Martin Hamilton Loughborough University Renato Iannella IPR Systems Jon Knight Loughborough University Rostislav Matl Masaryk University September 2001 Representing the Dublin Core within X.500 and LDAP Abstract This document is updated version of draft from August 1996 and provides a description of mapping from abstract model of the Dublin Core to the directory service protocol LDAP [1] and its forecomer X.500 [2]. The Dublin Core is set of fifteen descriptive elements laying the foundations of metadata vocabularies for resource discovery. This basic set is further extended in specificity via so called qualifiers by either element refinement or encoding scheme declaration [3][4]. In April 1996 it has been augmented by the Warwick Framework [5], which provides a concept of modular metadata allowing to combine separately maintained metadata packages. It allows additional information to be packaged up with Dublin Core records without changing the Dublin Core itself. 1. The Dublin Core in X.500 and LDAP Attribute definitions for the individual Dublin Core elements, all have syntax of DirectoryString (UTF-8 form of ISO 10646 defined in [7]): Name: dcTitle Description: A name given to the resource. OID: 1 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcCreator Description: An entity primarily responsible for making the content of the resource. OID: 2 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcSubject Description: The topic of the content of the resource. OID: 3 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcDescription Description: An account of the content of the resource. OID: 4 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcPublisher Description: An entity responsible for making the resource available. OID: 5 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcContributor Description: An entity responsible for making contributions to the content of the resource. OID: 6 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcDate Description: A date associated with an event in the life cycle of the resource. OID: 7 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcType Description: The nature or genre of the content of the resource. OID: 8 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcFormat Description: The physical or digital manifestation of the resource. OID: 9 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcIdentifier Description: An unambiguous reference to the resource within a given context. OID: 10 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcSource Description: A Reference to a resource from which the present resource is derived. OID: 11 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcLanguage Description: A language of the intellectual content of the resource. OID: 12 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcRelation Description: A reference to a related resource. OID: 13 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcCoverage Description: The extent or scope of the content of the resource. OID: 14 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch Name: dcRights Description: Information about rights held in and over the resource. OID: 15 Syntax: DirectoryString SizeRestriction: None SingleValued: False Equality Match: caseIgnoreMatch Substring Match: caseIgnoreSubstringsMatch We propose that each of the fifteen elements of the Dublin Core be made into an X.500/LDAP attribute, and that these attributes be used both directly or gathered together in an object class: Name: dcContainer Description: object containing the Dublin Core attributes OID: 16 SubclassOf: top MustContain: MayContain: dcTitle, dcCreator, dcSubject, dcDescription, dcPublisher, dcContributor, dcDate, dcType, dcFormat, dcIdentifier, dcSource, dcLanguage, dcRelation, dcCoverage, dcRights Note: Formerly considered name dcObject cannot be used because it is now used for domain component object from core schema as defined in [6]. Examples: For example the Dublin Core "Title", "Identifier", and "dcDescription" elements can be used for description of simple bookmark: dcTitle: OpenLDAP dcIdentifier: http://www.openldap.org/ dcDescription: free opensource LDAP implementation 2. Qualified Dublin Core One aspect of the Dublin Core does not translate directly to X.500 and LDAP - each element may have additional qualifying "encoding scheme" or "elment refinement" information attached to it. This provides the creator of the record with a means of indicating additional semantics, e.g. the classification scheme being used in the "Subject" element. Since X.500 and LDAP are, like most Internet based search and retrieval protocols, attribute/value oriented, it is necessary to find a place to put this extra information. Because [3] states that "a client should be able to ignore any qualifier and use the description as if it were unqualified" we propose that the same approach as in [9] will be used. Only difference is that instead of "lang-" option there will be two qualifying options, "encoding-" and "refinement-" which can be used both on one attribute. Examples: dcTitle: OpenLDAP dcTitle;refinement-Alternative: OpenLDAP home page dcIdentifier;encoding-URI: http://www.openldap.org/ dcDescription: free opensource LDAP implementation dcDate;encoding-W3C-DTF;refinement-Created: 12/31/2000 It allows clients without knowledge of qualifiers to search and manipulate tree content easily. 3. Security considerations Security considerations are not discussed in this document. 4. Conclusions This document has shown how the abstract resource description proposals of the Dublin Core and the Warwick Framework may be used within the X.500 and LDAP protocols. It should be apparent that a little care is necessary when delivering this information via these protocols but that this does not imply any great implementation complexity over and above that which is required to support these protocols in the first place. 5. Acknowledgements Thanks to Hoylen Sue, CiTR Pty Ltd (Australia), and all other contributors for their comments on previous version of this draft. The previous version of this work was supported by grants from the UK Electronic Libraries Programme (eLib), the European Commission's Telematics for Research Programme, and the Cooperative Research Centres Program, through the Department of the Prime Minister and Cabinet of Australia. 6. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] M. Wahl, T. Howes, S. Kille. "Lightweight Directory Access Protocol (v3)", RFC 2251. December 1997. [2] C. Weider, J. Reynolds, S. Heker. "Technical Overview of Directory Services Using the X.500 Protocol", RFC 1309. March 1992. [3] Dublin Core Metadata Initiative "Dublin Core Metadata Element Set, Version 1.1: Reference Description", July 1999, [4] Dublin Core Metadata Initiative "Dublin Core Qualifiers", July 2000, [5] C. Lagoze, C. Lynch and R. Daniel. "The Warwick Frame- work: A Container Architecture for Aggregating Sets of Metadata", Technical Report TR96-1593, Cornell Univer- sity Department of Computer Science. June 1996. [6] S.Kille, M.Wahl, A. Grimstadt. "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247. January 1998. [7] M. Wahl, A. Coulbeck, T. Howes, S. Kille "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997 [9] M. Wahl, T. Howes "Use of Language Codes in LDAP", RFC 2596, May 1999 7. Authors' addresses Martin Hamilton Department of Computer Studies Loughborough University of Technology Leics. LE11 3TU, UK Email: m.t.hamilton@lut.ac.uk Renato Iannella IPR Systems Pty Ltd 19 Pitt St, Level 6 Sydney, NSW, 2000, AUSTRALIA Email: renato@iprsystems.com Jon Knight Department of Computer Studies Loughborough University of Technology Leics. LE11 3TU, UK Email: j.p.knight@lut.ac.uk Rostislav Matl Faculty of Informatics Masaryk University Brno Czech Republic Email: xmatl@fi.muni.cz