Dublin Core ist kein Format. Es ist eine Liste von 15 Datenelementen, die für die Beschreibung von Dokumenten aller Art (allgemein: "Ressourcen") für wichtig gehalten werden, mehr nicht. Solche Beschreibungen werden als "Metadaten" bezeichnet, und "Dublin Core" gilt als internationaler Standard dafür. DC-Metadaten werden typischerweise direkt in den Kopf von HTML-Dokumenten eingebettet, quasi wie eine elektronische CIP-Aufnahme. Das jedoch ist nur eine von vielen denkbaren Implementierungen.
Man muß auch bedenken: ein Format ohne Katalogregeln ist eine halbe Sache (oder weniger), und hinter DC stecken keine solchen Regeln (hinter MAB steckt RAK, hinter USMARC die AACR). Mit der Aufstellung einer Liste von Feldern ist noch nicht viel gewonnen, ob es 13 sind oder 15 oder 150 (oder wie bei Pica: 1300).
Im Kapitel 5 sollte klar geworden sein, warum das so ist.

Die nachfolgenden Bemerkungen entstanden bei verschiedenen Gelegenheiten, aus Diskussionen über den Wert von Metadaten und Vergleiche zwischen WWW-Metadaten und Katalogisierungsdaten.
Weiten unten folgt eine Stellungnahme einer Arbeitsgruppe der American Library Association zur Frage "AACR, USMARC und Metadaten".
Bei der LC wurde trotz allem eine Art Konkordanz, genannt "Crosswalk" zwischen USMARC und DC erstellt.
Andere solche Versuche wurden dokumentiert bei UKOLN.
Vergleiche mit UNIMARC wurden angestellt in Unimarc and metadata / Alan Hopkinson. 1998 IFLA Annual Conference.
Über die grundsätzlichen Probleme der Konversion zwischen Metadaten-Formaten schreibt eine NISO-Studie (1998).

