|
A review of metadata: a survey of current resource description formats
Work Package 3 of Telematics for Research project DESIRE (RE 1004) |
Title page
Table of Contents |
LDAP, the Lightweight Directory Access Protocol, is documented in RFC 1777. It is worth noting that LDAP started out life as a means of providing access to the X.500 Directory Service for machines which did not have the necessary power to run the full Directory Access Protocol over OSI lower layers. Over time LDAP has evolved to the point where it is now possible to use it as a stand-alone directory service protocol in its own right - i.e. with no use of X.500 behind the scenes.
The most recent revision of the LDAP protocol, which provides the necessary additional functionality, has yet to be published as an RFC - and is currently undergoing major modifications.
LDIF, the LDAP Data Interchange Format, is currently only documented in the LDAP software distribution from the University of Michigan <URL:http://www.umich.edu/~rsug/>.
LDAP and the associated LDAP Data Interchange Format are of interest to us because of their adoption by Netscape Communications Corporation, who in addition to developing a Directory Server product, have also said that they will integrate LDAP support with their popular Netscape Navigator World-Wide Web browser.
X.500 and LDAP are primarily used for White Pages type applications, such as searching for email and postal addresses, and telephone numbers. This should not be taken to mean that White Pages applications are their only use - X.500 was originally intended to support a wide variety of uses, including automatic routing of email and public key certificate distribution via the X.509 standard. In fact, White Pages is the only application of the technology which has been deployed to any extent on public data networks - and even then only in a trivial capacity by comparison with the near-universal adoption of the World-Wide Web suite.
If Netscape choose to integrate LDAP with their browser product in such a way as to facilitate its use for non-White Pages applications, this would mean that the vast majority of World-Wide Web users (most of whom are currently reckoned to be using various versions of the Netscape Navigator product) would have a search and retrieval protocol delivered directly to their desktop. This would be a major advance on the current situation, where search and retrieval operations typically take place via third parties - often using dedicated WWW servers or CGI programs.
The key issue here is to do with the schema used to represent information within the LDAP based directory service. The schema is the set of attributes a particular object within the directory may inherit from whatever object classes the LDAP server is aware of. This is a similar notion to object oriented programming in languages such as C++ and Java. LDAP need not necessarily conform to the schema definitions which have been made for X.500, but this would be bad for interopability. In any case, the X.500 schema definitions are based on numeric object identifiers, whereas LDAP holds attribute names and schema information as plain text.
Be this as it may, flexible LDAP client support in Netscape Navigator and other similar products would require knowledge of other schemas in addition to straightforward White Pages information - perhaps including support for downloadable schemas. At the moment this is all supposition, however.
What is clear is that a schema suitable for document-like objects, such as World-Wide Web pages, does not exist at the moment. It could be expected that some time would elapse before consensus was reached on this, but the commercial interest may spur its development on on a unilateral basis. A suitable basis for experimentation might be the schema definitions used by Paul Barker and David Thomas for the ABDUX project though note that this work is primarily aimed at reproducing the OPAC environment via X.500 <URL:ftp://cs.ucl.ac.uk/abdux>.
Here, and for the remainder of this section, we will focus on the use of LDIF as the "LDAP metadata format."
The LDAP protocol provides native support for object addition, modification, and deletion - so in theory LDAP based user interfaces could be used for all of the regular maintenance activities. This would facilitate the use of, for example, authority files.
The LDIF format provides a mechanism by which the LDAP server's database may be updated without using the LDAP protocol itself. Records may be created using any text editor, and no specialist training would be required except in cases such as (for example) where an attribute's value was to be restricted to words selected from a controlled vocabulary.
It should also be noted that LDIF is capable of handling binary data, which needs to be encoded according to the base64 convention used within MIME. This may not be readily generated by hand!
LDAP version 2 was recently advanced to the IETF standards track. This is not the version which implements stand-alone LDAP - that being version 3, which is still under development.
See also the notes below on URIs and internationalisation. Schema standardisation also would seem likely to occur within the auspices of the IETF, since this is where the majority of LDAP development has taken place.
None defined as yet.
None defined as yet.
An Internet Draft proposing a formalism for inclusion of URLs and/or URIs has seen widespread adoption within the LDAP/X.500 developer community. This is being advanced through the IETF's Access, Searching and Indexing of Directories working group - ASID (<URL:http://www.ietf.org/html.charters/asid-charter.html>).
Note that the format which has been adopted optionally includes a plain text label associated with each URI, and that multiple URIs may be associated with a single object.
None defined as yet.
None defined as yet.
None defined as yet, though some may be inherited from existing practice with X.500 - e.g. record modification times and ownership.
None defined as yet.
None defined as yet.
None defined as yet.
Where an attribute has multiple values, these may be written as separate attribute-value pairs, on successive lines. Where an attribute-value pair would be too long to conveniently fit onto a single line onscreen, the value may be continued by starting a new line with a single space or tab character.
Multiple objects may be packaged into a single LDIF format file, with a blank line separating one object from another. Each object may be allocated a unique numeric ID to distinguish it from other objects.
Here is a sample LDIF object using the conventional Internet White
Pages schema:
[12368]
dn: cn=martin hamilton, o=loughborough university, c=gb
cn: martin hamilton
o: loughborough university
c: gb
email: m.t.hamilton@lut.ac.uk
labeledURI: http://hpc.lut.ac.uk/~comth/
objectclass: person labeledURIObject
The LDIF record must currently be encoded as plain vanilla ASCII text. As noted above, binary objects may be embedded, but only if they are converted to base 64 encoding first.
There is no support for multiple languages or character sets in LDAP v2. This seems likely to appear in LDAP version 3 and there is currently a Internet Draft available that outlines the use of UTF-8 encodings in LDAP Distinguished Names, suitable for transporting Unicode multilingual characters.
Potentially, complex relationships could be expressed. Aliases are well defined as part of the X.500 heritage - these can be used to provide persistent location independent names for objects. Other relationships are typically White Pages oriented, e.g. manager.
None as yet. Has the potential to be anything from miminal to rich.
LDAP runs over a TCP connection, and has dispensed with the extra OSI layers used by X.500 - though it does still use a cut down version of the Basic Encoding Rules to convert its data into on-the-wire format.
LDIF objects may be interchanged using many other protocols, since they are written as text. In particular, they may easily be used as MIME objects within mail, news and HTTP messages. Searching is an integral part of the LDAP protocol and X.500.
The only widely deployed server implementation is the freely available one which was produced by the University of Michigan. Now that its principal developers have left to work for Netscape, its future is unclear. Note that the phrase widely deployed in this context means widely deployed amongst the small community of Internet sites which run directory services of one sort or another.
Numerous LDAP based gateways from other protocols and dedicated
clients are distributed with the University of Michigan LDAP release.
Some other development has taken place elsewhere, e.g. with the
development of World-Wide Web and CCSO nameserver gateways.
| Next | Table of Contents |
$Id: rev_13.htm,v 1.2 1997/05/23 16:46:13 lisap Exp $