innovation in metadata design, implementation & best practices

DCMI Localization and Internationalization Community

Meeting Report: Working Group on Dublin Core in Multiple Languages (DCML)

Asian Institute of Technology, Bangkok, Thailand
Date of meeting:
Thomas Baker (, Chair/Rapporteur
Thomas Baker (, Chair/Rapporteur
Tetsuo Sakaguchi (
Shigeo Sugimoto (
Han Suk Choi (
Koichi Tabata (
Asanee Kawtrakul (
Wu Xiaoyun (
Chutiporn Anutariya (
Bagus Tri Prabawa (
Xu Bo (
Edie Rasmussen (
Fytton Rowland (
Vilas Wuwongse (


This meeting in Bangkok followed a meeting of the DCML Working Group on Monday, 25 May 1998, at the German National Research Center for Information Technology in Bonn, Germany. The result of the Bonn meeting had been a position paper for the Working Group that articulated assumptions about the status of Dublin Core versions in multiple languages and laid out a plan of action. Discussion and endorsement of this position paper was one of the key objectives of the meeting in Bangkok.

Another objective of the Bangkok meeting was to evaluate and discuss a simple registry prototype prepared by Tom Baker and Xu Bo at AIT. This prototype was designed to let users request a version of Dublin Core in a particular language from a central registry, which would retrieve that version from a local registry (eg, in Bangkok, Beijing, or Berlin) and display it on the user's Web browser. Browsers enabled for Java would display versions in certain fonts (eg, Thai and Japanese) using MHTML, a Java suite developed at the University for Library and Information Science in Tsukuba, Japan. Technical aspects of this MHTML implementation were discussed at the meeting with members of the MHTML development team.


  1. The participants generally endorsed the position paper ("DC-Multilingual: plans for a distributed registry of Dublin Core in multiple languages," version of 14 July 1998). Exceptions and comments follow below.
  2. The RDF schema will soon support human-readable labels (Point 7), partly as a result of this group's recommendation.
  3. The DC Datamodel Working Group is currently discussing a proposal to define separate name spaces for Unqualified and Qualified Dublin Core (DC and DCQ). It was agreed that the DCML position paper should be revised to reflect this as soon as the Datamodel working group takes a formal decision.
  4. Point 12 of the position paper suggests that users should get a URI for DC-Finnish from the central registry and "henceforth load Dublin Core element names and definitions from Helsinki." However, one might argue that users should always load these using the URI for the central DC namespace. It was acknowledged that this will require further discussion.
  5. The local registries will often want to put up Web pages placing the Dublin Core in context and providing guidelines for usage. Perhaps the DCML working group should develop recommendations for the content of these Web sites.
  6. Point 15 says that a distributed registry should start with Simple Dublin Core and that sub-elements should not be implemented before the Dublin Core community ratifies versions of Qualified Dublin Core. However, implementors are busy defining such sub-elements (eg, for DC-Korean) and have no systematic way to monitor how others are doing this. The registry should begin covering sub-elements as soon as possible to prevent the duplication of effort, the proliferation of incompatible sub-elements, and (as a result) divergence in usage.