Unter dem Namen "Dublin Core" wurde 1995 eine Liste von 13 (später erweitert auf 15) Datenelementen aufgestellt, die für die Beschreibung von elektronischen Dokumenten (allgemeiner "Ressourcen") für wichtig gehalten wurden.
Die DC-Initiative entstand unter dem Eindruck, daß die Internet-Suchmaschinen hinsichtlich Präzision der Ergebnisse sehr zu wünschen übrig lassen. Man wollte mit möglichst geringem Aufwand etwas tun, um die Chancen zu verbessern, im Internet relevante Ressourcen zu entdecken. "Resource Discovery" heißt das Schlagwort.
Nun sind Ressourcen weit vielfältiger als nur elektronische Äquivalente von papierenen Dokumenten. Das Verdienst der DC-Initiative besteht darin, zunächst einmal einen Konsens zwischen Vertretern der verschiedensten "Communities" zustande gebracht zu haben, darunter Leute aus Archiven, Museen, verschiedensten Dokumentationsstellen. Den meisten waren die bibliothekarischen Metadaten-Standards (AACR und USMARC oder UNIMARC) unbekannt, und Standards solchen Umfangs und solcher Detaillierung erschienen als undurchsetzbar. Der Konsens bestand aus 13, später 15 Datenelementen, die man für unabdingbar hielt, und diese Liste erhielt den Namen "Dublin Core", weil sie zuerst in einer Bar in Dublin Ohio auf einer Serviette notiert wurde. Daß ein solcher Name, der über die Sache selbst nichts aussagt, sich in dieser Weise etablieren konnte, mag man erstaunlich finden. Es könnte ein Symptom dafür sein, daß man sich für das unentwirrbare Internet-Chaos eine "Lösung" nach Art des Gordischen Knotens erhoffte: anstatt aus den voluminösen bibliothekarischen Standards, die zugegebenermassen einigen historischen Ballast mitschleppen, in der Sache aber fundiert sind, einen Minimalstandard auszudestillieren, setzte man eine Liste dagegen, die sich als von bibliothekarischem Sachverstand so gut wie ungetrübt erwiesen hat. Und suggerierte damit (sicher nicht mit Absicht) den Zuschauern und den Entscheidungsträgern (!), daß die bibliothekarischen Standards nichts taugten oder unnötig seien. Man bedenke aber: da, wo jetzt "Dublin Core" ist, da war vorher einfach überhaupt kein Standard, und bei den Produzenten der Ressourcen befand sich auch kaum einschlägige Erfahrung. Nach meinen Eindrücken denkt wirklich ausnahmslos jeder, der erstmals mit bibliothekarischen Regeln und Formaten konfrontiert wird, das müsse doch alles viel viel einfacher zu machen sein. Die wahren Probleme werden nicht gesehen oder gewaltig unterschätzt, die Erfolgsaussichten immens überschätzt. Wenn das irgendwann dämmert, läßt man die heiße Kartoffel sang- und klanglos in der Versenkung verschwinden. Davon zeugen auch zahllose Versuche an Hochschulinstituten, die Institutsbibliothek durch einen studentischen Hiwi mal schnell auf den Rechner bringen zu lassen, mit untauglichsten Methoden und ohne Rücksprache mit irgendwem, der davon was verstehen könnte. Über Misserfolge wird ja leider nicht geredet, schon gar nicht publiziert...
Die Welt der Bücher ist kompliziert, weil erstens das darin angesammelte Wissen kompliziert ist und zweitens die menschlichen Beziehungen kompliziert sind, in deren Zusammenhang die Aufzeichnungen erfolgen. Daß unsere Regeln kompliziert sind, ist eine notwendige Folge.
Eine andere Folge ist z.B., daß man CIP-Aufnahmen nicht von den Verfassern oder Verlegern der Dokumente anfertigen läßt, sondern daß dies nationale Agenturen tun. Metadaten in E-Dokumenten sind von der Intention her durchaus mit CIP- Aufnahmen zu vergleichen, eine Erstellung durch irgendwelche zentralen Einrichtungen wird aber nicht nur abgelehnt, es erscheint schlicht undurchführbar. Die Verfasser müssen die Metadaten selber machen, sonst wird niemand sie machen können. Das ist der begrenzende Faktor, aber WIE eng die Grenzen des Erfolgs dadurch werden, ist noch wenigen klar.
Andererseits stehen dadurch auch die Scheunentore für jede Art von Mißbrauch weit offen, man denke an das "index spamming", das Anfüllen des META tags DC.Subject mit allerhand wenig relevanten Wörtern, evtl. sogar in zigfacher Wiederholung. Es gibt Leute, die verkaufen Tricks, mit denen man seine Web-Seiten in Suchdiensten ganz nach oben bringen kann...
Wenn nicht nur Bücher, sondern Dokumente im weitesten Sinne zu erfassen und zu beschreiben sind, KANN das nicht einfacher zugehen als in Bibliothekskatalogen. Wer diese simple Erkenntnis ignoriert, muß Lehrgeld bezahlen, und nicht selten wird das leider "Staatsknete" sein. Für die DC-Gemeinde besteht das zur Zeit darin, daß die DC-Daten von Suchmaschinen-Betreibern noch mit großer Skepsis behandelt werden, wenn sie denn überhaupt zur Kenntnis genommen werden. (Warum man sich nicht gleich am Anfang mit solchen Betreibern ins Benehmen gesetzt hat, um zu ergründen, was denn wünschenswert und nützlich sein könnte, das mag man sich fragen. Vielleicht wurde es sogar versucht.) Allerdings darf man nicht zuerst und hauptsächlich auf die großen, allgemeinen Suchmaschinen schauen und dort Verbesserungen erwarten. Dies sind kommerzielle Dienste, die sich aus Werbeeinnahmen finanzieren, nicht aus öffentlichen Mitteln, man vergesse das nie! Die Zielrichtung Nummer 1 ist das Alltagsleben, obenan Freizeit und Unterhaltung, nicht Wissenschaft.  Bei Fireball hat man dennoch einiges in die Metadaten-Auswertung investiert, und dies auch dokumentiert: http://www.fireball.de/meta_daten.html Man sieht dort, was für eine bunte Vielfalt es gibt - u.a. DC-Tags. Es wird sogar ein Meta-Generator bereitgestellt. Dieser erstellt Tags, die mit DC nicht kompatibel sind, d.h. sich nicht alle in DC abbilden lassen. Auffällig: es fehlt JEDE Empfehlung, in den einzelnen Feldern bestimmte Formalien einzuhalten (d.h. es gibt keine Ansetzungsregeln!) Unter "Autor" kann jemand also "Fritz Mueller" genauso wie "Müller,F" oder "Müller, Fritz" eingeben. Auf einem Vortrag in Berlin enthüllte freilich einmal der Fireball-Chef, Oli Kai Paulus, man stelle in der Zugriffsstatistik ein sehr geringes Interesse an Metadaten fest. Vermutlich ist man genau deshalb noch nicht auf die Probleme gestoßen, die sich aus einem solch laxen Ansatz ergeben müssen.
Es sind Unternehmungen der fachspezifischen Art, und Dienste wie das "Nordic Metadata Project", der "Deutsche Bildungsserver", oder in England "ROADS", wo sich Verbesserungen zuerst zeigen sollten. Überzeugende Beweise, daß DC die eingangs beschriebene Misere lösen kann, stehen noch aus. Man mag das als einen Fall von "Henne und Ei"-Problem sehen (solange noch zu wenig DC-Daten da sind, nützen sie nichts, und weil sie noch nichts nützen, macht kaum einer welche). Die wenigen aber, die man schon finden kann, lassen recht schnell erkennen, daß die Qualität der erreichbaren Resultate (Präzision!) bei nüchterner Analyse hinter den Erwartungen zurückbleiben muß - so schlecht und uneinheitlich sind die Daten. Kein Wunder, denn DC enthält so gut wie keine Ansetzungsregeln. Ohne solche wird das Chaos nur leicht gemildert. Das wurde von Bibliothekaren schon hier und da in Diskussionen angemerkt, einige hatten es vorausgesehen, aber sie konnten es nicht rüberbringen.
Zu bedenken ist allerdings: Anders als bei Bibliothekskatalogen (OPACs wie Zettelkatalogen) kann man von einem gefundenen Metadatum aus in der Regel direkt durch einen Mausklick das Dokument selbst einsehen! Eingehende und genaue deskriptive Erschließung sollte sich deshalb erübrigen - Kataloge mußten das machen, weil man eben normalerweise NICHT das Dokument gleich einsehen konnte, deshalb brauchte man genaue Information, um am Katalog z.B. unterschiedliche Ausgaben identifizieren und unterscheiden zu können. Standardisierung von Zugriffskriterien (Namen, Titel, Schlagwörter) ist allerdings ein anderes Thema! Hier schlägt Regellosigkeit direkt auf die Chancen einer Online-Suche durch.
Der einzige schon einigermaßen fixierte Level des DC ist "DC Simple". Die Verfasser jenes Dokuments wissen, daß es beiweitem nicht ausreicht, um überzeugende Resultate zu erreichen. Die Magie des Wortes "Simple" verheißt jedoch schnelle, mühearme Erfolge. Man wird erkennen, daß dieses "simple" mit "schlicht" übersetzt werden muß ("plain" wäre auf Englisch besser), und daß schlichte Daten eben in den gewaltigen Mengen, um die es geht, keine durchschlagenden Verbesserungen erbringen KÖNNEN sondern eben nur geringfügige Milderungen. (Das hat übrigens auch Stu Weibel, Metadaten-Papst bei OCLC, erkannt und erklärt, er werde den Terminus "DC Simple" nicht mehr verwenden.) Weil aber ein mehr ins Detail gehender Level noch nicht existiert, kann man DC zur Zeit kaum gewinnbringend einsetzen, es sei denn innerhalb einigermaßen geschlossener Communities, wo man in der Regel dann noch eigene Spezifikationen hinzufügt. Dann ist es nicht mehr DC Simple, und damit ist es nicht mehr Standard, sondern weicht von allen anderen Anwendungen ab. Zur Zeit ist infolgedessen eine Aussage wie "Metadaten nach Dublin Core vorhanden" nicht viel wert. Wenn es irgendwann gelingt, einen hinreichend detaillierten DC-Standard zu erstellen, wird dieser nicht weniger umfangreich sein können als AACR plus USMARC. (Wenn man das Heil in SCHEMEs sucht, ist man de facto schon an diesem Punkt angelangt, denn die einem SCHEME entsprechenden Daten können ja nur unter Anwendung des zugehörigen Regelwerks entstehen.) Sobald mehrere SCHEMEs zum Einsatz kommen, sind DC-Daten schon jetzt alles andere als "simple", wenn man sie nutzbringend verwerten will.
Ein Wort noch zur Codierung in HTML-Dokumenten. Die Elemente mit HTML-Tags zu kennzeichnen ist zwar für Web-Programmierer die natürlichste Sache der Welt. (Vielleicht ist ihnen deswegen nichts anderes eingefallen. Eine sachliche Notwendigkeit, es so zu machen, besteht jedenfalls nicht.) Diese Methode ist jedoch grob ineffizient. Man sieht das schon daran, daß die Metadaten, wenn auch noch mit SCHEMEs u. dgl. gearbeitet wird, mehr aus Tags als aus Daten bestehen. Wenn wir so etwas in OPAC-Datenbanken machen würden!

