According to the Dublin Core homepage (see http://purl.oclc.org/metadata/dublin_core/), it is
a 15-element metadata element set intended to facilitate discovery of electronic resources. Originally conceived for author-generated description of Web resources, it has also attracted the attention of formal resource description communities such as museums and libraries.
The Dublin Core is developed by a rather informal group of librarians, networking people and content specialists. Since its creation in March 1995 in what is now called the first Dublin Core Metadata workshop, Dublin Core has rapidly gained popularity, in spite of the lamentable fact that it is not yet quite complete. This article will describe Dublin Core -related developments since Spring 1996, concentrating on the Dublin Core metadata workshops in Canberra and Helsinki.
Early Dublin Core developments and the role of the metadata in general were described by Traugott Koch, Ole Husby and Juha Hakala in a recent Nordinfo Nytt article (Koch). This article also included a report from the second Dublin Core metadata workshop held in Warwick, UK in April 1996. At that time the Dublin Core contained 13 elements. The format as such had not yet been utilized in actual implementation projects, but the first DC-based projects were at planning stage. One of these was NORDINFO's Nordic Metadata project (see http://www.lib.helsinki.fi/meta) which currently is one of the best-known Dublin Core initiatives in the world.
One of the most intriguing results of the Warwick workshop was the Warwick framework, a container architecture for delivering metadata on the Web. According to (Lagoze),
The framework is a mechanism for aggregating logically, and perhaps physically, distinct packages of metadata. This is a modularization of the metadata issue with a number of notable characteristics.
It allows the designers of individual metadata sets to focus on their specific requirements, without concerns for generalization to ultimately unbounded scope.
It allows the syntax of metadata sets to vary in conformance with semantic requirements, community practices, and functional (processing) requirements for the kind of metadata in question.
It separates management of and responsibility for specific metadata sets among their respective "communities of expertise".
It promotes interoperability by allowing tools and agents to selectively access and manipulate individual packages and ignore others.
It permits access to the different metadata sets that are related to the same object to be separately controlled.
It flexibly accommodates future metadata sets by not requiring changes to existing sets or the programs that make use of them.
The Resource Description Framework initiative described below will be based on the Warwick framework. The framework will therefore become an essential part of the Internet information infrastructure. The Dublin Core will be one of the formats that utilise the framework, along with MARC and other formats less familiar to the library community.
"I was not especially surprised that we concluded that the elements needed to discover text and images on the internet are similar. The text and the images themselves are radically different and require different types of expertise to study and interpret them, but most of the primary categories under which we classify and search for them are similar."
But there was a price to be paid: two new elements, Rights Management and Description, were added to the format. The former is defined in the Dublin Core Reference description document (Dublin) as:
A link to a copyright notice, to a rights-management statement, or to a service that would provide information about terms of access to the resource. Formal specification of rights is currently under development. Users and developers should understand that use of this element is currently considered to be experimental.
Description is described as:
A textual description of the content of the resource, including abstracts in the case of document-like objects or content descriptions in the case of visual resources.
Of course Rights Management and Description elements can be used to define electronic texts as well as digital images. However, the need for them was felt more keenly by the image community.After elements 14 and 15 were added a decision was made to prevent further element creep. This decision will not be reversed, although there has been some pressure to do it. For instance, a proposal was made to split the Date element into several new elements.
The minimal, simple version of Dublin Core has been stable since DC-3, although detailed usage of a few elements, including for instance Rights Management, has not been decided upon. The majority of time spent in DC-4 and DC-5 workshops has gone into further specification of elements. However, due to the established core of the Dublin Core it is safe to implement the standard now, although the format is still under construction in some fringe areas.
According to the official workshop report (Weibel 97b), the central issues for DC-4 were:
Element Structure: Formal identification of the structure of elements and possible qualifiers is necessary for the specification of any given syntax.
Extensibility Issues: From the beginning of the Dublin Core effort, it was recognized that any core set would require mechanisms for extending the core set both to other functional sets of metadata as well as to richer sets. Without such mechanisms, each variety of metadata becomes a monolith, requiring duplication of effort and resulting in diversification of element sets rather than the convergence necessary to support semantic interoperability.
Element Refinement: Clearer definitions of the semantic content of certain of the elements is necessary (for example, coverage, relation, and rights management).
As has often been the case in Dublin Core workshops, the meeting seemed rather chaotic at times, but surprisingly it ended up with solid consensus on many of the central issues it set out to solve.
Language
Language specifies the language of the element value. If the document itself is written in English this can be pointed out in the Language element. However, if subject headings are provided in English, Finnish and Swedish, this may be specified by using Language qualifier in each individual Subject tag. Coupled with useful internationalization (i18) features in HTML 4.0 like <HTML lang="en">, language qualifier will greatly enhance the capabilities of Web indexes to locate, harvest and index documents in different languages.
Scheme
Stu Weibel has defined scheme as "A formal data content standard or encoding standard with an authoritative maintenance agency". Common examples would be for instance MeSH, UDC and the ISO-8601 profile for encoding date information. The scheme qualifier specifies a context for the interpretation of a given element. Typically this will be a reference to an externally-defined scheme or accepted standard. For example, a SUBJECT field might be SCHEME-qualified as YSA data (Finnish General Subject Headings List).
There are cases in which the scheme qualifier is critical to the use of the field. For instance, scheme is needed for the interpretation of a date. Unambiguous parsing of a date requires knowledge of the encoding standard (i.e. scheme) used in the expression of the content - does the string 1997-10-07 specify the tenth day of July or the seventh day of October (Weibel 97b)? In the same way, classifications put into the Subject tag must be specified with scheme, since otherwise UDC notation like 681.03.06 will not make sense to an application trying to parse it.
From an author's point of view Date is rather unproblematic, provided that there are tools available that support data input by generating the required HTML syntax. Subject is far more complicated, since controlled vocabularies used for content description are usually not available in the Web. We can not assume that authors and publishers will obtain SAB or UDC; instead, these systems must be put on-line and linked to metadata templates. From the IR point of view, it is very important that metadata contains not only decent bibliographic data, but also high-quality content descriptions done with with controlled terms. Because of this, the metadata creator built in the Nordic Metadata project maximises subject scheme support by linking directly to all Web accessible classifications and subject headings lists (see the creator's Subject help page, available at http://www.ub.lu.se/metadata/subject-help.html).
Type
The type qualifier specifies a facet of a given field. The intent of a type qualifier is to narrow the semantics of a an element. Another way of looking at the type is as a sub-element name; a type qualifier modifies the element name, not the content of the element field.
It has been difficult to come up with a universally acceptable list of valid sub-elements. As of yet there is no authoritative specification of Dublin Core sub-elements, although we have agreed on a few principles on how to develop them. The basic axiom is that the sub-elements must narrow the semantics of the (main) element. Due to heavy pressure from the implementor's side this principle has been loosened up a little - it is possible to provide author's mail address in the Creator element. "Legal" sub-elements of Creator include ways of specifying whether the author is a corporation or a person, i.e. the traditional 100/110 division in MARC.
However, one of the results of the Canberra meeting was a list of qualifiers (Guenther). This document has been refined several times since Summer '96, but its task has remained the same:
The following proposes a core set of qualifiers for the Dublin Core element set. It attempts to find a middle ground between the "minimalists" (those wanting a minimum of DC qualifiers and substructure if any) and the "structuralists" (those wanting more precision in refinement of the elements for searching).
The tension between minimalists and structuralists was apparent in early DC development work. Types may be interpreted as additional elements, and by specifying a very large set of them, we may well build into the Dublin Core a complexity that surpasses even that of MARC. Many librarians active in the DC community belonged to the minimalist group. It is as if they were saying, "don't go there - we have been there already".
In the Helsinki metadata workshop, or DC-5, the minimalist-structuralist division was less apparent. Instead, there were people who want to stabilize the simple version of the Dublin Core further as quickly as possible, in order to provide a solid, no-nonsense platform to all implementors. On the other hand, people representing many different metadata "communities" were developing advanced versions of the Dublin Core with the help of qualifiers so as to provide a more effective tools for their own communities. Using a metaphor developed by Tom Baker, a long-time DC activist, one may say that in the beginning the Dublin Core was a pidgin format compared with "real" formats like MARC, but now the DC is on its way of becoming a set of metadata creoles, each one having a lot more expressive power than the simple Dublin Core.
One of the practical outcomes of the Helsinki meeting was the decision to establish a sub-elements working group. The statement of purpose of this group is stated below:
The purpose of this proposal is to establish a set of approved optional subelements for the Dublin Core. The list is not exclusive, nor complete, but represents common best practice as currently perceived within the implementation community. Current and future implementors are provided with a framework within which they may place further (discipline or application specific) subelements as required.
From an implementor's point of view it is very important that basic subelements are agreed on, since from the point of view of metadata creation, harvesting, indexing and conversion, subelements are of vital importance. Production of decent metadata and subsequent conversion of Dublin Core records to MARC would be very cumbersome if implementors had to stick with unqualified DC. The same applies, but to a lesser degree, to schemes. As a scheme has to be a nationally or internationally recognized system, the only requirement is that we need a register of scheme values in order to avoid duplication of data. For instance, "NBN" for the National Bibliography ID number can only be used in one country. Other countries need to add country code (i.e. "FI-NBN") or something else so as to differ from the plain NBN.
In the DC-4 meeting there was a wide consensus in the group that it is necessary to include specific means for providing Dublin Core data in HTML into the HTML standard. With the introduction of HTML 4.0 as an Internet standard (see Raggett) this will be possible, thanks to the following new attributes of the META tag:
SCHEME: This attribute names a scheme to be used to interpret the property's value, and
LANG: language tagging based on RFC 1766, Tags for the Identification of Languages.
So it is possible to create for instance the following meta tag:
<META name="DC.subject" scheme = "YSA" lang="fi" content="luettelointi">
or
<META name="DC.subject" scheme = "LCSH" lang="en" content="cataloging">
Over the years there have been several different ways of coding type qualifiers into a HTML META tag. Before the Canberra meeting, a valid Dublin Core Author tag looked like this:
<META NAME="DC.author" CONTENT="(TYPE=name) Hakala, Juha">
In the Canberra meeting, it was felt that it is not a good idea to clutter data content with type specification. In order to avoid this, a mechanism called dot syntax was invented. With dot syntax, type qualifiers, or sub element names, are incorporated into the element name separated with a dot. The above data in the new syntax looks like this:
<META NAME="DC.creator.name" CONTENT="Hakala, Juha">
People using templates to create Dublin Core metadata perhaps have not even noticed the difference, but organisations building applications which handle Dublin Core data must be prepared for the changed data. Moreover, it seems this version of the dot syntax was not the last one. With the introduction of the Resource Description Framework - which will be briefly described later in this article - it became necessary to start element and subelement names with capital letters, so a valid author tag looks now like this:
<META NAME="DC.Creator.Name" CONTENT="Koch, Traugott">
It should be pointed out that normalizing personal names during data input (i.e. "first name, last name) is by no means a generally agreed convention, but just a recommendation of the Nordic Metadata project. From the point of view of searching it does not really matter if names are normalized or un-normalized, but this is a big issue for MARC conversion programs. Generally, nothing like AACR2 neither exists for the Dublin Core, nor is likely to appear in near future. Therefore, it is important that Dublin Core users in Nordic countries agree on basic principles of how to catalogue things. The Nordic Metadata group has done some basic work in this area, but a lot more remains to be done on a national level. For instance in Finland we need a recommendation of how to put Finnish General Subject Headings into a DC Subject tag.
The DC-4 developed a means of expressing private elements and/or qualifiers. These may be needed to extend the semantics of the basic Dublin Core. The mechanism to add private "stuff" is based on the common Internet method called X referencing. Any private element or qualifier name must start with "X-". For instance, if we want to add price information to a DC record, we can do it by adding an element "X-Price". Generic metadata harvesting applications will recognize this information is internal and will not touch it. On the other hand, a Finnish DC-> FINMARC converter can be taught to put the value of this element into the 021 subfield $d in the MARC record.
Element refinement has been an on-going process almost since the invention of the Dublin Core. A lot of intellectual work has been put into problem specification - without a solid basis it is hard to make progress in this area. Significant results were achieved in this area in the Helsinki workshop. As said earlier, by now most elements are stable, but for instance Date, Source and Relation still require some work.
I will provide here an example of what element refinement means in practice by presenting current thinking on the Date element within the DC community. Date has been a difficult element to specify properly, partly because electronic documents pose quite a few additional complications to what used to be a rather simple task in the past with printed documents. The relative simplicity of date in printed world is reflected for instance in the simplistic way MARC formats handle dates.
In the Helsinki meeting a decision was made to establish a Date sub-group. The most important task of this group is to finish naming and defining the Date types (sub-elements). In November 1997 there were the following candidates:
1. DC.Date.ContentCreated
Date of creation of the intellectual content
2. DC.Date.VariantCreated
Date of creation or modification of the resource in its present form
3. DC.Date.Issued
Date of formal publication (eg, copyright) of the resource
4. DC.Date.Available
Date that the resource will become or did become available
5. DC.Date.Valid
Date (often a range) of validity of the resource
6. DC.Date.Accepted
Date of acceptance (eg, dissertation or treaty) of the resource
7. DC.Date.DataGathered
Date of sampling of the information in the resource
8. DC.Date.Acquired
Date of acquisition or accession
Please note that date information as subject is put into Subject or Coverage.
It is also important to agree on which date presentation standard to use and in which manner. A decision has been made to use ISO 8601 as the base standard; a profile has been written of how to use the standard in applications. See (Kuhn) for more information on ISO 8601.
Now, the Dublin Core was supposed to be a simple and easy-to-use metadata format, but "creolization" is paving the way for complexity. The driving force behind this development is diversity of actual and potential Dublin Core user communities and their needs. In order to be able to provide meaningful descriptions in different environs, it is necessary to introduce complexity into the format. Luckily implementors will not need to utilize all the features that will be built into the Dublin Core, although leaving things out from a local implementation will degrade interoperability to some extent.
One interesting question that arises from the current Dublin Core activity is whether the MARC community should follow in, for instance, making date presentation less simplistic? The Dublin Core development may turn out to be very fruitful to other formats as well. On the other hand, the Dublin Core has definitely benefited from other formats, and will do so in the future. For instance, work on Relation element seems to be heading towards the direction set by IFLA in the Functional Requirements for Bibliographic Records -report (see http://www.nlc-bnc.ca/ifla/VII/s13/frbr/frbr-toc.htm).
Many of the international guests were visiting Finland for the first time, and for at least one overseas guest this was his very first trip to Europe. Helsinki is perhaps not at its best in October, but then it was easier to concentrate on work than in summer.
While the invitational DC workshop was meant for the initiated, the 2nd Nordic Metadata Workshop arranged on 9 October provided an unique opportunity to learn about Dublin Core from the person who is by many regarded to be the father of the format, Stuart Weibel.
The main objectives for DC-5 were:
Element refinement and stability. As seen from the above, good progress have been made but it is still a little early to talk about stability. Of course stability of a format is a relative thing. Any format is "work in progress - for instance MARC formats are being modified all the time, as new kinds of materials are included in them.
Define sub-elements and resource types. After the Helsinki meeting, we are now much closer to an agreement on sub-elements, or types.
Share implementation experiences. The Dublin Core is not experimental anymore - more that 30 projects sent their descriptions.
Most of these issues have already been discussed above, and the current status has been described. Here I will concentrate on DC implementations. But at the beginning some time was spent on informational presentations and it is well worth giving an overview of this here.
Clifford Lynch, who presented this issue in the meeting, thought that adding new attributes is not the correct solution. The fact that MARC and Dublin Core both have "Title" or "Subject" does not mean that these elements have precisely the same semantic content. On the other hand, there are plans in the Z39.50 implementor's group to revise Bib-1 into something quite different, so extending the current Bib-1 would only be a temporary solution. The best solution will very likely be development of a new attribute set for the Dublin Core. We would then have the Bib-1 (or Bib-2) attribute set, optimized for MARC data, and DC-1 or something like that for DC data.
The only problem of this solution is interoperability. Client applications providing access to MARC- and Dublin Core -databases need to support two attribute sets. This should not be too hard, since the differences will not be too apparent at the user interface level, which will in both cases provide for instance Author, Subject and Title searches. There is no guarantee that the semantic content of for instance "Subject" or "Author" will be the same in DC- and MARC-bases, but the same problem exists also between different MARC (or DC) databases, due to diverse content of bibliographic databases.
According to the RDF model and syntax specification (Miller) the Resource Description Framework is
a foundation for processing metadata; it provides interoperability between applications that exchange machine-understandable information on the Web. RDF emphasizes facilities to enable automated processing of Web resources. RDF metadata can be used in a variety of application areas; for example: in resource discovery to provide better search engine capabilities; in cataloging for describing the content and content relationships available at a particular Web site, page, or digital library; by intelligent software agents to facilitate knowledge sharing and exchange; in content rating; in describing collections of pages that represent a single logical "document"; for describing intellectual property rights of Web pages, and in many others.
RDF has rather mundane roots; it is based on the W3 organization's earlier activity called PICS (Platform for Internet Content Selection) which aimed at providing a means for blocking (or picking) some materials from the Web based on some kind of content description. This metadata on resources must be harvested and indexed one way or another. The original motivation for this activity came from the need to prevent kids from accessing suspectible sites like porn services.
RDF has a very wide scope; it seems to be on its way of becoming a very widely used means for the exchange and processing of metadata. This metadata can arrive in the Dublin Core and many other formats; the Warwick Framework conceived in DC-2 will be utilized to facilitate metadata transfer on the Web. An important factor here is that RDF tools will be ubiquitous - they will be built into Web browsers and servers and into HTML editors. For instance Netscape and Microsoft are building RDF applications already. There are other organisations interested in RDF as well - it was interesting to see that one of the editors of the RDF model specification comes from the Nokia company.
While the main motivation to start RDF activity or the earlier PICS initiative has been to protect minors from unsuitable materials the RDF mechanism can be used for many other purposes. RDF will facilitate creation and harvesting of Dublin Core -based metadata, and the necessary tools will be provided for us for free, as a part of applications we use every day. This explains why the Dublin Core community is very interested in RDF and has in fact participated in its creation from the very beginning.
When printed this document is more than 60 pages long; I will just summarize some central points here.
In spite of the criticisms real-life implementors of the Dublin Core were quite happy with it, and did not see any alternative to it in their current projects.
At the moment I feel it's safe to say that the project has been successful, especially from the technical point of view. Seldom has a Nordic library IT project attracted as much international interest as this rather small project. One proof of the high status of the Nordic Metadata was the decision to arrange the 5th Dublin Core workshop in Helsinki.
What have we done, then? The project's main aim was and still is to develop tools for creation, harvesting and indexing of Dublin Core -based metadata. We have very few resources for the actual creation of metadata, and rely on other projects like INDOREG in that area.
Our tools and their addresses are:
The template was originally developed with the Nordic Metadata resources, but has since been improved with resources NetLab (which is responsible for the metadata template and database development) has received from another metadata projects it is involved with. We have therefore accomplished more than we originally believed we could.
The project has also developed user guides (unabridged and simple) for Dublin Core metadata producers. Further work is needed in this area, since in order to make the guides really useful we need to modify them according to the local needs. For example, the Finnish guide must contain information on how to provide Finnish General Subject Headings terms. It is also necessary to translate the guides into the domestic languages.
There are currently two metadata databases: Swemeta and Danmeta, for Sweden and Denmark. These contain 80,000 records, of which only a fraction are in the Dublin Core. We intend to build metadata databases for Finland and Norway before the project is over. It should be noted that metadata databases are separate from the full-text database for obvious reasons - if all data were stored in one database, we would lose the main benefit of metadata, enhanced precision of searches.
The DC->MARC converter has been built by Ole Husby from Bibsys. During development work it became obvious that the task of creating a fully satisfactory converter is more challenging than anticipated. There are no resources in the project left to make the converter fully table-driven, which means that conversion changes must be made directly into the program code.
The opportunity to follow the emergence of the Dublin Core has been a very interesting experience. As a result of the Nordic Metadata and other metadata initiatives the Nordic countries are now well prepared to participate actively in the developments, and make sure that we are among the early implementors of useful new tools built by the Internet metadata community.
Guenther, Rebecca: Dublin Core Qualifiers/Substructure. 15 October 1997. Electronic document, available at: http://lcweb.loc.gov/marc/dcqualif.html
Koch, Traugott [et al.]: Warwick framework and Dublin core set provide a comprehensive infrastructure for network resource description. Nordinfo-nytt vol. 19 (1996) no. 2 s. 40-48. Electronic version available at: http://www.bibsys.no/warwick.html
Lagoze, Carl: The Warwick Framework: A Container Architecture for Diverse Sets of Metadata. D-Lib Magazine, July/August 1996. Electronic document, available at: http://mirrored.ukoln.ac.uk/lis-journals/dlib/dlib/dlib/july96/lagoze/07lagoze.html
Kuhn, Markus: A Summary of the International Standard Date and Time Notation. Electronic document, available at: http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html
Miller, Eric [et al.]: Resource Description Framework (RDF) Model and Syntax. 2 October 1997. Electronic document, available at: http://www.w3.org/TR/WD-rdf-syntax/
Raggett, Dave [et al.]: HTML 4.0 Specification. W3C Proposed Recommendation 7-Nov-1997. Electronic document, available at: http://www.w3.org/TR/PR-html40/
[Weibel 96] Weibel, Stuart: A Proposed Convention for Embedding Metadata in HTML. Electronic document, available at: http://purl.oclc.org/docs/metadata/dublin_core/approach.html
[Weibel 97a] Weibel, Stuart & Miller, Eric: Image Description on the Internet. A Summary of the CNI/OCLC Image Metadata Workshop. September 24 - 25, 1996, Dublin, Ohio. D-Lib Magazine, January 1997. Electronic document, available at: http://www.dlib.org/dlib/january97/oclc/01weibel.html
[Weibel 97b] Weibel, Stuart, Iannella, Renato & Cathro, Warwick: The 4th Dublin Core Metadata Workshop Report. D-Lib Magazine, June 1997. Electronic document, available at: http://www.dlib.org/dlib/june97/metadata/06weibel.html