Diann Rusch-Feja
Entwicklungsgeschichte des Dublin Core
In den letzten zwei Jahren ist das Konzept "Metadaten zur Erschließung von digitalen Ressourcen" im Rahmen des Dublin Core1) gereift. Ursprüngliches Ziel der Bemühungen von Bibliothekaren, Informationswissenschaftlern, Informatikern und Systemspezialisten war es, einen Minimalsatz von Erschließungselementen zu definieren, die zur verbesserten Präzision und Retrievalfähigkeit digitaler Dokumente bei Recherchen im Internet, z. B. mittels Suchmaschinen, verhelfen konnten2). HTML-Dokumente und dokumentenähnlichen Objekte (DLO)3) sollten mit eingebetteten formalen und inhaltlichen "Metatags" im Header des Dokuments versehen werden, die jedoch nicht beim normalen Display durch den Browser angezeigt werden. Sie sind nur bei der Anzeige des Quelltextes ("View Source") für das menschliche Auge zu sehen, können aber von den sog. Suchmaschinen, Robotern und Gatherern gelesen und gesammelt werden. Wichtig für die erste Entwicklung des Dublin Core war eine fachübergreifende Übereinstimmung, daß die Aufgabe, die Erschließungs- und Retrievalaspekte für digitale DLO's zu präzisieren, durch eine Basisbeschreibung erfüllt werden könnte. Um die weitreichenden Möglichkeiten des neuen Mediums Internet zu nutzen, wurde das Konzept bald erweitert, um Bilddateien und andere Arten von Dateien einzuschließen. Somit konnten inhaltliche und formale Anfragen (nach Namen, Institutionen) gezielter zum Suchergebnis kommen. So sollen alle Arten von Medien miteinbezogen werden, die vorher in medien-getrennten Sammlungen ("Repositories") oder gar nicht erschlossen wurden (z. B. Bibliotheken und Bibliothekskataloge, Museen, Bildarchive etc.).
Der erste Dublin Core Metadata Workshop fand im März 1995 unter der Schirmherrschaft von OCLC und des US National Center for Supercomputing Applications (NCSA) in Dublin (Ohio) statt4). Ergebnis dieses Workshops war die semantische Definition eines Kernsatzes von 13 formalbibliographischen und inhaltlichen Elementen, die gezielt zur Beschreibung digitaler und digitalisierter Gegenstände angewandt werden können. Im zweiten Workshop, der von OCLC und UKOLN (United Kingdom Online Library Network) im April 1996 in Warwick (GB) veranstaltet wurde, konnte die Dublin Core Metadata-Diskussion im Kontext gleichzeitiger Anwendung mehrerer Metadaten-Pakete für verschiedene Zwecke und Suchmechanismen besprochen werden. Daraus entwickelte sich dann das umfangreichere Warwick Framework, ein Rahmenmodell, das eine Struktur für die gleichzeitige Anwendung verschiedener Metadaten-Formate, -Schemata und -Coverage-Ebenen vorsieht5). Bei diesem Workshop wurde auch ein Syntaxformat für Dublin Core-Metadaten normiert6).
Parallel zu den Dublin Core-Bemühungen, Metadaten zur Beschreibung von Internet-Ressourcen zwecks Recherche und Retrieval zu definieren, liefen eine Reihe von weiteren, voneinander unabhängigen Bemühungen, verschiedene Metadaten für Internet-Ressourcen zu implementieren. So besprachen Experten die Benutzung von Metadaten im Rahmen der NSF-Digital Libraries Initiative (DLI) November 1995 bei einem DLI-Treffen an der Alexandria-Projektstelle für die Erfassung und Erschließung von geowissenschaftlichen Objekten in der Universität von Kalifornien in Santa Barbara. Im Mai 1996 fand ein Workshop des World Wide Web Consortium (W3C) in Cambridge, Mass., statt, der sich mit der Indexierung und Suchpräzisierung von Internet-Ressourcen beschäftigt hat7). Die Ergebnisse dieses Workshops bestätigen die Ansätze des Dublin Core, zielen jedoch eher auf die weiteren Entwicklungen der Suchmaschinen- und Roboter-Technologie. Bei diesem Workshop wurden Ansätze gemacht, Regelungen für die Einbettung von Metadaten in HTML aufzustellen, sowie Registries für Metadaten einzurichten8).
Auch in den US-Regierungsstellen, wo bereits seit 1995 die Verpflichtung zur Erstellung aller "Druck"-Erzeugnisse der Regierungsstellen in digitaler Form und zur Verfügbarkeit über das Internet besteht, wurde es ab dem 1. Januar 1997 auch Pflicht, diese digitalen Dokumente mit Metadaten nach dem Format US Government Information Locator Service (GILS) zu versehen9). Da viele dieser digitalen Dokumente Satelliten- und andere Bilder sowie statistische und kartographische Werke waren, stand im September 1996 der dritte Workshop in der Dublin Core-Reihe vor der Hintergrundfrage, ob die Dublin Core-Elemente auch für diese Art von digitalisierten / digitalen geowissenschaftlichen Dokumenten/Objekten angewandt werden können. Die TeilnehmerInnen beim CNI/OCLC Metadata Workshop on Metadata for Networked Images10) in Dublin, Ohio prüften die Dublin Core-Elemente, ob sie Museumsobjekte, Bilder, Tabellen, Wirtschaftsgraphiken, dreidimensionelle CAD/CAM, kartographische und geowissenschaftliche Abbildungen ohne allzu große Modifikation beschreiben konnten. Sie stellten fest, daß die Dublin Core-Elemente mit wenigen Qualifizierungen auch für Bild- und andere visuelle Gegenstände im Netz sinnvoll angewandt werden können.
Projekte in Großbritannien11), Skandinavien12) und Australien13) fingen bereits 1996 mit der Implementierung von Dublin Core-Metadaten an. Weitere Projekte in Deutschland bei den Fachgesellschaften14) bauten bereits Preprint-Server und andere Datenbanken für elektronische Publikationen und Softwaresammlungen auf, die mittels Metadaten ausgewertet werden können, die zunächst mit eigenen Charakteristika an die Dublin Core-Elemente angelehnt waren. Nach den ersten zwei Workshops in Deutschland15) wurden jedoch die Metadatenformate auf das Dublin Core umgestellt16).
Diskussionen über die Struktur und Unterteilung der einzelnen Dublin Core-Elemente nahmen von Oktober bis Anfang Dezember 1996 zu. Nach einem Meinungsbildungsprozeß in der Diskussionsliste für das Dublin Core wurde entschieden, den ursprünglichen Kernsatz von 13 Elementen17) um zwei Elemente nach allgemeinem Konsens zu erweitern.
Die 15 Dublin Core Elemente
In Klammern steht der englische Begriff des Elements (Label) des Dublin Core Element Reference Set. Die 15 Elemente mit den derzeitigen Erläuterungen nach dem englischen Vorbild18) sind:
1. Titel (DC.TITLE)
Titel der Quelle; der vom Verfasser, Urheber oder Verleger vergebene Name der Ressource.
2. Verfasser oder Urheber (DC.CREATOR)
Die Person(en) oder Organisation(en), die den intellektuellen Inhalt verantworten. Z. B. Autoren bei Textdokumenten; Künstler, Photographen bzw. auch andere Bezeichnungen wie Komponist und Maler bei graphischen Dokumenten.
3. Thema und Stichwörter (DC.SUBJECT)
Thema, Schlagwort, Stichwort. Das Thema der Ressource bzw. Stichwörter oder Phrasen, die das Thema oder den Inhalt beschreiben. Die beabsichtigte Spezifizierung dieses Elements dient der Entwicklung eines kontrollierten Vokabulars. Das Element kann sowohl systematische Daten nach einer Klassifikation (scheme) wie Library of Congress Klassifikations-Nummer oder UDC-Nummer oder Begriffe aus anerkannten Thesauri (wie MEdical Subject Headings (MESH) und Art and Architecture Thesaurus (AAT) Deskriptoren) enthalten.
4. Inhaltliche Beschreibung (DC.DESCRIPTION)
Eine textliche Beschreibung des Ressourceninhalts inklusive eines Referats (Abstract) bei dokumentähnlichen Ressourcen oder Inhaltsbeschreibungen bei graphischen Ressourcen. Künftige Metadata-Sammlungen können auch numerische Inhaltsbeschreibungen (z. B. Spektralanalyse einer graphischen Ressource) enthalten, die eventuell noch nicht in bestehende Netzsysteme eingebettet werden können. In solchen Fällen kann dieses Feld einen Link zu einer solchen Beschreibung enthalten statt der Beschreibung selbst.
5. Verleger bzw. Herausgeber (DC.PUBLISHER)
Die Einrichtung, die verantwortet, daß diese Ressource in dieser Form zur Verfügung steht, wie z. B. ein Verleger, ein Herausgeber, eine Universität oder ein korporatives Unternehmen. Der Zweck bei der Benutzung dieses Felds ist es, die Einrichtung oder Einheit zu identifizieren, die den Zugang zur Ressource gewährt.
6. Weitere beteiligte Personen und Körperschaften (DC.CONTRIBUTORS)
Zusätzliche Person(en) und Organisation(en) zu jenen, die im Element 2 (DC.CREATOR) genannt wurden, die einen bedeutsamen intellektuellen Beitrag zur Ressource geleistet haben, deren Beitrag aber sekundär im Verhältnis zu denen im Element 2 (DC.CREATOR) zu betrachten ist (z. B. Herausgeber, Übersetzer, Illustratoren, auch Konferenzleiter, Moderatoren).
7. Datum (DC.DATE)
Das Datum, an dem die Ressource in der gegenwärtigen Form zugänglich gemacht wurde. Der empfohlene Eintrag des Datums wäre eine achtstellige Zahl JJJJMMTT, wie es in ANSI X3.30-1985 definiert ist, beispielsweise: 19961213 (=13. Dezember 1996). Andere Darstellungsschemata für das Datum sind erlaubt; werden sie angewandt, so sollten sie eindeutig identifiziert werden [über SCHEME]19), damit keine Fehlinterpretationen auftreten.
N.B.: Beim 4. Dublin Core Workshop (DC4) wurde entschieden, dieses Element etwas offener, jedoch noch stark restriktiv zu definieren, und zwar in einer Unterteilung von zumindest DC.DATE.CREATION (Datum der Herstellung bzw. erstmaligen Veröffentlichung im Netz) und DC.DATE.LASTMODIFIED (Datum der letzten Änderung). Eine DC4-Arbeitsgruppe prüft z. Z., ob weitere Unterteilungen zu empfehlen sind.
8. Ressourcenart (DC.TYPE)
Die Art der Ressource, z. B. Homepage, Roman, Gedicht, Arbeitsbericht, technischer Bericht, Essay, Wörterbuch, wird hier eingetragen. Es wird erwartet, daß die Angabe für dieses Feld aus einer definierten Liste von Ressourcenarten entnommen wird. Eine vorläufige Liste solcher Ressourcenarten ist unter der URL <http://www.roads.lut.ac.uk/Metadata/DC-ObjectTypes.html> zu finden.
N.B.: Die offizielle Liste von zulässigen Angaben zum "TYPE" wird noch in einer in Canberra konstituierten Arbeitsgruppe zusammengestellt, und zwar auch in Hinblick auf bestehende Formschlagwort-Normdateien. Sobald diese zur Verfügung steht, wird auf sie in der Web-Seite für die deutsche Übersetzung (s. Anm. 18) hingewiesen.
9. Format (DC.FORMAT)
Hier wird das datentechnische Format der Ressource eingetragen, z. B. Text/HTML, ASCII, Postscript-Datei, ausführbare Anwendung, JPEG-Bilddatei etc. Die Angabe in diesem Feld gibt die erforderlichen Informationen, die Menschen oder Maschinen ermöglichen, über die Verarbeitungsmöglichkeiten der kodierten Daten zu entscheiden (z. B. welche Hard- und Software benötigt werden, um diese Ressource anzuzeigen bzw. auszuführen). Ähnlich wie bei der Ressourcenart (TYPE) soll die Angabe in diesem Feld (FORMAT) aus festdefinierten Listen, wie die der angemeldeten Internet Media Types (MIME Types) entnommen werden. Grundsätzlich können Formate auch physische Medieneinheiten wie Bücher, Zeitschriften oder andere nicht elektronische Medien mit einschließen.
10. Ressourcen-Identifikation (DC.IDENTIFIER)
Hier wird eine Zeichenkette oder Zahl eingetragen, die diese Ressource eindeutig identifiziert. Beispiele für vernetzte Ressourcen sind URLs und URNs (wo verwendet). Andere weltweit eindeutige Identifikationen, wie die International Standard Book Number (ISBN) oder andere formale Namen wären weitere mögliche Bezeichnungen, die in dieses Element eingetragen werden können.
11. Quelle (DC.SOURCE)
In diesem Element wird - falls nötig - das gedruckte oder elektronische Werk, aus dem diese Ressource stammt, eingetragen. Zum Beispiel, bei einer HTML-Datei eines Sonetts von Shakespeare könnte hier die gedruckte Version der Sonetts als Quelle angeben werden, die als Vorlage für die Erstellung der HMTL-Datei benutzt wurde.
12. Sprache (DC.LANGUAGE)
Hier werden die Sprache(n) des intellektuellen Inhalts dieser Ressource vermerkt. Der Inhalt dieses Felds sollte möglichst mit den dreistelligen Z39.53-Sprachcodes übereinstimmen. (Siehe: <http://www.sil.org/sgml/nisoLang3-1994.html>)
13. Beziehung zu anderen Ressourcen (DC.RELATION)
Die Angabe in diesem Feld ermöglicht es, Verbindungen unter verschiedenen Ressourcen darzustellen, die einen formalen Bezug zu anderen Ressourcen haben, aber als eigenständige Ressourcen existieren. Beispiele sind Bilder in einem Dokument, Kapitel eines Buches oder Einzelstücke einer Sammlung. Eine formale Spezifizierung (Referenzliste) für dieses Element ist in Arbeit. Benutzer und Entwickler sollten dieses Feld noch als experimentell betrachten.
14. Räumliche und zeitliche Maßangaben (DC.COVERAGE)
Hier werden Angaben zur räumlichen Bestimmung (z. B. geographische Koordinaten) und zeitlichen Gültigkeit eingetragen, die die Ressource charakterisieren. Formale Spezifizierungen für COVERAGE werden z.Zt. erarbeitet20). Benutzer und Entwickler sollten dieses Element noch als experimentell betrachten.
15. Rechtliche Bedingungen (DC.RIGHTS)
Vorgesehen für den Inhalt dieses Elements ist ein Link (URL oder andere passende URI soweit zutreffend) zu einem Urhebervermerk, ein "Rights-Management"-Vermerk über die rechtlichen Bedingungen oder ggf. zu einem Server, der solche Informationen dynamisch erzeugt. Die Angaben in diesem Feld ermöglichen es Informationsanbietern, die Verbindung von Bezugs- und Benutzungsbedingungen sowie rechtlichen und abrechnungsbedingten Voraussetzungen oder Urhebervermerken mit einer entsprechenden Ressource oder einer Sammlung von Ressourcen herzustellen. Nutzer dieses Feldes sollten vermeiden, Schlußfolgerungen jeglicher Art zu ziehen, wenn dieses Feld leer oder nicht vorhanden ist.
Nachdem die 15 Elemente im Dezember 1996 konsolidiert waren, kreiste die Diskussion noch um die Erweiterbarkeit ("extensibility") der Elemente, die Unterteilung der einzelnen Elemente in verschiedene Unterfelder ("subfields") durch Präzisierungen ("qualifiers"), die Einhaltung des Dublin Core an bestehenden oder im WWW-Bereich sich konsolidierenden Standards und ferner die Internationalität des Dublin Core. Diese Themen wurden dann Hauptdiskussionsgegenstand des 4. Dublin Core Metadata Workshops.
Der 4. Dublin Core Metadata Workshop - "Dublin Core Down Under"
Der 4. Dublin Core Metadata Workshop (DC4) fand vom 3.-5. März 1997 in Canberra, Australien statt. Veranstalter waren die Nationalbibliothek Australiens (NLA), das Distributed Systems Technology Centre (DSTC) in Australien und OCLC mit zusätzlicher Unterstützung von der US National Science Foundation (NSF), Sponsor des US-Digital Libraries Initiative-Programms. Die 65 TeilnehmerInnen kamen aus 12 Ländern mit folgender Verteilung: 22 Nordamerikaner, 16 Europäer (davon 3 aus Deutschland)21), 20 Australier und Neuseeländer und 7 aus Asien (Japan, Thailand). Beruflich verteilten sich die TeilnehmerInnen auf 25 Bibliothekare, 25 Netzwerkspezialisten und Spezialisten für Datentechnik und 15 Fachspezialisten. Der Workshop wurde in der Nationalbibliothek Australiens in Canberra unter der Organisation von Dr. Renato Iannella (DSTC) und Warwick Cathro (NLA) abgehalten. Dr. Stuart Weibel (OCLC) leitete den Workshop.
Die Tagesordnung sah vor, den Elementesatz des Dublin Core in einem informationellen RFC ("Request for Comment")22) für die IETF (Internet Engineering Task Force) zu formulieren und befestigen, sowie durch die oben erwähnten, noch offenen Diskussionspunkte (Erweiterbarbeit, Substruktur der Elemente und Qualifier) zur Verfeinerung des Elementensatzes zu gelangen. Thesenpapiere dienten als Diskussionsanstöße. Auch die Aufteilung in kleinere Arbeitsgruppen hat eine Präzisierung der Argumente während der Diskussionen bewirkt und verschaffte gewisse Klarheiten über die durch die TeilnehmerInnen vertretenen Positionen.
Die Themen
Erweiterbarkeit ("Extensibility") des Elementesatzes
Es gab Konsens darüber, daß dem Dublin Core keine weiteren Elemente hinzugefügt werden, und daß der noch anzufertigende RFC die 15 Elemente und ihre Beschreibung enthalten soll.
Im Rahmen der Erweiterbarkeit des Dublin Core sollte die Möglichkeit gegeben sein, Dateien und digitale Objekte inhaltlich ausführlicher zu beschreiben als mit einem Minimalsatz von Erschließungselementen bzw. durch Elemente für besondere Eigenschaften23). Lokalspezifische, regionalspezifische oder fach- bzw. domänenspezifische Attribute ergänzen und präzisieren die Metadatenangaben. Für die Zwecke automatisierter Recherchevorgänge durch Suchmaschinen und Roboter machen alle zusätzlichen Elemente und Unterelemente, die außerhalb des Standards fallen, jedoch eine neue Konfiguration des Suchdesigns notwendig und sind daher nur in außerst begrenzten Fällen akzeptabel.
Unter dem Begriff "Erweiterbarkeit" des Dublin Core wurden drei Möglichkeiten angesprochen (John Kunze, Carl Lagoze):
Diese sollen jedoch nicht zum Basis Dublin Core gehören, sondern von einer Koordinierungsstelle ("Registry" oder Referenzstelle) begutachtet, akzeptiert und festgelegt werden. Eine Arbeitsgruppe, um den konkreten Bedarf nach solchen zusätzlichen Elementen festzustellen bzw. Aspekte einer Normierungs- oder Referenzstelle zu bewerkstelligen, wurde in Canberra konstituiert;
Zwei Lösungsvorschläge, um die Verbindung und die Einrichtung eines weiteren Elementesatzes darzustellen, lagen zum Anfang des Workshops vor: Der erste schlug die Nutzung eines Link-Hinweises auf die verwendeten Metadata-Schemata im HTML-Dokument nach dem Schemata-Spezifizierungssystem im X.500 vor24). Der Link-Hinweis zeigt auf eine URL (URN bzw. URI), deren Seite das Metadaten-Schema mit dem Namen, der Beschreibung der Elemente und Syntax der Metadaten und ggf. einem weiteren Link auf die Referenzseite des formalen Standards (falls vorhanden) dieses Metadaten-Schemas enthält. Auch auf die semantischen und syntaktischen Regelungen der Metadaten wird in dieser Weise hingewiesen. Der zweite Vorschlag beinhaltete die Implementierung von PICS25) als Strukturgrundlage zur Erweiterung des Dublin Core26). Die Benutzung von PICS beeinflußt jedoch auch die Syntax der Dublin Core-Metadaten im HTML-Dokument und z. Z. werden auch bei PICS noch Standards vorbereitet. Die Entwicklung von PICS soll in Hinblick auf ihre Bedeutung für die Dublin Core weiter verfolgt werden;
Die Verfeinerung der Elemente durch eine Substruktur von Qualifiern wird unten ausführlich besprochen. Die Unterteilung eines Elements, das sonst eine ungenauere Bedeutung hat, wurde für die Elemente DC.DATE und DC.COVERAGE akzeptiert. Diese beiden Elemente und ihre vorgeschlagene Aufteilung (s.o.) sowie DC.RELATION werden noch in Arbeitsgruppen geprüft.
Eine Reihe von "Qualifiern" wurden bereits im ROADS-Projekt27) und im Nordic Metadata Project28) implementiert. Qualifier definieren z. B. die Rolle ("role") einer Person beim DC.CREATOR bzw. DC.CONTRIBUTOR oder unterteilen das Element "DC.SUBJECT" in "Stichwort" ("keyword"), "Systematik" ("classification") usw. Wie die Qualifier im HTML <META> Feld dargestellt und vom Element abgehoben werden, wurde sowohl in einem Thesenpapier29) als auch in der Diskussion durch verschiedene Beiträge besprochen.
Jedes Dublin Core-Element ist so definiert, daß es leicht verständlich ist und nicht weiter qualifiziert werden muß, um sowohl für Erschließungs- als auch für Recherchezwecke allein funktionieren zu können. Ein Qualifier - falls vorhanden - verfeinert den Wert und die Bedeutung des Elements ggf. durch den inhaltlichen Bezug zur Benutzung in einer Fachcommunity. Qualifier entstammen bekannten bibliothekarischen Standards bzw. Standardbegriffen eines Fachgebiets, zu dem die Ressource gehört. Qualifier sind wichtig, weil sie eine selbst zu definierende Spannweite zwischen allgemeinem Gebrauch und wissenschaftlichem Anspruch zulassen 30).
Grundsätzlich teilten sich die Meinungen der TeilnehmerInnen in zwei Gruppen. Es bestand ein Spannungsfeld zwischen Anhängern des ursprünglichen Ziels des Dublin Core, einen einfachen Satz von Elementen zu benutzen, die der entsprechenden Erschließung und dem Retrieval von digitalen Ressourcen im Internet höhere Qualität verleihen könnten, und anderen mit der Meinung, ohne zusätzliche Qualifier wäre kaum das inhaltliche Ziel des Dublin Core, nämlich eine verbesserte Suchgenauigkeit, erreichbar. So stand die Meinung der "Minimalisten", daß der Kernsatz von 15 Dublin Core-Elementen für die Präzisierung der Suche ausreichen müßte, der Meinung gegenüber, eine Reihe von Qualifiern für einzelne Elemente seien notwendig und wünschenswert, um die Eindeutigkeit des Suchverfahrens zu erzielen und gleichzeitig der Komplexität des Fachgebiets bzw. den Ansprüchen der Wissenschaft gerecht zu werden.
Internet-Nutzer stellen ein breites Spektrum von unterschiedlichen Erwartungen an die Suchergebnisse. Es gibt sowohl den Nutzer, der über eine Suchmaschine mit dem einfachen Elementennamen und Wert alles zu einem Thema sucht (DC.SUBJECT = "Quantenphysik"), als auch den Spezialisten, der seine Suche so präzisieren will, daß er nur diejenigen Publikationen findet, die genau seiner Vorstellung entsprechen. Im Prinzip einigte man sich im DC4-Workshop darauf, daß mit einigen wenigen Ausnahmen (s. u.) alle Elemente auch ohne obligatorische zusätzliche Qualifier ausreichend recherchierbar sein sollen. Dagegen besteht die Möglichkeit der Elementpräzisierung durch zusätzliche Qualifier, die aber in einem definierten und beschriebenen Satz von erlaubten Qualifiern für das jeweilige Element enthalten sind. Diese Diskrepanz führte zu dem Vorschlag, zwei RFCs zu formulieren, eine für die Basisversion der "unqualifizierten Elemente" und eine, die die Erweiterbarkeit durch Qualifier und Unterstruktur der Elemente festlegt.
Die "Canberra Qualifiers"
Es wurden drei "Canberra Qualifiers" vorgelegt, deren Semantik und Syntax zunächst akzeptiert worden sind. Vor dem DC4-Workshop wurde der Satz von Dublin Core Qualifiern, die im ROADS-Projekt definiert wurden, von Jon Knight und Martin Hamilton nach allgemeinem Input überarbeitet und zur Diskussion gestellt. Ursprünglich lehnten sich diese Qualifier sehr an buchbezogene dokumentenähnliche Objekte an. Sie wurden erweitert, um sowohl die allgemein bekannten Regelwerke für Angaben in den betreffenden Elementen ("SCHEME") als auch die entsprechenden fachlichen und formalen Unterelemente ("TYPE", "ROLE") zu definieren und beschreiben31) .
Der erste Canberra Qualifier ist "SCHEME", nämlich eine Angabe über das verwendete Regelwerk bei dem Eintrag des Werkes. Ohne diese Qualifier können Angaben oft nicht eingeordnet werden bzw. können womöglich in die Irre führen. SCHEME kann z. B. eine ISO-Norm sein, ein bibliothekarischer Normsatz oder ein anderes Regelwerk. Die Angabe des SCHEME ist oft für die Anwendung weiterer Qualifier nötig. Es wurde empfohlen, daß eine Koordinierungsstelle bzw. Referenzstelle ("Registry") für die Angabe zugelassener Regelwerke zuständig ist. Kein Eintrag in SCHEME darf dann gemacht werden, wenn er nicht von der Koordinierungsstelle akzeptiert wurde bzw. wenn er nicht ein anerkanntes Regelwerk ist. Es wurde festgestellt, daß für bestimmte Elemente die Angabe zum verwendeten Regelwerk ("SCHEME") unbedingt notwendig ist. SCHEME gibt z. B. zusätzliche Informationen, die zur Präzisierung des Indexierungs- bzw. Suchbegriffs dienen:
<META NAME = "DC.SUBJECT" TYPE = "CLASSIFICATION" (SCHEME = "DDC") CONTENT = "370.79">
Der numerische Wert im Unterfeld "classification" würde ohne die Angabe, daß es sich um eine Zahl aus der "DDC" (Dewey Decimal Classification) handelt, eventuell mit einem anderen numerischen Regelwerk für Klassifikation (wie z. B. MSC, PACS etc.) wechselt und zu Fehlanzeigen führen. Eine DC4-Arbeitsgruppe stellt die im wesentlichen akzeptierten Regelwerke für die jeweiligen Elemente zusammen, die als "SCHEME" angegeben werden können, um den SCHEME-Registry aufzubauen.
Der zweite Canberra Qualifier, "TYPE", wurde als einzige Unterteilungs- oder Verfeinerungsangabe für ein Element akzeptiert und kann in einigen Fällen auch als Unterelement ("subelement") angesehen werden. Die vorher akzeptierte "ROLE" wurde hiermit unter "TYPE" subsumiert und verschwindet als eigenständige Unterteilung. So kann zum Beispiel "TYPE" benutzt werden, um die inhaltliche Verfeinerung von einigen der einzelnen 15 Dublin Core-Elementen zu bewirken. Zur Zeit werden die TYPE-Unterteilungsmöglichkeiten geprüft und es wird eine begrenzte Zahl von erlaubten "TYPE"-Bezeichnungen vorgeschlagen. Die endgültige Liste soll jeweils elementgebunden werden und noch weit eingeschränkter als die ROADS-Liste sein, um die Nutzbarkeit und Retrievalfähigkeit von Dublin Core Metadaten nicht zu beeinträchtigen.
<META NAME = "DC.CREATOR" TYPE = "NAME" CONTENT = "WILLIAM FULBRIGHT">
<META NAME = "DC.CONTRIBUTOR" TYPE = "TRANSLATOR" CONTENT = "SUSAN MILLOWICH">
Die erlaubten Begriffe, vor allem für den Qualifier "TYPE", für die jeweiligen Elemente werden zur Zeit in einer Arbeitsgruppe als Liste (mit Angaben zur Definition und zum Abdeckungsgrad) erstellt und in die Diskussionsliste für Dublin Core-Metadatafragen aufgenommen.
Neben "SCHEME" und "TYPE" war es naheliegend, daß Angaben, die für sprachbezogenes Suchen notwendig sind, mit einer Sprachangabe gekennzeichnet werden. Dieses erfolgt mit dem Zusatzqualifier "LANG" und einer Angabe aus dem zweistelligen Sprachencodes Z 39.53 bzw. nach einem anderen universellen Sprachencode (der vorher als "SCHEME" für die Sprachenangaben vermerkt werden sollte). Zum Beispiel:
<META NAME = "DC.SUBJECT" TYPE = "KEYWORD" CONTENT (LANG = "EN") = "FOREIGN AFFAIRS">
<META NAME = "DC.SUBJECT" TYPE = "KEYWORD" CONTENT (LANG = "DE") = "AUSLANDSBEZIEHUNGEN">
Diese Qualifier sind insofern wichtig, als sie eine strukturinterne Öffnung zur Multilingualität des Dubin Core bedeuten. Während es für die Verarbeitung der Angaben durch Suchmaschinen etc. notwendig ist, daß die Elementen- und Qualifierbezeichnungen in dem HTML-Dokument einheitlich (und daher in englischer Sprache) sind, kann anhand der Angabe (CONTENT = " ") nun mit dem Zusatz LANG = " " gezielt nach Begriffen in einer bestimmten Sprache gesucht werden. Obwohl dieser Aspekt nur einer von vielen im Hinblick auf die zunehmende Internationalität des Dublin Core ist, stellt er sich als sehr wichtig heraus. Zwei der DC4-Teilnehmer erarbeiteten bereits Konzepte für prototyphafte sprachenbezogene Dublin Core-Referenzstellen (Tom Baker, Thailand und die Verfasserin).
Dieser Zusatzqualifier "LANG" bezieht sich nur auf den jeweiligen Begriff oder Wert des Metaelements und nicht auf die Sprache des Werkes als Gesamtes, die im Element DC.LANGUAGE zu kennzeichnen ist.
Da ein Hauptregelwerk für Sprachangaben im Dublin Core bereits in der Beschreibung zum DC.LANGUAGE vorgeschlagen wurde (Z 39.53 bzw. ISO 639), wurde empfohlen, dieses weitgehendst zu nutzen, obwohl andere Sprachcodes vielleicht umfassender sind - vor allem für weniger verbreitete Sprachen, z. B. in den asiatischen Ländern.
Weitere Entwicklungen im Internet hinsichtlich der Standardisierung von Sprachangaben und anderen Code-Spezifizierungen wurden von Misha Wolf (Reuters) berichtet. Rasche Standardisierungsbemühungen im Bereich "Unicode" zielen darauf ab, einheitliche, allgemein akzeptierte Zeichensätze und -darstellungen im Internet zu erreichen. Auch diese Entwicklungen werden im Hinblick auf ihre Auswirkungen für das Dublin Core im Auge behalten.
Elementverfeinerung
Die Spannung zwischen Minimalsatz des Dublin Core und die offensichtliche "Gefahr der Zersplitterung" (offene Erweiterungsmöglichkeiten) durch weitere Qualifier, Elementunterteilung und andere Elementsätze durchzog die Diskussionen.
Auch Fragen des Syntax der Ansetzung für die Metadaten wurden besprochen. Zwei Formen wurden bevorzugt, die ein Minimum an Interpunktion, Klammern oder Trennzeichnen unterstützt:
und
Bei zwei der Dublin Core-Elemente wurde festgestellt, daß sie ohne einen Qualifier nicht aussagekräftig genug sind (DC.DATE; DC. COVERAGE).
Berichte über die Implementierung des Dublin Core in verschiedenen Projekten
Über laufende Projekte in verschiedenen Stadien der Implementierung von Metadaten nach dem Dublin Core wurden kurz berichtet.
Das deutsche MathN-Projekt des Deutschen Mathematiker-Vereins
Dr. Roland Schwänzl von der Universität Osnabrück zeigte die Eingabe-Maske für die Erfassung von Metainformationen für den Preprint-Server des Deutschen Mathematiker-Vereins und demonstrierte, wie diese Angaben in die HTML-Dokumente in Dublin Core Syntax um- und eingesetzt werden. Der Bezug zur in der Mathematik allgemein verwendeten Systematik der American Mathematical Society (MSC) bzw. verwandten naturwissenschaftlichen Gesellschaften (PACS, CR etc.) sowie die durchgehende Verwendung der englischen Sprache für die formalen und inhaltlichen Metadaten sowie für Recherchezwecke machten einen einheitlichen Eindruck. Deutschsprachige Titel der Preprints sind natürlich auch im Stringsearch suchbar, aber die Verwendung der international anerkannten Fachsystematik und englischer Verbalerschließungsbegriffe öffnet den Server zur sinnvollen Nutzung durch eine größere internationale Fachcommunity.
Der Deutsche Bildungs-Server - Beispiel für eine nicht-englischsprachige Nutzung von Metadaten sowie die Nutzung von fachspezifischen Elementenzusätzen
Im Kontrast zum MathN-Projekt steht der Deutsche Bildungs-Server (German Educational Resources)32) durchgehend in deutscher Sprache, mit Übersetzung einzelner Seiten in englischer und in französischer Sprache, zur Verfügung. Die nachgewiesenen Dokumente sind überwiegend deutschsprachig, werden aber teilweise mit sowohl deutschen als auch englischen Metadaten versehen. Da die Bereiche Erziehungswissenschaft, Bildungswesen und Schulwesen in die kulturelle und soziale Struktur eines Landes eingebettet und oft damit auch in den linguistischen Eigenheiten der jeweiligen Sprache konzeptionell verankert sind, reichen Übersetzungen allein nicht immer aus. Weitere inhaltliche Probleme treten auf, wo die linguistische Darstellung von soziopolitischen Strukturen in einer anderen Sprache nicht mit dem ursprünglichen Sprachbegriff genau übereinstimmt. Der Deutsche Bildungs-Server gab auch ein passendes Beispiel von der Notwendigkeit zusätzlicher fachspezifischer bzw. domänenspezifischer Qualifier (im Bereich "TYPE"), um z. B. fachbedingte Ressourcenarten (z. B. Lehrmaterialien, Unterrichtspläne), Themenunterteilungen nach Schulebene etc. zu erschließen und recherchierbar zu machen. Auch im Deutschen Bildungs-Server können Lehrer, Schüler und Wissenschaftler ihre Dokumente und digitalen Ressourcen selbst mit Hilfe eines Eingabeformulars (auf Deutsch) eingeben, das die Metadaten ebenfalls berücksichtigt33).
Das Nordic Metadata Project
Über den Stand des Nordic Metadata Project (Metadatenprojekt der skandinavischen Länder)34) berichteten Juha Hakala und Traugott Koch. Auch über eine Untersuchung vom Preben Hansen wurde berichtet, die zeigte, daß 4 % aller schwedischen Web-Seiten Metadaten anwendeten. Ebenfalls untersucht wurde das Recherche-Verhalten mittels Metadaten, um die eigentlichen Nutzungseffekte des Dublin Core festzustellen.
Traugott Koch demonstrierte die Anwendung eines Eingabeformulars35) bzw. Konverters für Metadatenangaben, basierend auf dem Dublin Core, der von ihm und Mattias Borell im Rahmen des Nordic Metadata Project entwickelt worden ist, aber zur freien Nutzung für alle Metadateneingaben zur Verfügung steht. Dieses Formular bearbeitet die Metadaten sowohl in ASCII-Textformat als auch in HTML-Metadata-Format zur Übernahme in eine HTML-Datei. Obwohl dieses Template (Formular) noch einige Unterfelder berücksichtigt, die noch nicht nach dem DC4-Workshop bestätigt sind, bietet es ein Formular zur Erfassung von Metadaten mit Hilfstexten36) zu allen Angaben an. Außerdem werden in diesem Formular die Minimalanforderungen definiert - die als notwendigste Metadaten-Angaben mit roten Punkten gekennzeichnet werden - , während es gleichzeitig auch eine breite Palette von Standardeintragungen für weitere Unterfelder anbietet, inklusive Formschlagwörtern, universell anerkannter Regelwerke zur Übernahme in die Rubrik "SCHEME" bei den jeweiligen Elementen etc. Dieser Service kann von jedem genutzt werden, der Metadaten in seine HTML-Datei einbetten möchte, auch wenn er selbst keine HTML-Erfahrungen hat. Die Angaben können auch für eine Datenbankerfassung von Metadaten angewendet werden.
Die Implementierung von Dublin Core Metadaten in Australien
Dr. Renato Iannella vom Distributed Systems Technology Centre berichtete kurz über die Arbeit und Implementierung von Dublin Core Metadaten in Australien. Im Anschluß an den DC4-Workshop fand ein Metadata-Workshop für australische Bibliothekare, Archivare und Informationsvermittler statt37). Australien hat den Nutzen von Internet in Forschung und Lehre früh erkannt, und mehrere Institutionen (EDNA, ERIN, ANZLIC) arbeiten bereits mit Metadaten nach dem Dublin Core. Ein detailliertes, systematisches Informationssystem, dessen fachliche Zuständigkeiten auf verschiedene Universitätsbibliotheken und -rechenzentren in Australien verteilt sind, ist aufgebaut worden (WWW Virtual Library). es werden sowohl Datenbanktechnik (auch WAIS) als auch ansatzweise Dublin Core Metadaten eingesetzt.
Metadaten-Registries
Koordinierungsstellen ("Registries") für die offiziellen Namen, Definitionen, Beispiele und Anwendungen etc. werden eingerichtet. Somit werden weitere angenommene Qualifier von einer Art "Aufsichtsrat" ("Registry review board") geprüft, inwieweit sie eine sinnvolle Anwendung haben, ob ihre Anwendung im Einklang mit der Grundphilosophie des Dublin Core ist, und ob sie eindeutig eine notwendige Elementverfeinerung ermöglichen ohne semantische Überschneidungen mit anderen Qualifiern. Ähnliches wird für sprach- oder regionalbezogene Koordinierungs- oder Referenzstellen gelten, die notwendig werden, um nicht-englische Suchinterfaces, Eingabeformulare etc. zu gestalten38).
Da es noch keine Verfahrensweisen für eine solche Koordinierungsstelle oder Referenzstelle gibt, wird sich eine dafür konstituierte DC-Arbeitsgruppe damit befassen. Es wurde in dieser Hinsicht auf ähnliche Bestrebungen und die Organisation von Metadaten-Registries in anderen Wirtschaftszweigen hingewiesen und angeregt, Erfahrungen aus diesen Entwicklungen zu nutzen39).
Die nächsten Schritte zum Standard des Dublin Core
Die bereits erwähnten, in Canberra konstituierten Arbeitsgruppen werden ihre Lösungsvorschläge im Forum der Diskussionsliste zur allgemeinen Stellungnahme und Debatte zur Verfügung stellen. Diese noch offenen Punkte sind:
1) Genannt nach dem Ort des ersten Workshops Dublin/Ohio gleichzeitig Sitz der not-for-Profit-Firma Online Cataloging Library Center (OCLC) <http://www.oclc.org/>. Siehe auch die Dublin Core Homepage < http://purl.org/metadata/dublin_core>
2) Diese Art von Metadaten dient lediglich "resource discovery and retrieval" (vgl. Rusch-Feja, Diann: Metadaten zur Erschließung digitaler Ressourcen und PURL. In: Weiter auf dem Weg zur Virtuellen Bibliothek! Praxis, Projekt, Perspektiven. 2. InetBib-Tagung der Universität Dortmund und der Fachhochschule Potsdam Fachbereich Archiv-Bibliothek-Dokumentation vom 10.-11. März 1997 in Potsdam. Hrsg. Beate Tröger. Dortmund, Potsdam, 1997, S. 7-11. In Kurzform: <http://www.mpib-berlin.mpg.de/DOK/metadata/INETwksp.htm> Siehe auch Bearman, David; Sochats, Ken: Metadata Requirements for Evidence <http://www.oclc.org:5046/conferences/metadata/requirements.txt>.
3) DLO = Document-Like Object.
4) OCLC / NCSA Metadata Workshop Report <http://www.oclc.org:5047/oclc/research/conferences/metadata/dublin_core_report.html>
5) Dempsey, Lorcan; Weibel, Stuart: The Warwick Metadata Workshop: A Framework for the deployment of resource description. DLib Magazine (July/August, 1996) <http://www.dlib.org/dlib/july96/07weibel.html>. Lagoze, Carl; Lynch, Clifford; Daniel, Ron: The Warwick Framework: A Container Architecture for Diverse Sets of Metadata. D-Lib Magazine, July 1996 <http://www.dlib.org/dlib/july96/lagoze/07lagoze.html>. Siehe auch Henze, Volker; Schefczik, Michael: Metadaten: Beziehungen zwischen Dublin Core Set, Warwick Framework und Datenformaten. BIBLIOTHEKSDIENST 31(3) (1997), S. 413-419. - Allerdings wurde das Dublin Core nicht als Datenaustauschformat konzipiert.
6) Burnard, Lou; Miller, Eric; Quin, Liam; Sperberg-McQueen, C.M.: A Syntax for Dublin Core Metadata: Recommendations from the Second Metadata Workshop <http://users.ox.ac.uk/~lou/wip/metadata.syntax.html>
7) W3C Distributed Indexing and Searching Workshop <http://www.w3.org/pub/WWW/Search/9605-Indexing-Workshop/>
8) A proposed Convention for Embedding Metadata in HTML. <http://www.oclc.org:5046/~weibel/html-meta.html>
9) GILS: Application Profile for the Government Information Locator Service (GILS), Federal Information Processing Standard, FIPS PUB 192. Siehe auch <http://www.usgs.gov/gils>
10) CNI/OCLC Metadata Workshop on Metadata for Networked Images <http://purl.oclc.org/metadata/image>. Siehe auch 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 <http://www.ukoln.ac.uk/dlib/january97/oclc/01weibel.html>
11) Dempsey, Lorcan: ROADS to Desire. Some UK and Other European Metadata and Resource Discovery Projects. D-Lib Magazine, July/August 1996 <http://www.ukoln.bath.ad.uk/DLib/july96/07dempsey.html>
13) Iannella, Renato: Metadata Activities in Australia <http://www.dstc.edu.au/RDU/pres/nat-md/>
14) Für die Aktivitäten der IuK-Kommission der Fachgesellschaften hinsichtlich Metadaten siehe <http://www.mathematik.uni-osnabrueck.de/ak-technik/IuKKwF.html>
15) DELOS ERCIM Workshop (s. Rusch-Feja, Diann: Erschließung von Internet-Quellen durch Metadata. Ergebnisbericht des 2. DELOS-Workshops. BIBLIOTHEKSDIENST 30(12) (1996), S. 2023-2027. und "Metadaten und Strukturierung von elektronischen Information", der im Dezember 1996 von der IuK-Kommission der zusammengeschlossenen Fachgesellschaften an der Niedersächsischen Staats- und Universitätsbibliothek Göttingen veranstaltet wurde <http://www.mathematik.uni-osnabrueck.de/ak-technik/anlagen/vortrag.html> Ein Bericht darüber erscheint demnächst.
16) Siehe z. B. das MathN des Deutschen Mathematiker-Vereins <http://www.mathematik.uni-osnabrueck.de/harvest/brokers/MathN/query.html>
17) Vgl. BIBLIOTHEKSDIENST 30(12) (1996), S. 2024.
18) Dublin Core Element Reference Set <http://purl.org/metadata/dublin_core_elements/> Die deutsche Fassung der englischen Erläuterungen der DC-Elemente wird jeweils auf dem neuen Stand an folgender URL gehalten: <http://www.mpib-berlin.mpg.de/DOK/metatagd.htm>.
19) Zusatz durch die Verfasserin.
20) Im 4. Dublin Core Workshop wurde zunächst eine grundsätzliche Aufteilung dieses Elements in DC.COVERAGE.SPATIAL (räumliche Angaben) und DC.COVERAGE.TEMPORAL (zeitliche Angaben) durchgeführt.
21) Hans-Jürgen Becker (SUB Göttingen), Dr. Roland Schwänzl (Universität Osnabrück, FB Mathematik) und die Verfasserin.
22) Ein RFC der IETF ist wie eine Offenlegung eines Patenttextes zur öffentlichen Stellungnahme, bevor es zur akzeptierten Norm für das Internet wird.
23) Weibel, Stuart: Metadata: The Foundations of Resource Description. D-Lib Magazine, July 1995 <http://www.dlib.org/dlib/July95/07weilbel.html>
24) Waugh, Andrew: A Strawman Proposal for Metadata Etensibility. <http://www.dstc.edu.au/DC4/straw/extend2.html>
25) Die Platform for Internet Content Selection (PICS) sieht sowohl ein System für inhaltliche Bewertungen vor als auch eine Empfehlung für die Namensgebung und Syntax von Metadaten zwecks datentechnischer Kommunikationen. Siehe <http://www.w3.org/pub/WWW/PICS/>.
26) Iannella, Renato: Extensibility Strawman Proposal using PICS <http://www.dstc.edu.au/DC4/straw/extend1.html>
27) Knight, Jon; Hamilton, Martin: Dublin Core Qualifiers. ROADS Project, Department of Computer Studies, Loughborough University <http://www.roads.lut.ac.uk/Metadata/DC-Qualifiers.html>
28) The Nordic Metadata Project <http://linnea.helsinki.fi/meta/index.html>
29) Beckett, Dave: Dublin Core Element Substructure (Why The Dublin Core needs Qualifiers) <http://www.dstc.edu/DC4/straw/structure1.html>
30) Weibel, Stuart: Metadata: The Foundations of Resource Description. D-Lib Magazine July 1995 <http://www.dlib.org/dlib/July95/07weibel.html>
31) Knight, Jon; Hamilton, Martin: Dublin Core Qualifiers. <http://www.roads.lut.ac.uk/metadata/DC-SubElements.html>
33) "Erstellung eines neuen Datensatzes" (für die Datenbank von Lern- und Unterrichtsmaterialien) <http://dbs.schule.de/db/inconeue.html>
34) <http://www.ub2.lu.se/desire/>
35) Dublin Core Metadata Template <http://www.ub2.lu.se/metadata/DC_creator.html>
36) Koch, Traugott: Dublin Core Element Set: The 15 Elements. <http://www.ub2.lu.se/tk/metadata/CD10cats.html>
37) Die Präsentationsfolien von diesem Workshop hat Dr. Iannella ins Web gelegt: Metadata Activities in Australia <http://www.dstc.edu.au/RDU/pres/nat-md/>
38) Ein Deutscher Referenzserver ist in diesem Sinne bereits in der konzeptionellen Phase und wird sowohl Übersetzungen der englischen Begriffe als auch Hinweise auf Eingabeformulare (Templates) und Beispiele der Metadatenanwendungen bereithalten.
39) Vgl. z. B. den 1996 ISO/JTC1 Joint Workshop on Standards for the Use of Models that Define the Data and Processes of Information Systems <http://www.nist.gov/workshop/jct1-96/report.html>.
Weitere Literatur
Miller, Paul: An Application of Dublin Cre from the Archaeology Data Service <http://intarch.ac.uk/ahds/project/metadata/dublin.html>
Miller, Paul: Metadata for the Masses. Ariadne September 1996 <http://www.ukoln.ac.uk/ariadne/issue5/metadata-masses/>
Dublin Core Metadata Element Set: Reference Description <http://purl.org/metadata/dublin_core_elements>
IFLA: Metadata-Resources <http://www.nlc-bnc.ca/ifla/II/metadata.htm>.
Weibel, Stuart; Miller, Eric; Godby, Jean; LeVan, Ralph: An Architecture for Scholarly Publishing on the World Wide Web. <http://www.oclc.org:5046/oclc/research/publications/weibel/web_pub_arch/>
Weibel, Stuart: A Proposed Convention for Embedding Metadata in HTML. June 1996 <http://www.oclc.org:5046/~weibel/html-meta.html>