Nach diesen subjektiv eingefärbten Kommentaren nun noch eine

Stellungnahme aus einem Gremium der American Library Association:

AACR2, USMARC und Metadaten
Das US-amerikanische Committee on Cataloging: Description and Access (Pendant zu unserer "Arbeitsgruppe für Formalerschließung") hatte eine "Task Force on Metadata and the Cataloging Rules" eingesetzt, welche das Verhältnis zwischen Katalogisierungsregeln und Metadaten und insbesondere den meistdiskutierten Standards, Dublin Core und TEI (Text Encoding Initiative), untersuchen sollte. Am 3. Juni 1998 verabschiedete diese Gruppe ihren Schlußbericht: http://www.ala.org/alcts/organization/ccs/ccda/tf-tei2.html
Zwar stehen dabei die AACR2 im Zentrum des Interesses, doch spricht nichts dafür, daß die Schlußfolgerungen für unser Regelwerk anders ausfallen würden. Es werden darin einige sehr deutliche Worte gesprochen. Daher ist es wohl richtig, sich zumindest die "Conclusions" des Abschlußberichts genauer anzusehen. Weil die Diskussion auch hier geführt werden muß, kann es nicht schaden, davon eine deutsche Übersetzung zu haben, welche hiermit vorgelegt wird:
(Im Anschluß daran erlaube ich mir, zwei Fragen in die Diskussion zu werfen)

