Open Meta Tools Make It Big
Morgahastu writes "Byte.com has a great article about open meta tools and open software in general: "After more than 10 years of open-software development in the scientific community, open software now holds a preeminent place in the operation of the computing community. The three products I have written about simply scratch the surface of the powerful tools available. OpenLDAP and OAI both enable a wide variety of sharing and automated access.""
Actually the Massachusetts library system uses LDAP for it's electronic card file system. LDAP is optimized for fast lookup and searches. Only insertions are slow. SQL is better suited to data that changes where LDAP is mostly for static-ish data like card files.
I don't know if I like the idea of using LDAP as a library card file, but LDAP does have the advantage of having a heirarchy so it would easier to organize books. Now that I think about it, I'll bet you could get better performance on searchs using LDAP and it would almost certainly be easier to manage.
The OAI spec mandates that data providers support unqualified Dublin Core, but you can provide any other metadata format you want in addition to Dublin Core (as long as there's an XML schema defining the format available). So, both
PRISM and SCORM should work with OAI (although
you might have to whip up an XML schema for
PRISM -- I'm not sure there's an official one in the works). Various communities are looking at OAI for exchanging non-Dublin Core metadata; librarians are looking at it for exchanging MARC data and other forms of metadata (such as the MODS and METS formats). I'd be surprised if someone isn't already trying to do an OAI/SCORM project.
Jerome McDonough
NYU Digital Library Team
jerome.mcdonough@nyu.edu
There are several implementations of the virtual LDAP directory you mention. Some of them are Maxware, OctetString, Radiant Logic, and Persistent Data.
All of them provide the ability to front-end various LDAP, RDBMS, and other data repositories into a virtual LDAP directory structure.
The Lightweight part of LDAP means that it is optimised for reading, and does not expect to be written to very much. Databases, on the other hand, could be considered heavyweight because, with transactions, they can guarantee the accuracy of the data.
You cannot run an airline reservation system on LDAP. If I update LDAP information, the next few readers might get stale data.
LDAP is thus lighter on resources, and, IMHO, would be a better tool for a library index.
Andy Rabagliati
Protocols to mention besides OpenLDAP and OAI are Whois++ and Z39.50. OAI actually is transported over HTTP. You could do the same with EAD or others.
Projects which implemented Z39.50 for the purposes of interoperability are ONE and ONE-2, EUROPAGATE, Desire and Desire II, DECOMATE and DECOMATE II, and Renardus just to touch the surface. Don't forget OHIOLINK...
Another other older, but interesting, metadata activity have been SGML MARC, and the corresponding XML MARC.
Those that are interested in more detailed reading can check out the Nordic Metadata Project, Nordic Metadata Project II, which studied the practical implications of cross browsing multiple databases and especially the use of Dublic Core. Even if you get agreement on the protocol and data standard, cross searching's not as easy as it sounds. One of the tools is the Dublin Core Metadata Temple (get it while you still can).The BYTE article was exciting to see again and could have benefited further from pointing out the relative ease of use of Dublic Core. OAI uses unqualified Dublic Core, SAFARI uses qualified Dublin Core to create an up to date index over academic research in Sweden. Shoot, since it already uses some META tags, you could even tweak htdig to use Dublic Core on your own site for those high precision searches.
With the interest in structured data (XML?) maybe well see some sites serving up not just HTML with Dublic Core, but maybe even Docbook or even TEI / TEI Lite. There are great tools for converting from Docbook to HTML, PDF, RTF, etc. and AbiWord and Kword already have partial support for docbook. If there were more, then we could see some real changes on searching the web. Coding for SGML is more difficult, so the obvious choice would be to start from Docbook XML.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.