Network Working Group Martin Hamilton
INTERNET-DRAFT Loughborough University
Expires January 1998 Renato Iannella
DSTC Pty Ltd
Jon Knight
Loughborough University
July 1997
Representing the Dublin Core within X.500, LDAP and CLDAP
Filename: draft-hamilton-dcxl-02.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as ``work
in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
The Dublin Core is a simple resource description format which arose
out of a loose grouping of "librarians, archivists, humanities
scholars and geographers, as well as standards makers in the
Internet, Z39.50 and Standard Generalized Markup Language (SGML)
communities" [1].
This document describes a mapping from the abstract model of the
Dublin Core to the X.500 [2], LDAP [3], and CLDAP [4] directory
service protocols.
[Page 1]
INTERNET-DRAFT July 1997
1. The Dublin Core in X.500, LDAP and CLDAP
We propose that each of the fifteen elements of the Dublin Core be
made into an X.500/[C]LDAP attribute, and that these attributes be
gathered together in an object class:
Name: dcObject
Description: object containing the Dublin Core attributes
OID: lutObjectClass.1 (1.3.6.1.4.1.1828.2.1)
SubclassOf: top
MustContain:
MayContain: dcTitle, dcCreator, dcSubject, dcDescription,
dcPublisher, dcContributors, dcDate,
dcType, dcFormat, dcIdentifer, dcSource,
dcLanguage, dcRelation, dcCoverage, dcRights
Attribute definitions for the individual Dublin Core elements:
Name: dcTitle
Description: The name of the resource
OID: lutAttributeType.1 (1.3.6.1.4.1.1828.1.1)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcCreator
Description: The person(s) primarily responsible for the
intellectual content of the resource
OID: lutAttributeType.2 (1.3.6.1.4.1.1828.1.2)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcSubject
Description: The topic addressed by the resource, or a
set of appropriate keywords
OID: lutAttributeType.3 (1.3.6.1.4.1.1828.1.3)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcDescription
Description: A plain text description or abstract about
the resource.
OID: lutAttributeType.4 (1.3.6.1.4.1.1828.1.4)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
[Page 2]
INTERNET-DRAFT July 1997
Name: dcPublisher
Description: The agent or agency responsible for making the
resource available
OID: lutAttributeType.5 (1.3.6.1.4.1.1828.1.5)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcContributors
Description: The person(s), such as editors and transcribers, who
have made other significant intellectual
contributions to the work
OID: lutAttributeType.6 (1.3.6.1.4.1.1828.1.6)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcDate
Description: The date of publication
OID: lutAttributeType.7 (1.3.6.1.4.1.1828.1.7)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcType
Description: The genre of the resource, such as novel, poem, or
dictionary
OID: lutAttributeType.8 (1.3.6.1.4.1.1828.1.8)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcFormat
Description: The physical manifestation of the resource, such as
Postscript file or Windows executable file
OID: lutAttributeType.9 (1.3.6.1.4.1.1828.1.9)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcIdentifier
Description: String or number used to uniquely identify the
resource
OID: lutAttributeType.10 (1.3.6.1.4.1.1828.1.10)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
[Page 3]
INTERNET-DRAFT July 1997
Name: dcSource
Description: Resources, either print or electronic, from which
this resource is derived, if applicable
OID: lutAttributeType.11 (1.3.6.1.4.1.1828.1.11)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcLanguage
Description: Language of the intellectual content
OID: lutAttributeType.12 (1.3.6.1.4.1.1828.1.12)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcRelation
Description: Relationship to other resources
OID: lutAttributeType.13 (1.3.6.1.4.1.1828.1.13)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcCoverage
Description: The spatial locations and temporal durations
characteristic of the resource
OID: lutAttributeType.14 (1.3.6.1.4.1.1828.1.14)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
Name: dcRights
Description: Information concerning the intellectual property
rights that are being exercised over the
resource (including access terms)
OID: lutAttributeType.15 (1.3.6.1.4.1.1828.1.15)
Syntax: DirectoryString
SizeRestriction: None
SingleValued: False
2. Examples and implementation considerations
For example, using Quipu [5] EDB notation, a Dublin Core "Title"
element which had the value "Cities of The Red Night" would be
represented as the attribute/value pair:
dcTitle= Cities of The Red Night
One aspect of the Dublin Core does not translate directly to X.500
[Page 4]
INTERNET-DRAFT July 1997
and LDAP - each element may have additional qualifying information
attached to it. This gives the creator of the record a way 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. We propose that, given
the difficulty of incorporating this model within the X.500/LDAP
paradigm, a simple but sub-optimal approach be taken - with any
qualifying information being placed at the beginning of the value
part of the attribute/value pair, delimited using round brackets, and
with any additional qualifiers following using comma separation.
For example, if the subject classification for the above book were
813 in the Dewey Decimal system, the resulting Dublin Core record
expressed as an X.500 EDB entry would look like this:
dcSubject= (scheme=DDC) 813
3. Extensibility
It is important to note that the Dublin Core element set is intended
for use in describing document-like objects, and not as a means of
describing arbitrary objects. Furthermore, the number of elements is
strictly limited in the interests of interoperability.
Work is ongoing on the Warwick Framework [6], which attempts to
provide a mechanism for packaging together collections of descriptive
information. It is envisaged that this would be used in cases where
the Dublin Core element set did not provide enough descriptive
capability. This is a subject for further study.
4. Security considerations
This proposal does not introduce any new security related issues.
One of the main uses to which the Dublin Core is expected to be put
is in the generation of author supplied cataloguing information for
on-line resources. Implementations which manipulate externally
produced data should treat it with caution - for example, to avoid
buffer overrun problems and unexpected evaluation of metacharacters.
5. Conclusions
This document has shown how the X.500 protocol, and the related LDAP
and CLDAP protocols, may be used as carriers for the abstract
resource descriptions of the Dublin Core proposal.
[Page 5]
INTERNET-DRAFT July 1997
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 additional implementation complexity.
6. Acknowledgements
Thanks to Hoylen Sue, CiTR Pty Ltd (Australia), Rachel Heery and
Lorcan Dempsey for their comments on draft versions of this document.
This work was supported by UK Electronic Libraries Programme (eLib)
grant 12/39/01, the European Commission's Telematics for Research
Programme, grant RE 1004, and the Cooperative Research Centres
Program, through the Department of the Prime Minister and Cabinet of
Australia.
7. References
[1] S. Weibel. "Metadata: The Foundations of Resource
Description", D-Lib Magazine, July 1995.
<URL:http://www.ukoln.ac.uk/dlib/dlib/July95/07weibel.html>
<URL:http://www.dlib.org/dlib/July95/07weibel.html>
[2] C. Weider, J. Reynolds, S. Heker. "Technical Overview
of Directory Services Using the X.500 Protocol", RFC
1309. March 1992.
<URL:ftp://ftp.internic.net/rfc/rfc1309.txt>
[3] W. Yeong, T. Howes & S. Kille. "Lightweight Directory
Access Protocol", RFC 1777. March 1995.
<URL:ftp://ftp.internic.net/rfc/rfc1777.txt>
[4] A. Young. "Connection-less Lightweight Directory
Access Protocol", RFC 1798. June 1995.
<URL:ftp://ftp.internic.net/rfc/rfc1798.txt>
[5] S.E. Kille. "Implementing X.400 and X.500: the PP and
QUIPU systems", Artech House, 1991.
[6] L. Dempsey, S. Weibel. "The Warwick Metadata Workshop:
A Framework for the Deployment of Resource Descrip-
tion", D-Lib Magazine, July/August 1996.
<URL:http://www.ukoln.ac.uk/dlib/dlib/july96/07weibel.html>
[Page 6]
INTERNET-DRAFT July 1997
<URL:http://www.dlib.org/dlib/july96/07weibel.html>
8. 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
Research Data Network CRC
DSTC Pty Ltd
Gehrmann Laboratories
University of Queensland
Australia
Email: renato@dstc.edu.au
Jon Knight
Department of Computer Studies
Loughborough University of Technology
Leics. LE11 3TU, UK
Email: j.p.knight@lut.ac.uk
[Page 7]