1. Metadaten ersetzen nicht eine regelgerechte Katalogisierung
Sie können eine nützliche Informationsquelle für Katalogisierer sein. Metadaten werden sich in den Umgebungen am besten bewähren, für die sie geschaffen wurden, nicht in Bibliothekskatalogen. Metadaten werden sich nicht nutzbringend in Kataloge integrieren lassen, es sei denn, sie sind erstellt in Übereinstimmung mit semantischen oder inhaltlichen Richtlinien, die von den Katalogregeln abgeleitet wurden bzw. von den Sacherschließungsregeln und Vokabularien, die für die Kataloge gelten. Jedoch können Metadaten als nützliche Informationsquelle für die Katalogisierung von E-Materialien dienen.

2. Die meisten Metadaten-Standards haben nicht zum Ziel, ausreichende Angaben für eine Unterscheidung einer Ressource von anderen Ressourcen oder anderen Versionen derselben Ressource zu machen
Die inhaltlichen Richtlinien der meisten Metadaten-Standards verfolgen nicht das Prinzip der Vorlagentreue [wie es in Katalogregeln verankert ist]. Metadaten sind in der Regel nicht als vollwertiger Katalogisierungsersatz intendiert. Insbes. sind Dublin Core Daten zur Verbesserung der Auffindemöglichkeiten von Ressourcen gedacht, nicht zu deren Beschreibung. Man geht von der Annahme aus, daß ein DC-Datensatz entweder eine Verbindung herstellt zu einer vollwertigen Beschreibung wie einem Katalogdatensatz, oder aber direkt zum Dokument. Wegen dieser begrenzten Zielsetzung verlangen die inhaltlichen Regeln in den Standards DC und TEI nicht die vorlagegetreue Übertragung von Elementen aus präzise vorgeschriebenen Quellenbestandteilen, wie dies die Katalogregeln tun. Aus diesem Grund sind Metadaten oft nicht hinreichend genau, um die Unterscheidung einer Ressource von ähnlichen Ressourcen oder anderen Versionen derselben zu gewährleisten.

3. Metadaten sind nicht zum direkten Einspeisen in Kataloge geeignet, weil sie keine semantischen oder inhaltlichen Normen befolgen oder Normdaten anwenden, wie z.B. Namensdateien oder kontrolliertes Schlagwortvokabular
Die Unbrauchbarkeit von Metadaten für die unmittelbare Einspeisung in Bibliothekskataloge folgt hauptsächlich daraus, in welcher Weise Kataloge und Metadaten von normierten Inhalten Gebrauch machen bzw. nicht Gebrauch machen. Die Integrität eines Bibliothekskatalogs beruht auf der konsistenten Anwendung wohldefinierter Normen und der Verwendung sorgfältig erstellter und gepflegter Normdateien z.B. für Namen und Sachbegriffe. Normierte Daten werden von den Meta-Standards nicht gefordert oder erwartet, wenngleich Vorkehrungen getroffen sind, daß solche Normen verwendet werden können und die Tatsache solcher Verwendung in den Daten angezeigt werden kann. Wenn eine signifikante Menge von Datensätzen in einer Datenbank nicht den Kriterien der Konsistenz genügt und nicht den maßgeblichen Normen entspricht, verliert die Datenbank ihre Integrität und kann weder die von Cutter [1] und anderen formulierten Aufgaben erfüllen noch den Erwartungen der Nutzer entsprechen.

