|Description:||This position paper grew out of discussion at a meeting of the Working Group on 25 May 1998 at the German National Research Center for Information Technology in Bonn, Germany and was revised after a meeting on 6 September 1998 at the Asian Institute of Technology in Bangkok, Thailand.|
Note: This is a provisional version for discussion only; points 6 through 8 have not been approved by the group as a whole.
This position paper grew out of discussion at a meeting of the Working Group on 25 May 1998 at the German National Research Center for Information Technology in Bonn, Germany and was revised after a meeting on 6 September 1998 at the Asian Institute of Technology in Bangkok, Thailand.
The Working Group on Dublin Core™ in Multiple Languages takes the following position:
The reference language of the international Dublin Core™ community is English inasmuch all of its outputs are discussed and approved in English. Accordingly, the English version of the Dublin Core™ has a special status as the canonical result of an international process.
However, the semantics of Dublin Core™ elements are in principle expressible equally well in any modern language. We hesitate to call versions of the Dublin Core™ in languages other than English "translations." Rather, these versions could function as reference definitions in their own right, as objects of discussion, adaptation, and extension in locally specific ways. Like any good translation, moreover, such versions need not be word-for-word literal as long as they convey the essence of the canonical definitions in ways that make sense to their readers.
People currently associate "the Dublin Core™" with a standard in English. We would like to call the sum of instantiations of the Dublin Core™ in various languages "Multilingual Dublin Core," or "DC-Multilingual." One might think of the metadata semantics shared within DC-Multilingual to be, in some sense, independent of any particular language, hence universal.
The versions of Dublin Core™ elements in various languages should share a single namespace. According to a decision of the Dublin Core™ Data Model Working Group of October 1998 [DCDM], that namespace will be: http://purl.org/dc/elements/1.0/ The portion "purl.org/dc" may change in the future.
As defined in the RFC for Unqualified Dublin Core™ [RFC], Dublin Core™ elements consist of a descriptive name (eg, "Author or Creator"), a single-word label or "token" for use in encoding schemes (eg, "Creator"), and element definitions. The descriptive names and element definitions are meant to be read primarily by humans, the tokens primarily by machines. The tokens look like English words but stand for universal elements. Universal elements can have interchangeable names and definitions in multiple languages.
A version of the Dublin Core™ in French (DC-French) at http://www.inria.fr could have universal elements -- canonical elements with translated definitions and names -- and elements that are specific to DC-French. Universal elements would use the Dublin Core™ namespace (here, http://purl.org/specifications/dublin-core/rec-dces-199809.htm ), while local elements would use a namespace such as http://www.inria.fr/metadata/dublin_core_elements.
As of September 1998, it seemed that the definition of the Title element in a (hypothetical) RDF schema of DC-French at http://www.inria.fr would look like this:
<RDF:instanceOf RDF:HREF="http://www.w3.org/TR/WD-RDF-Syntax#PropertyType"/> <RDFS:necessity RDF:href="http://www.w3.org/TR/WD-RDF-Schema#ZeroOrMore"/> <RDFS:Comment XML:LANG="fr">Le nom donné à la ressource par le créateur ou l'auteur.</RDFS:Comment> </RDF:Description>
<rdf:RDF xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax#" xmlns:rdfs="http://www.w3.org/TR/WD-rdf-schema#"> xmlns:rdfs="http://purl.org/dc">
<rdf:Description about="http://purl.org/dc#Title"> <rdfs:label xml:lang="fr"> Titre </rdfs:label> <rdfs:comment xml:lang="fr"> Le nom donné à la ressource par le créateur ou l'auteur. </rdfs:comment> </rdf:Description>
<?xml:namespace ns="http://purl.org/metadata/dublin_core_elements" prefix="DC"?> <RDF:RDF> <RDF:DESCRIPTION RDF:HREF="http://www.biblio.de/buecher/kleist.html"> <DC:Title XML:lang="de">Das Erdbeben in Chili</DC:Title> <DC:Creator>Heinrich von Kleist</DC:Creator> </RDF:Description> </RDF:RDF>
It is not clear whether machine-readable RDF schemas should be embedded in human-readable HTML documentation files or kept separate. For now we should keep these separate so that we more easily can change them when we know what is required.
It is not clear whether the namespace name (see #4 above) should point to an RDF schema file or to a Web page in HTML. Perhaps element definitions could be dynamically extracted from an RDF file to an HTML file, or vice versa. Moreover, the draft XML Namespaces specification [XML] makes a distinction between a namespace name and an optional URI that points to a schema. This is clearly a question for further research. Either way, what the namespace name points to can change over time, so we can go ahead and write metadata with confidence.
Versions of the Dublin Core™ in other languages should cite the specific English version on which they are based (eg, 1.0, 1.1, 2.0...), as that canonical version will evolve over time. For example, the Dublin Core™ could grow to have more than fifteen elements. Perhaps one could give each new version its own URI. Exactly how versioning should be implemented is a question for the Dublin Core™ community as a whole.
Links from the central namespace server to versions in other languages should be machine-parsable. It should be possible for users to transmit a preference for the Finnish language and automatically get in return the URI for DC-Finnish. As of September 1998, it is unclear whether users should then be encouraged to load their Dublin Core™ element names and definitions through the central registry or directly from Helsinki.
We are embarking on a period of experimentation, during which we should invite metadata-using institutions in many countries to create versions of Dublin Core™ in various languages. Regional language or institutional differences may occasionally result in the creation of multiple versions of Dublin Core™ in any given language, but we see no reason to place restrictions on this at present. Eventually we may need a process for evaluating such versions, with peer review for quality and some verification of an institution's commitment to maintaining a version in the long term. Versions that pass could be "certified" by the Dublin Core™ community as a whole.
DC-Multilingual should be a forum for sharing and negotiating metadata semantics across languages. An extension originally defined in Thailand could be incorporated into the universal version and be used worldwide.
Process and deliverables
The distributed registry should start with versions of Unqualified Dublin Core™ in multiple languages. Sub-elements should not be implemented before the Dublin Core™ community ratifies versions of Qualified Dublin Core™. However, the Dublin Core™ community urgently needs to define a process to do this before the proliferation of incompatible sub-elements compromise global interoperability.
DC-Multilingual should comply with the RDF specifications as they evolve. Indeed, it could provide RDF with a model application that is high-profile, international, and vendor-neutral. The DC-Multilingual community, in turn, should communicate its evolving requirements back to the RDF Working Group for consideration in future versions of RDF.
The distributed registry of DC-Multilingual will be implemented by the Working Group on Dublin Core™ in Multiple Languages in close consultation with Dublin Core™ advisory committees, the RDF Working Group, and the Dublin Core™ community as a whole (as represented by the periodic workshops and by the dc-general mailing list). The Working Group will maintain a Web page at http://dublincore.org/ and conduct discussions on the dc-international mailing list ( http://www.jiscmail.ac.uk/lists/dc-international.html)
Local implementors are strongly encouraged to develop projects that enhance or extend the capabilities of the registry. In addition to schemas, such sites could eventually hold downloadable templates, metadata editors, Java utilities, user guides, enumerated lists, crosswalks to other element sets, and controlled vocabularies.