Hi all...
Following Helsinki, it was agreed that five RFCs should be written and
published in order to bring some stability to the foundations of Dublin
Core, and to give implementers something to implement FROM.
We have all seen the (excellent) drafts that John has been circulating
for RFC number 1 (the semantics of unqualified Dublin Core).
Here, then, is a draft of RFC number 3 (the semantics of qualified
Dublin Core), written by myself and Tony Gill.
We also have a draft of RFC number 4 (implementing qualified DC in
HTML), but it's bound to cause confusion if they're both sent out
together, so we'll try them one at a time.
There is some talk about possibly restructuring the current five RFC
model, so it's probably not worth people paying too much attention to
the nitty-gritty detail of layout, so much as the sorts of information
Tony and I have tried to gather together, and the clarity of the text
for a non-meta2 addict.
Included in this RFC is the subelement working group's current list of
'core' subelements -- a list from which Stu derived HIS list last week,
creating a minor storm of protest/panic... Don't confuse the two.
Paul
--
== paul miller ================== [log in to unmask] ==
collections manager, archaeology data service, king's manor
york, YO1 2EP, UK tel: +44 (0)1904 43 3954
== http://ads.ahds.ac.uk/ahds/ ==== fax: +44 (0)1904 43 3939 ==
Dublin Core Workshop Series P. Miller
Internet-Draft T. Gill
draft-miller-dc-00.txt
3 February 1998
Expires in six months
Qualified Dublin Core Metadata for Simple Resource Discovery
1. Status of this Document
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 rendered obsolete 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 Coa
st), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to [log in to unmask], or to the discussion list [log in to unmask]
2. Introduction
The Dublin Metadata Core Element Set, or "Dublin Core", is a set of 15 information elements used to provide a simple means by which networked electronic resources may be described for more effective discovery and retrieval.
The fifteen elements of the Dublin Core are TITLE, CREATOR, SUBJECT, DESCRIPTION, PUBLISHER, CONTRIBUTORS, DATE, TYPE, FORMAT, IDENTIFIER, SOURCE, LANGUAGE, RELATION, COVERAGE and RIGHTS. The elements are described more fully in RFC [DC-RFC1], and on the
official Dublin Core web site [1].
These 15 elements and their meanings have been developed and refined by an international group of librarians, information and subject specialists through a consensus-building process that has included 5 international workshops to date and discussion on th
e active Meta2 mailing list [2].
During the workshop series, a significant body of the participant community agreed on the need for a simple, optional method for additional semantic qualification of Dublin Core metadata. The method agreed upon is the use of the Canberra Qualifiers, SCHEM
E, LANG and SUBELEMENT.
This document describes the semantics by which these subelements can be used to refine the basic functionality of the Dublin Core. Rather than present the details of implementation in any one presentation format, this document is restricted to discussion
of the semantic generalities underpinning qualified Dublin Core, and applies equally to implementation in HTML (RFC [DC-RFC4]), RDF (RFC [DC-RFC5]), or any other manner.
The broad agreements on syntax and semantics that have emerged from the workshop series will be expressed in a series of five Informational RFCs, of which this document is the third. These RFCs (currently Internet-Drafts) will comprise the following docum
ents:
2.1 Dublin Core Metadata for Simple Resource Discovery
(RFC [DC-RFC1])
Editors: John Kunze and Carl Lagoze
An introduction to the Dublin Core and a description of the intended semantics of the 15-element Dublin Core element set without qualifiers.
2.2 Encoding Dublin Core Metadata in HTML
(RFC [DC-RFC2])
Editors: John Kunze and Carl Lagoze
A formal description of the convention for embedding unqualified Dublin Core metadata in HTML.
2.3 Qualified Dublin Core Metadata for Simple Resource Discovery
(RFC [DC-RFC3])
Editors: Paul Miller and Tony Gill
The principles of element qualification and the semantics of Dublin Core metadata when expressed with a recommended qualifier set known as the Canberra Qualifiers.
2.4 Encoding Qualified Dublin Core Metadata in HTML
(RFC [DC-RFC4])
Editors: Tony Gill and Paul Miller
A formal description of the convention for embedding qualified Dublin Core metadata in HTML.
2.5 Dublin Core on the Web: RDF Compliance and DC Extensions
(RFC [DC-RFC5])
Editors: to be determined
A formal description for encoding Dublin Core metadata with qualifiers in HTML compliant metadata, and how to extend the core element set.
3. Unqualified Dublin Core Metadata - A Brief Overview
The means of expressing unqualified Dublin Core metadata (i.e. without the use of the Canberra Qualifiers) are defined formally in RFC [DC-RFC1], along with official definitions of the fifteen core elements. This most basic vision of the Dublin Core forms
the basis of all implementations, whether realised in HTML, RDF, within a relational database structure, or other format, and underpins even the most highly qualified and complex applications, all of which must follow the guidelines, below.
Unqualified Dublin Core as defined in RFC [DC-RFC1] forms a lowest common denominator to all more structured applications, and the guidance presented in this RFC is intended to ensure that applications built to interpret this lowest common denominator wil
l always be able to interpret even the most highly qualified Dublin Core records to some degree, albeit without the subtle nuances embedded by the record creator. Dublin Core is thus equipped to meet disciplinary, national or domain-specific requirements
for refinement and qualification on the one hand, whilst continuing to service the guiding principle of inter-disciplinary, international and inter-domain interoperability on the other.
4. Qualified Dublin Core Metadata - The Canberra Qualifiers
Although simplicity remains one of the fundamental tenets of the Dublin Core metadata initiative, a significant body of the stakeholder community believes that the option to refine the semantics of the element set through the addition of qualifiers is ess
ential to allow effective deployment of the Dublin Core for resource discovery.
For example, a value of 759.2 in the SUBJECT element is meaningless unless the value is qualified as a reference to the Dewey Decimal Classification system, allowing the meaning (British Painting) to be correctly interpreted. Similarly, the elements DATE
and COVERAGE often have little meaning or value without qualification of some form; for example, the date 06-11-97 could refer to the sixth day of November or the eleventh day of June, and the century is clearly ambiguous.
To address these shortcomings, the qualifiers SUBELEMENT, SCHEME and LANG were proposed at the 4th Dublin Core workshop in Canberra, Australia. These 'Canberra Qualifiers' are:
SUBELEMENT, which allows the refinement and clarification of an element's content, such as, for example, refining the definition of DATE into Creation Date, Date Last Modified, etc.
SCHEME, which allows an element's value to be identified as part of an existing classification system, coding scheme, glossary or thesaurus, such as the Dewey Decimal Classification for books or the Art & Architecture Thesaurus for cultural he
ritage.
LANG, which specifies the base language of an element's attribute values and text content; it is recommended that the values for this element are compliant with the scheme for creating language tags described by RFC 1766 [3].
The LANG qualifier should not be confused with the Dublin Core's LANGUAGE element. The former defines the language in which the metadata is expressed, the latter defines the language in which the resource being described is itself presented.
By optionally applying any or all of these qualifiers to the 15 elements of the Dublin Core, more detailed and semantically specific information about a resource can be encoded, thus assisting precision in the discovery and retrieval process for systems t
hat support the use of these qualifiers.
It is important for implementers and developers to remember that the use of these Canberra Qualifiers remains optional, with a further requirement that qualified Dublin Core records must remain intelligible to those tools capable only of manipulating the
most basic unqualified Dublin Core as defined in RFC [DC-RFC1].
In order to ensure such backward compatibility, and to maintain interoperability between different, highly qualified, applications of Dublin Core, a series of guidelines are offered for the way in which qualifiers should be implemented.
4.1 Rules for the application of Canberra Qualifiers
The three rules, below, must be adhered to by any application of the Canberra Qualifiers to the Dublin Core:
The Canberra Qualifiers are optional refinements of the Dublin Core element set, and their use should not conflict with the 'minimalist' implementation of Dublin Core, whereby the fifteen elements are used in an unqualified manner.
An unqualified element is interpreted according to the definition given in RFC [DC-RFC1].
Any SUBELEMENT is required to register a simple definition of its role with respect to the parent element.
4.2 Guiding principles for the application of Canberra Qualifiers
As well as the rules, above, a number of guiding principles exist for the manner in which Canberra Qualifiers should best be applied to Dublin Core applications. These principles should be employed wherever possible, and those failing to adher
e to them within individual applications risk rendering that application less than interoperable with the wider community.
In principle, use of Canberra Qualifiers should refine, rather than extend, the interpretation of a Dublin Core element.
In principle, Canberra Qualifiers implemented within individual user communities or applications must further refine the interpretation of the Dublin Core elements, and must therefore fit within the structure of 'official' Dublin Core SUBELEME
NTs presented in Section 4.3, below.
In principle, SUBELEMENTs should be used as sparingly as practicable.
In principle, implementers should strive towards using as few levels of SUBELEMENT as possible beneath any Dublin Core element.
4.3 A list of widely applicable SUBELEMENTs for the Dublin Core
Within the confines laid down in Sections 4.1 and 4.2, above, implementers are free to develop their own SUBELEMENTs in order to meet specific local requirements.
It should be borne in mind, though, that whilst the application of numerous SUBELEMENTs to the Dublin Core is likely to increase its value to any one application area or subject grouping, the same action is equally likely to reduce the potential for inter
operability between domains. As such, the addition of SUBELEMENTs to the 15 core elements of Dublin Core should be kept to a minimum.
Developers wishing to extend the scope and functionality of Dublin Core beyond that catered for by the 15 elements and a limited number of SUBELEMENTs are directed to RFC [DC-RFC5], where extensions to the Dublin Core are discussed.
Whilst complex applications of Dublin Core are likely to have differing requirements for specialist SUBELEMENTs, early implementers frequently identified a common requirement for certain key SUBELEMENTs. Rather than encourage proliferation of these common
SUBELEMENTs, with each application employing slightly different nomenclature and semantics, the most commonly utilised SUBELEMENTs identified to date are gathered together below, and presented in a standardised form. As can be seen, most of the 15 elemen
ts remain unqualified.
4.3.1 TITLE
Title.Alternative
Used for any titles other than the main title; including subtitle, translated title, series title, vernacular name, etc.
4.3.2 CREATOR
Creator.PersonalName
The name of an individual associated with the creation of the resource.
Creator.CorporateName
The name of an institution or corporation associated with the creation of the resource.
Creator.PersonalName.Address
An electronic or physical address for the individual in question. This could be an electronic mail address, web page URL, postal address, etc., and is most useful if further defined by use of a SCHEME.
Creator.CorporateName.Address
An electronic or physical address for the institution or corporation in question. This could be an electronic mail address, web page URL, postal address, etc., and is most useful if further defined by use of a SCHEME.
4.3.3 SUBJECT
No SUBELEMENTs at present.
4.3.4 DESCRIPTION
No SUBELEMENTs at present.
4.3.5 PUBLISHER
Publisher.PersonalName
The name of an individual associated with the publication of the resource.
Publisher.CorporateName
The name of an institution or corporation associated with the publication of the resource.
Publisher.PersonalName.Address
An electronic or physical address for the individual in question. This could be an electronic mail address, web page URL, postal address, etc., and is most useful if further defined by use of a SCHEME.
Publisher.CorporateName.Address
An electronic or physical address for the institution or corporation in question. This could be an electronic mail address, web page URL, postal address, etc., and is most useful if further defined by use of a SCHEME.
4.3.6 CONTRIBUTORS
Contributors.PersonalName
The name of an individual making a contribution to the creation of the resource.
Contributors.CorporateName
The name of an institution or corporation making a contribution to the creation of the resource.
Contributors.PersonalAddress
An electronic or physical address for the individual in question. This could be an electronic mail address, web page URL, postal address, etc., and is most useful if further defined by use of a SCHEME.
Contributors.CorporateAddress
An electronic or physical address for the institution or corporation in question. This could be an electronic mail address, web page URL, postal address, etc., and is most useful if further defined by use of a SCHEME.
4.3.7 DATE
Date.Created
Date of creation of the resource
Date.Issued
Date of formal issuance (e.g., publication) of the resource.
Date.Accepted
Date of acceptance (e.g., for a dissertation or treaty) of the resource.
Date.DataGathered
Date of sampling of the information in the resource.
Date.Available
Date (often a range) that the resource will become or did become available.
Date.Acquired
Date of acquistion or accession.
Date.Valid
Date (often a range) of validity of the resource.
4.3.8 TYPE
No SUBELEMENTs at present.
4.3.9 FORMAT
No SUBELEMENTs at present.
4.3.10 IDENTIFIER
No SUBELEMENTs at present.
4.3.11 SOURCE
No SUBELEMENTs at present.
4.3.12 LANGUAGE
No SUBELEMENTs at present.
4.3.13 RELATION
Relation.IsPartOf
The resource being described is physically and/or logically part of a larger resource, referred to by this use of the element.
Relation.HasPart
The resource being described physically and/or logically contains one or more constituent resources, referred to by this use of the element.
Relation.IsVersionOf
The resource being described is an historical state or edition of an earlier resource by the same creator, an earlier instantiation of which is referred to by this use of the element.
Relation.HasVersion
The resource being described is an earlier edition of a resource later altered through further editions, one of which is referred to by this use of the element.
Relation.IsFormatOf
The resource being described has been mechanically or technologically altered into a new manifestation or reproduction, which may be considered fundamentally not as a reinterpretation of the original but rather as an alternative repres
entation. An earlier manifestation of the resource is referred to by this use of the element.
Relation.HasFormat
The resource being described is an earlier manifestation of a resource which exists in several technologically different but interpretatively similar representations, one of which is referred to by this use of the element.
Relation.References
The resource being described is related to another resource to such an extent that it is considered appropriate to provide a citation to the second resource here.
Relation.IsReferencedBy
The resource being described is significantly referred to by a second resource, a citation for which is included here.
Relation.IsBasedOn
The resource being described owes a significant creative debt to an earlier work, referred to by this use of the element.
Relation.IsBasisFor
The resource being described is a significant basis for some later work, referred to by this use of the element.
Relation.Requires
The resource being described is dependent upon another resource, referred to by this use of the element, in order to ensure its effective functioning, delivery or interpretation. The resource referred to by this use of the element is requi
red if the resource being described is to be used.
Relation.IsRequiredBy
The resource being described is essential to the functioning, delivery or interpretation of another resource, referred to by this use of the element.
4.3.14 COVERAGE
Coverage.PeriodName
The resource being described is from or related to a named historical period, referred to by this use of the element.
Coverage.PlaceName
The resource being described is associated with a named place, identified by this use of the element.
Coverage.x
The resource being described is associated with a spatial location which may be defined by the use of x, y, (and, possibly, z) co-ordinates. The x co-ordinate is given in this use of the element.
Coverage.y
The resource being described is associated with a spatial location which may be defined by the use of x, y, (and, possibly, z) co-ordinates. The y co-ordinate is given in this use of the element.
Coverage.z
The resource being described is associated with a spatial location which may be defined by the use of x, y, (and, possibly, z) co-ordinates. The z co-ordinate is given in this use of the element.
Coverage.t
The resource being described is from or associated with an instance in time which may be given numerically.
Coverage.Polygon
The resource being described may be located with respect to a shape, or polygon, defined in space as a series of x,y co- ordinate values.
Coverage.Line
The resource being described may be located with respect to a line defined in space by a series of x,y co-ordinate values.
Coverage.3d
The resource being described may be located with respect to a volume, or hull, defined in three dimensional space as a series of x,y,z co-ordinate values.
Further refinements of the Coverage element are discussed in the report of the Coverage working party [4]. These include the capability to further refine semantics by identifying minimum and maximum values (e.g. Coverage.x.Min and Coverage.x.Max), etc.
4.3.15 RIGHTS
No SUBELEMENTs at present.
4.4 Encouraging adoption of controlled vocabularies: the use of SCHEME
Much of the information made available by means of the Dublin Core is potentially difficult for the user to interpret, rendered as it (probably) is outwith a context familiar to the user or typical for the resource.
For example, a value for the Dublin Core's Coverage element of 466345, for example, means next to nothing. It is only when the value is qualified as being from the National Grid of the Ordnance Survey of Great Britain that it begins to have any useful mea
ning or significance; it is a measurement in metres east of a point off the southwest coast of Great Britain. Even users not intimately familiar with the inner workings of the British National Grid system are placed in a position where they can consult av
ailable reference material to help them make sense of the value.
Similarly, a Subject value of 759.2 is impossible to interpret unless the user is aware that it is a Dewey Decimal Classification Number. With this information available, the code can be looked up and translated to become the intelligible British Painting
.
The Dublin Core's SCHEME qualifier fulfils this important role of aiding users in the process of decoding the information stored within the elements of any Dublin Core record.
Using the optional SCHEME qualifier, it is possible to identify the coding practice, controlled terminology, or thesaurus from which any term is drawn, and to gain insights both into the meaning of the term itself and the context from which it was drawn.
Current best practice advocates the use of acronyms to identify SCHEMEs, with commonly-used examples including AAT for the Getty Information Institute's Art & Architecture Thesaurus, LCSH for the United States Library of Congress Subject Headings, MeSH fo
r the Medical Subject Headings, or DDC for the Library world's Dewey Decimal Classification.
No single list currently exists of SCHEMEs in use within the Dublin Core community, and it is suggested that a registry agency be established to regulate possible conflicts between acronyms. Should AA, for example, be used in reference to the Automobile A
ssociation or Alcoholics Anonymous?
SCHEMEs used solely for internal purposes need not be registered, and may be denoted by the use of a leading x- to distinguish them from global SCHEMEs. x-LCSH (a Local Community School and Hospital index, perhaps?), for example, would be a local SCHEME,
and should not be confused with the global LCSH used to identify the Library of Congress Subject Headings.
5. Security Considerations
The Dublin Core element set poses no risk to computers and networks. It poses minimal risk to searchers who obtain incorrect or private information due to careless mapping from rich data descriptions to the simple Dublin Core scheme. No other security co
ncerns are likely to be raised by the element description consensus documented here.
6. References
[1] Dublin Core,
http://purl.org/metadata/dublin_core
[2] Meta2 mailing list archive,
http://weeble.lut.ac.uk/lists/meta2/
[3] RFC 1766, Tags for the Identification of Languages,
http://ds.internic.net/rfc/rfc1766.txt
[4] Dublin Core Coverage Working Party report,
http://www.sdc.ucsb.edu/~mary/coverage.htm
7. Authors' Addresses
Paul Miller
Archaeology Data Service
King's Manor
York, YO1 2EP, UK
Email: [log in to unmask]
Voice: +44 1904 43 3954
Fax: +44 1904 43 3939
Tony Gill
Surrey Institute of Art & Design
Falkner Road
Farnham, Surrey, GU9 7DS, UK
Email: [log in to unmask]
Voice: +44 1252 892721
Fax: +44 1252 892725
|