4. Metadaten-Formulierer haben sich auf die Kompatibilität mit Austauschformaten wie MARC konzentriert, nicht mit Regeln für Semantik und Inhalt von Datenfeldern wie z.B. AACR
Allgemein kann man weder an DC- noch an TEI-Daten hohe Erwartungen hinsichtlich Konsistenz und Normierung knüpfen. Die Väter der Metadaten-Standards haben sich auf die Abbildbarkeit ihrer Elemente auf Austauschformate konzentriert; Regeln für Semantik und Inhalt von Datenelementen haben sie ignoriert oder noch nicht entdeckt. Ein Datenelement mag sich zwar gut auf USMARC abbilden lassen, aber trotzdem der durch AACR definierten inhaltlichen Anforderung nicht entsprechen. So wichtig die Kompatibilität mit der Austauschsyntax USMARC auch ist - die lebensnotwendige Arbeit der Harmonisierung mit den Katalogregeln ist noch gar nicht angepackt worden.

5. Metadaten aus einer nicht-AACR-konformen Quelle müssen vor einer Einspeisung in Kataloge stets von Katalogisierern geprüft und bearbeitet werden
Die Schlichtheit der unqualifizierten DC-Definitionen, der Mangel an Genauigkeit dieser Definitionen im Detail, die fehlende Verbindlichkeit, und die Tatsache, daß man die Datenerfassung Nutzern ohne bibliographische Kenntnisse überlassen will, macht DC wenig verläßlich und erzwingt sorgfältige Überprüfung durch Katalogisierer. Metadaten jedoch, die aus einer Quelle mit AACR2-Erfahrung stammen, wird man mit geringer oder keiner Überprüfung durch Katalogisierer verwenden können. TEI-Metadaten werden weniger manuelle Bearbeitung brauchen als andere, weil es für TEI ein höherentwickeltes Regelwerk gibt, weil die Liste der Elemente mit den Levels 2 und 3 der AACR2 recht genau abgestimmt ist, und weil bestimmte Elemente verpflichtend sind.

6. Metadaten-Standards wie DC müssen von Institutionen gepflegt werden, die verantwortungsbewußt die Weiterentwicklung leiten und die Anwendung überwachen.
Es ist noch unklar, wie die Pflege des DC-Standards und ähnlicher Normen organisiert werden wird. Man muß fragen, wer die amtliche Liste der Element-Spezifikationen führen wird, die für jede Bewertung und Beurteilung von Daten aus den verschiedensten Quellen notwendig ist. Die verantwortliche Stelle und Überwachungseinrichtung für AACR2 ist das Joint Steering Committee. Verantwortlich für USMARC sind MARBI das Network Development and MARC Standards Office und die Library of Congress. Für den TEI-Standard gibt es eine solche Autorität im Gewand der TEI-Herausgeber und eines TEI-Bearbeitungsverfahrens. Keine solche Einrichtung existiert bislang für den Dublin Core. Wer soll, wer kann diese Aufgabe übernehmen?

Charles A. Cutter formulierte als erster die "objectives" (Ziele), die ein Bibliothekskatalog verfolgen soll (und diese haben sich z.T. auch in den RAK, Paragr. 101, niedergeschlagen):
Der Katalog soll nachweisen,

• ob eine bestimmte, gesuchte Ausgabe eines Werks vorhanden ist [daher die genaue bibliographische Beschreibung]
• welche Werke eines Verfassers vorhanden sind [deshalb die Normierung der Personennamen]
• welche verschiedenen Ausgaben eines Werkes vorhanden sind [daher die Einheitssachtitel z.B. für Übersetzungen] und
• welche Werke zu einem vorgegebenen Thema vorhanden sind. [daher die Normierung der Sacherschliessung]

1996 hatte ich das Vergnügen, mit mehreren Exponenten der Metadaten-Szene in Göttingen zusammenzutreffen. In einer Studentenkneipe kam die Sprache auch auf die Frage, wo denn schon nennenswerte Verwertungen von DC-Daten zu beobachten seien. Die einzigen Versuche, die man nennen konnte, bestanden in einer schlichten Verstichwortung des gesamten META-Bereichs im HTML-Header. Darauf meinte ich, dazu brauche man keinen Dublin Core mit 15 Elementen, dazu könnten wir uns auf einen "Göttinger Kern" mit nur einem Element einigen. Leider versäumten wir, diesen neuen Entwurf auf einem Bierdeckel zu skizzieren, und so geriet dieser Ansatz zu einer durchgreifenden Simplifizierung wieder in Vergessenheit. Beim nächsten META-LIB-Treffen sollte ihn jemand wieder auf den (Bier-)Tisch bringen.