Thomas Volcan - Metadatenstandards Und Deren Implementation

Seminararbeit
Metadatenstandards und deren Implementation
Thomas Volcan
12. Juli 2002
Betreuer: Dipl.-Ing. Harald Krottmaier
Keywords: Metadaten, Dublin Core, MARC, UNIMARC, USMARC, RDF, Markuplan-

guages, XML, HTML, Hyperwave Atrribute, Speichern, Editieren, Open Archive Initiative
(OAI)
1
Inhaltsverzeichnis
1 Einleitung 4
2 Dublin Core (DC) 5

2.1 Dublin Core Metadata Element Set, Version 1.1 . . . . . . . . . . . . . . . 5
2.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 MAchine Readable Catalogue (MARC) 8

3.1 Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Warum MARC Records? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Vorteil von MARC Records . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 MARC 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Tags, Indikatoren und Subfields in MARC 21 . . . . . . . . . . . . . . . . . 9
4 UNIMARC 11
4.1 Formelle Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 Generelle Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2 Record Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3 Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4 Data Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.5 Pflichtfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 Resource Description Framework (RDF) 16

5.1 Resource, Property und Statement . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Unterschiede zu XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6 eXtensible Markup Language (XML) 19

6.1 Unterschiede zu HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2 Document Type Definition (DTD) . . . . . . . . . . . . . . . . . . . . . . . 20
7 Hyperwave-Attribute 21
7.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3 Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4 Editieren von Attributen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2
8 Open Archive Initiative (OAI) 24
8.1 Motivation und Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2 Das OAI – Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2.1 Warum Dublin Core? . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3 Protocol for Metadata Harvesting (PMH) . . . . . . . . . . . . . . . . . . . 25
9 Zusammenfassung 27
Literaturverzeichnis 28
3
Zusammenfassung
Metadaten, also Daten, die Daten genauer beschreiben, werden bei der steigenden Infor-
mationsflut immer wichtiger. Um Daten zu kategorisieren, sortieren und dann auch wieder
möglichst schnell auffindbar zu machen, müssen geeignete Löungen für die Speicherung der
Metadaten gefunden werden. Diese Arbeit beschäftigt sich nun mit verschiedenen Lösungs-
ansätzen. Insbesondere wird auf die Verwendung von Hyperwave Attributen und Markup-
sprachen wie XML, HTML und MARC bzw. RDF eingegangen. Weiterführend beschäftigt
sich diese Arbeit mit dem Editieren und Parsen von XML-Dateien, mit DTDs und dem
Austausch von Metadaten, der am Beispiel der Open Archive Initiative veranschaulicht
wird.
4
1 Einleitung
Metadaten werden in der Zeit der ständig wachsenden Informationsflut immer wichtiger.
Laut Statistiken verdoppelt sich die Anzahl der im Internet verfügbaren Dokumente inner-
halb weniger Monate [Harald Forstinger 1999]. Vor allem in Hinsicht auf die kategorisierte
Speicherung und eine möglichst schnelle und präzise Wiederauffindung von relevanten Do-
kumenten und Objekten wird es immer wichtiger, sich auch Gedanken über die Art und
Weise der Speicherung von Daten und vor allem auch Metadaten zu machen.
Um diesem Ziel immer näher zu kommen, wurden im Laufe der Zeit verschiedene Element–
Sets für die Katalogisierung und Beschreibung literarischer Werke entwickelt. Diese reichen
vom relativ einfachen Dublin Core bis zum komplexen MARC und den darauf aufbauenden
Abwandlungen wie USMARC, CANMARC, UKMARC etc.
Initiativen, wie die hier besprochene Open Archive Initiative (OAI), versuchen einen Infor-
mationsaustausch über geografische Grenzen hinweg zu erleichtern und zu standartisieren.
Um dies zu ermöglichen, werden Element Sets in Markup Languages wie z.B. XML einge-
bunden.
In dieser Arbeit soll nun das eher einfache Dublin Core, sowie das komplexere MARC
Schema vorgestellt werden. Weiters wird auf Markup–Languages wie XML eingegangen,
welche für einen Datenaustausch geeignet sind und zum Beispiel von der, kurz besproche-
nen, Open Archive Initiative verwendet werden.
Im Anhang soll kurz erläutert werden, wie Metadaten zu Artikeln, die auf einem Hyperwave–
Server (J.UCS1 ) gespeichert sind, in ein XML–Format konvertiert werden. Dies soll gesche-
hen, um Metadaten mit der OAI auszutauschen.
1
Journal of Universal Computer Science http://www.jucs.org
5
2 Dublin Core (DC)
Seinen Namen hat Dublin Core vom ersten einer Reihe Workshops, der bereits 1995 in
Dublin, Ohio stattgefunden hat. Dublin Core wurde unter internationaler Beteiligung ent-
wickelt. Genauere und ständig die neuesten Informationen erhält man auf der Homepage
der DCMI2
Die Dublin Core Metadata Initiative ist ein offenes Forum das sich mit der Entwicklung
von kompatiblen Metadaten Standards, welche für einen breiten Anwendungsbereich ein-
setzbar sind, beschäftigt. Die Aktivitäten des DCMI sind vielfältig um den Standard so
weit wie möglich zu verbreiten [Initiative 2002].
2.1 Dublin Core Metadata Element Set, Version 1.1

Diese Definition benutzt einen formalen Standard von Metadatenbeschreibung, wobei die
Formalisierung der Wahrung der Konsistenz mit anderen Metadaten–Communities hilfreich
sein soll.
Jedes Dublin Core Element besteht definierter Weise, aus einem Set von 10 Attributen,
welche der ISO/IEC 111793 Norm zur Beschreibung von Datenelementen genügen (dies ist
der Unterschied zur Version 1.0 beschrieben in [Weibel et al. 1998]). Sechs der Attribute
besitzen immer den gleichen Wert (in der folgenden Liste als Default–Werte angeführt):
• Name: der Name für dieses Datenelement
• Identifier: ein eindeutiger Schlüssel für dieses Datenelement
• Version (default: 1.1): die Version dieses Datenelements
• Registration Authority (default: Dublin Core Metadata Initiative): Schlüssel

des Autorisierten dieses Datenelement anzulegen
• Language (default: en): die Sprache, in der dieses Datenelement spezifiziert ist
• Definition: eine aussagekräftige Beschreibung für dieses Element
• Obligation (default: Optional): beschreibt, ob es vorhanden sein muss oder nicht
• Datatype (default: Character String): beschreibt, von welchem Datentyp der

Wert dieses Elements ist
• Maximum Occurrence (default: Unlimited): beschreibt die maximale Anzahl

von Wiederholungen diese Elements
• Comment: zusätzliche Anmerkung

2
http://dublincore.org/
3
nähere Informationen zu dieser Norm siehe unter ftp://sdct-sunsrv1.ncsl.nist.gov/x3l8/11179/
6
Die 15 Dublin Core Elemente werden nun durch die 10 oben angeführten Attribute be-
schrieben, wobei eben jene 6 Attribute für jedes Element gleich sind. Da ”Obligation”
immer den Wert ”Optional” enthält kann natürlich jedes Element fehlen.
Die 15 Elemente sind:
• DC.Title: Name der Ressource
• DC.Creator: die für den Inhalt verantwortliche Person oder Organisation
• DC.Subject: Thema des Inhalts
• DC.Description: Zusammenfassung des Inhalts
• DC.Publisher: Organisation oder Person die den Inhalt zugänglich gemacht hat
• DC.Contributor: Organisation oder Person die eine Beitrag zum Inhalt der Res-
source geleistet hat
• DC.Date: üblicherweise das Erstellungsdatum
• DC.Type: Art der Ressource
• DC.Format: digitale oder physikalische Repräsentation der Ressource
• DC.Identifier: eindeutige Referenz der Ressource (z.B. ISBN Nummer, URL)
• DC.Source: Quelle der Ressource
• DC.Language: Sprache des Inhalts
• DC.Relation: Referenz zu anderen, verwandten Ressourcen
• DC.Coverage: Bereich, den der Inhalt abdeckt (Zeitraum, geographisches Gebiet...)
• DC.Rights: Information zu den mit der Ressource verknüpften Rechten (z.B. Copy-
right)
Als Beispiel ein vollständiges Datenelement:
Name: Resource Identifier

Identifier: Identifier
Version: 1.1
Registry Authorisation: Dublin Core Metadata Initiative
Language: en
Definition: An unambiguous reference to the resource
7
within a given context.
Obligation: Optional
Datatype: Character String
Maximum Occurrence: Unlimited
Comment: Recommended best practice is to identify the
resource by means of a string or number
conforming to a formal identification system.
Example formal identification systems
include the Uniform Resource Identifier
(URI) (including the Uniform Resource
Locator (URL)), the Digital Object
Identifier (DOI) and the International
Standard Book Number (ISBN).
2.2 Zusammenfassung
Zusammenfassend kann man sagen, dass Dublin Core für Beschreibungen von Büchern etc.
in groben Zügen durchaus geeignet ist. Allerdings ist Dublin Core schon veraltet.
Ein weiterer Nachteil ist, dass Dublin Core der völlig objektiven Beschreibung von Res-
sourcen dient. Somit bietet DC auch keine Möglichkeit, Ressourcen zu bewerten oder zu
kritisieren. Diese Tätigkeit wird ohnehin nicht von Bibliothekaren durchgeführt, sondern
von Kritikern, Prüfern und Publizisten [Johann Weitzer 2000].
8
3 MAchine Readable Catalogue (MARC)
In diesem Abschnitt soll einer der Wegbereiter der elektronischen Metadaten Formate be-
schrieben werden. MARC4 ist eigentlich nicht ein einziges Format sondern eine Familie
von Formaten mit ähnlicher Struktur. Diese nationalen Formate (z.B. UK-MARC, US-
MARC...) haben sich auf Grund unterschiedlicher lokaler Anforderungen, wie z.B. zwei-
sprachige Beschreibungen oder unterschiedliche Zahlen– und Datumsformate, entwickelt.
Selbst innerhalb dieser ”Untervarianten” haben sich Abwandlungen ausgebildet.
3.1 Begriffe
• Machine–Readable bedeutet nichts anderes, als dass eine bestimmte Art von Ma-
schine, z.B. ein Computer, die Daten lesen und interpretieren kann.
• Cataloging Record ist ein bibliographischer Record, oder im ”traditionellen” Sinn

eine Karteikarte.
3.2 Warum MARC Records?

Es ist nicht unbedingt zielführend die Informationen einer Karteikarte einfach in einen
Computer einzugeben (oder einzuscannen), ohne dem System weitere Informationen über
die Art der Interpretation dieser Daten bereit zu stellen. Deshalb steht in einem MARC
record vor jeder noch so kleinen Information eine codierte Beschreibung über selbige.
3.3 Vorteil von MARC Records

Ein Vorteil von MARC Records liegt darin, dass die Felder (z.B. für Autor, Titel usw.)
nicht begrenzt, sondern erweiterbar sind und die Einträge von variabler Länge sein können.
Die Erweiterbarkeit ist notwendig, da z.B. einige Bücher Teile von Serien sein können, ein
katalogisierter Artikel könnte Bestandteil einer Artikelreihe aus einer monatlich erschei-
nenden Zeitschrift sein usw. Man sieht schnell, dass es sehr kompliziert werden kann, wenn
man all diese Informationen in vernünftiger Art und Weisse aufbereiten und abspeichern
will. Um dies zu ermöglichen, ist es also unbedingt notwendig, eine unbegrenzte, aber trotz-
dem strukturierte Anzahl von Feldern mit variabler Länge zur Verfügung zu haben.
Ein Computer kann nun nicht mehr damit rechnen, dass eine gewisse Information in jedem
bibliographischen Record an einer bestimmten Stelle beginnt und nach einer bestimmten
Anzahl von Bytes wieder endet. Deshalb beinhaltet ein MARC Record eine Art von ”In-
haltsverzeichnis” und ”Hinweise” wie ein Wert zu interpretieren ist für das Record, welches
einem gewissen Standard folgt.
Es gibt eine Vielzahl von Systemen für Bibliotheken, welche mit dem MARC Standard
umgehen können.
4
machine readable catalogue
9
3.4 MARC 21
Die Library of Congress, eine zentrale Anlaufstelle in den USA, wenn es um Publikationen
geht, hat bereits in den 60er Jahren begonnen, Computer für die Verwaltung ihrer Daten
zu verwenden. Zu dieser Zeit wurde das LC MARC Format ins Leben gerufen, welches
kurze Kombinationen aus Zahlen, Buchstaben und Sonderzeichen verwendet, um verschie-
dene Informationstypen zu kennzeichnen. Aus ständiger Weiterentwicklung ist schließlich
das MARC 21 Format entstanden, welches Standard für die am weitesten verbreiteten bi-
bliothekarischen Computersysteme und –programme Verwendung findet.
MARC 21 ist auch vom Speicherverbrauch interessant. Als Beispiel soll hier der Bereich,
welcher die Publikation eines Buches betrifft herausgepickt werden:
Ein herkömmlicher Datensatz Ausschnitt könnte so aussehen:
place of publication: New York

name of publisher: Lothrop, Lee & Shepard Books
date of publication: 1987
Der entsprechende Ausschnitt aus MARC 21 würde folgendermaßen aussehen:
260 ## $a New York

$b Lothrop, Lee & Shepard Books
$c 1987
3.5 Tags, Indikatoren und Subfields in MARC 21

Im obigen Beispiel sieht man dass MARC 21 Tags verwendet, um Bereiche in einem Record
zu markieren (z.B. ”260” betrifft Publikationsdaten). Diesen Tags folgen 2 Indikatoren (je-
weils eine Zahl von 0 – 9). Werden sie nicht verwendet, so werden sie durch den Platzhalter
”#” oder ein BLANK ersetzt. Manche Tags können zusätzlich noch Subfelder beinhalten.
Diese werden durch ”$a”, ”$b” usw. gekennzeichnet.
Zur Verdeutlichung noch 2 weitere Beispiele:
• 245 #4 $a Die Keltennadel
Das Tag ”245” markiert das Titelfeld, Subfeld ”$a” bezeichnet den Haupttitel. Indi-
kator 1 ist hier nicht definiert (”#”), interessant ist aber der 2. Indikator (die Ziffer
”4”): Dieser bedeutet nämlich, dass die ersten Zeichen des Titels (in diesem Fall eben
4) bei der Katalogisierung und Sortierung nicht berücksichtigt werden sollen. Dieses
Buch findet man also unter ”K”.
10
• 300 ## $a 675 p. : $b ill. ; $c 24 cm.
Tag ”300” markiert den Bereich für physikalische Angaben, die 2 Indikatoren sind
nicht definiert, die Subfields ”$a”, ”$b”, ”$c” stehen für ”Seitenanzahl”, ”weitere
physikalische Details” und ”Dimension in Zentimetern”.
3.6 Zusammenfassung
Zusammenfassend kann man sagen, dass MARC mit Sicherheit als Wegbereiter der elek-
tronischen Metadaten Formate bezeichnet werden kann. Leider ist die Verwendung von
MARC sehr kompliziert und verlangt dementsprechende, fortgeschrittene Kenntnisse in
der Katalogisierung. Für Bibliotheken, welche alte Katalogisierungssysteme betreiben, ist
MARC aber vielleicht der beste Weg, neue elektronische Ressourcen in die alten Kataloge
zu integrieren.
11
4 UNIMARC
Die Hauptzielsetzung von UNIMARC ist die Vereinfachung des internationalen Austau-
sches von bibliographischen, machine-readable Daten. Dabei ist UNIMARC so generell
gehalten, dass es auch für die Entwicklung und den Entwurf weiterer bibliographischer,
machine-readable Formate geeignet ist.
UNIMARC, das als ein Austauschformat entwickelt wurde, spezifiziert die Bezeichner, wel-
che bibliographischen Records zugeordnet sind. Das Format kann für einen weiten Bereich
verwendet werden. Beispiele wären Bücher, elektronische Ressourcen, kartographisches Ma-
terial usw.
Die Herausgeber des Manuals für USMARC (1994) waren Brian P. Holt von der British
Library5 sowie Sally H. McCallum von der Library of Congress6 .
4.1 Formelle Struktur

Im Folgenden soll die formelle Struktur von UNIMARC beschrieben werden.
4.1.1 Generelle Struktur

UNIMARC ist eine spezifizierte Implementation des ISO 2709 Standards. Diese internatio-
nale Norm beschreibt die Struktur von Records, welche bibliographische Daten beinhalten.
Um dieser Norm zu entsprechen, muss ein Record aus folgenden 3 Elementen bestehen:
4.1.2 Record Label

Er besteht immer genau aus 24 Zeichen, die den Record wie folgt, genau in dieser Reihen-
folge beschreiben:
• Record length (5 Zeichen, Position 0–4): Beinhaltet die Zeichenanzahl aus der
der gesamte Record besteht. Falls notwendig wird diese 5–stellige Zahl links mit
Nullen aufgefüllt.
• Record status (1 Zeichen, Position 5): Beinhaltet ”c” für einen korrigierten
Record, ”d” für einen gelöschten, nicht mehr gültigen Record, ”n” für einen neuen
Record, ”o” ein neuer Record in einer hierarchisch niedrigeren Ebene publiziert als
ein vorheriger, oder ”p” ein Record für ein publiziertes Element, welches ein vorher
publiziertes Element ersetzen soll.
• Implementation codes (4 Zeichen, Position 6–9): Diese 4 Zeichen sind nicht im

ISO 2709 Standard definiert, sind aber in den verschiedenen Implementationen dieses
Standards zu finden. Im UNIMARC Format haben die 4 Zeichen folgende Bedeutung:
5
Homepage: http://www.bl.uk/
6
Homepage: http://lcweb.loc.gov/
12
– Position 6, Type of Record: Position 6 im Record Label beschreibt die Art
des Records und kann folgende Werte beinhalten:
a sprachliches Material, gedruckt

b sprachliches Material, Manuskript
c Musiknoten, gedruckt
d Musiknoten, Manuskript
e Kartographisches Material, gedruckt
f Kartographisches Material, Manuskript
g Projektions– und Videomaterial (Videoaufzeichnungen, Filme...)
i Tonaufzeichnungen, nicht musikalisch (Ansprachen...)
j Tonaufzeichnungen, musikalisch (Konzerte...)
k Zweidimensionale Grafiken (Bilder, Skizzen, etc.)
l Elektronische Ressourcen
m Multimediale Ressourcen
r Dreidimensionale Artefakte und Realitäten
– Position 7, Bibliographic level: Kann einen der 4 folgenden Zeichen bein-
halten:
a ist physikalisch in einem anderen Gegenstand enthalten

m ist komplett in einem Gegenstand oder in einer endlichen Anzahl
s ist Teil einer Serie
c ist Teil einer Sammlung
– Position 8, Hierarchical level code: An dieser Position im Record wird die
hierarchische Beziehung durch eines der folgenden 4 Zeichen beschrieben:
# undefinierte hierarchische Beziehung

0 keine hierarchische Beziehung
1 Record der höchsten Ebene
2 Record unter der höchsten Ebene
(alle darunterliegenden)
– Position 9, Undefined: Dieses Zeichen ist in UNIMARC nicht definiert und
beinhaltet ein Leerzeichen (blank).
• Indicator length (1 Zeichen, Position 10): Eine Ziffer, welche die Länge des
Indikators angibt. In UNIMARC ist dies unveränderlich ”2”!
• Subfield identifier length (1 Zeichen, Position 11): Gibt an, wie lang ein Sub-
field Identifier (z.B. ”$a”) ist. In UNIMARC ist dieser Wert unveränderlich ”2”!
• Base adress of data (5 Zeichen, Position 12–16): Fünf Ziffern, wenn nötig mit
voranstehenden Nullen. Geben an, welcher Stelle, relativ zum Record Beginn, das
erste Zeichen des ersten Datenfeldes steht.
13
• Additional record definition (3 Zeichen, Position 17–19): Diese Zeichen geben
weitere, nötige Informationen für die Datensatzverarbeitung an:
– Position 17, Encoding level: Position 17 beschreibt generell den Grad der
Fertigstellung des Records:
# (blank) fertiggestellt
1–3 Sublevels
– Position 18, Descriptive cataloguing form: Dieses Zeichen zeigt an, ob die
beschreibenden Felder (”200-225”) der ISBD7 entsprechen:
# (blank) entspricht zur Gänze ISBD

i teilweise in ISBD
n nicht in ISBD
– Position 19, Undefined: Dieses Zeichen ist in UNIMARC nicht definiert und
enthält ein Blank.
• Directory map (4 Zeichen, Position 20–23): Diese Zeichen beinhalten Informa-

tionen über die Directory Entries jedes UNIMARC Feldes.
– Position 20, Length of ”Length of field”: Dieses Feld hat in UNIMARC

unveränderlich den Wert ”4”, was zugleich eine maximale Feldlänge von ”9,999”
bedeutet.
– Position 21, Length of ”Starting character position”: Wert in UNIMARC
ist ”5”. Somit wird eine ungefähre Record – Länge von ”100,000” Zeichen
erlaubt.
– Position 22, Length of ”implementationdefinedportion”: Gibt die Länge
des implementationsdefinierten Teils jedes Directories an. Da dieser Teil in UNI-
MARC nicht existiert, ist der Wert ständig ”0”.
– Position 23, Undefined: Nicht definiert, beinhaltet ein Leerzeichen.
4.1.3 Directory
Es folg direkt auf den Record Label. Jeder Eintrag im Directory besteht aus 3 Teilen:
• einem 3–stelligen nummerischen Tag,
• einer 4–stelligen Zahl, welche die Länge des Data Fields wiedergibt und
• einer 5–stelligen Zahl, welche die Stelle des ersten Zeichens wiedergibt.
Es sind keine weiteren Zeichen zugelassen!
7
International Standard Bibliographic Description
14
4.1.4 Data Fields
Die Datenfelder folgen wieder direkt dem Directory. Sie besitzen allerdings eine variable
Länge und beinhalten im Allgemeinen bibliographische Daten.
Data Control Fields (sie beginnen mit 00x, also z.B. 001) bestehen nur aus Daten und
einem End-Of-Field Byte.
Data (Control) Field (00x) Layout:
Data F/T (Terminator)
Alle anderen Datenfelder beinhalten 2 Indicator Felder, auf die eine beliebige Anzahl von
Unterfeldern folgen kann. Jedes Subfeld beginnt mit einem Subfieldidentifier, bestehend
aus einem Trennsymbol, ISl (1/15 of ISO 646), und einem Subfield Code (ein alphabeti-
sches oder nummerisches Zeichen). Das letzte Subfeld wird mit dem end-of-field Terminator
beendet.
Data Field (01x to 999) Layout:
Indicators Subfield Identifier Other Subfields

Ind Ind $a (etc.) Data Data ..... F/T
1 2
Das letzte Datenzeichen innerhalb eines Records wird von einem End-Of-Field Zeichen
IS2, welcher in dieser Instanz des Records dann von einem End-Of-Record Zeichen IS3
(1/13 of ISO 646) gefolgt wird.
4.1.5 Pflichtfelder
Die nun aufgelisteten Felder müssen in einem gültigen UNIMARC Datensatz vorhanden
sein, kursiv geschriebene müssen sogar ohne Ausnahme in jedem Datensatz vorhanden sein
001,100,200,801:
001 RECORD IDENTIFIER
100 GENERAL PROCESSING DATA
101 LANGUAGE OF THE WORK (when applicable)
120 CODED DATA FIELD:
CARTOGRAPHIC MATERIALS GENERAL (cartographic items only)
123 CODED DATA FIELD:
CARTOGRAPHIC MATERIALS SCALE AND CO-ORDINATES (cartographic items only)
200 TITLE AND STATEMENT OF RESPONSIBILITY
($a title proper is the only mandatory subfield)
206 MATERIAL SPECIFIC AREA:
CARTOGRAPHIC MATERIALS MATHEMATICAL DATA (cartographic items only)
15
801 ORIGINATING SOURCE FIELD
Falls optionale Felder beim Konvertieren leer bleiben sollten und auch nicht durch
Konstanten oder Computer Algorithmen eingesetzt werden können, sollten sie zur Gänze
weggelassen werden. Ansonsten könnte Feld 101 aus obigem Beispiel etwa so aussehen:
101 |#$a|||
4.2 Zusammenfassung
MARC 21 ist sicher eines der wichtigsten Schemata, um die Lücke zwischen technischer Im-
plementation und der tatsächlichen Verwendung von Metadaten zu schliessen. Vor allem
wenn es um bibliographische Daten geht, eignet sich dieses Format für die strukturier-
te Speicherung von Metadaten hervorragend. Vorteilhaft ist, dass dieses Schema in einer
Vielzahl von bibliographischen Anwendungen und Systemen Verwendung findet. Leider ist
das Schema relativ kompliziert und erfordert gewisse Vorkenntnisse, was Katalogisierung
betrifft.
16
5 Resource Description Framework (RDF)
Das Resource Description Framework8 wurde vom World Wide Web Consortium sozusa-
gen als Nachfolger von PICS9 ins Leben gerufen. Wie der Name schon sagt ist RDF ein
Framework für Ressourcen–Beschreibung und Metadatenaustausch.
5.1 Resource, Property und Statement

• Als eine Resource kann alles das eine eindeutige URI10 besitzt, (z.B. jede Web–Seite,
einzelne Elemente eines XML–Dokuments) angesehen werden.
• Ein Property ist selbst eine Resource und hat einen Name. Bei einem Buch wäre
das z.B. der Autor, der Titel usw.
• Ein Statement besteht aus einer Resource, Property und Wert Kombination. Die-
se Teile werden auch als ”Subjekt”, ”Prädikat” und ”Objekt” bezeichnet. Ein Bei-
spiel für ein Statement wäre: ”Der Autor von http://www.xyz.org ist Franz Hu-
ber”. Der Wert ist in diesem Beispiel ein einfacher String (”Franz Huber”), könnte
aber wie das nächste Beispiel zeigt, selbst eine Resource sein: ”Die Startseite von
http://www.xyz.org/images/ ist http://www.xyz.org”.
5.2 Unterschiede zu XML

Beim Design des RDF wurde unter anderem auf Skalierbarkeit geachtet. Dies bedeutet, dass
RDF–Ausdrücke einfach und 3–teilig sind (Resource, Property und value). Deshalb sind
diese Ausdrücke leichter zu handhaben. XML hat in Hinsicht Skalierbarkeit im Vergleich
zu RDF zwei entscheidende Nachteile:
• In XML ist die Reihenfolge der vorkommenden Elemente signifikant und oft bedeu-
tungsvoll. Ob dies in einem Metadatensatz so sein sollte oder nicht, ist ein Streitfall.
Ist es wirklich wichtig, dass z.B. der Autor immer vor dem Buchtitel in einem Da-
tensatz aufscheint?
• In XML wäre z.B. folgendes Konstrukt erlaubt:
<Description>
The value of this property contains some text, mixed up
with child properties such as its temperature
(<Temp>48</Temp>) and longitude
(<Longt>101</Longt>). [&Disclaimer;]
</Description>
8
http://www.w3.org/RDF/
9
Platform for Internet Content Selection http://www.w3.org/PICS
10
Uniform Resource Identifier
17
Wenn man also XML–Dokumente im Speicher des Computers ablegt, kann es passie-
ren, dass man verwirrende Strukturen, welche Bäume, Graphen und Zeichenketten
vermischen, bekommt.
Andererseits ist die Verwendung einer Datenstruktur wie z.B. XML unverzichtbar. Der
vereinfachte Datenaustausch, welcher ein Design Ziel von RDF war, wird z.B. durch die
Verwendung eben solcher Datenformate erleichtert [Tim Bray 2001].
5.3 Aufbau
RDF–Daten bestehen aus Knoten und Attribut–Wert Paaren. Knoten können Instanzen
von anderen Metadaten oder jegliche Art von Web Ressource sein. Das RDF–Modell kann
auch als gerichteter Graph veranschaulicht werden. Dabei würden die Kanten zwischen
den Knoten die Attribute darstellen. Um Instanzen dieses Modells in Dateien zu speichern
kann z.B. XML verwendet werden.
5.4 Beispiel
Das untenstehende Metadatenfragment beschreibt in Dublin Core Terminologie eine Web-
adresse, wie leicht nachvollziehbar ist:
<rdf:rdf>
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification (Revised)<dc:title>
<dc:format>text/html<dc:format>
<dc:creator>
<rdf:Description>
<p:name>Dave Beckett</p:name>
<p:email>N/A</p:email>
</rdf:Description>
</dc:creator>
...
</rdf:Description>
</rdf:rdf>
Das Listing stammt übrigens von der beschriebenen Seite und wurde leicht modifiziert
[W3C 2002]. Der dazugehörige gerichtete Graph würde wie in Abbildung 1 dargestellt
aussehen.
5.5 Zusammenfassung
Wie auch der Vorgänger von RDF (PICS) enthält RDF selbst keine vordefinierten ”Voka-
beln” für die Erstellung von Metadaten.
18
http: //www.w3.org/TR/rdf−syntax−grammar
dc:title dc:format dc:creator
RDF/XML Syntax text/html

Specification (Revised)
p:name p:email
Dave Beckett N/A
Abbildung 1: RDF Metadaten als Graph veranschaulicht
19
6 eXtensible Markup Language (XML)
XML ist eine erweiterte Markup–Sprache. Sie ist eine vereinfachte Version von SGML
(Standard Generalized Markup Language). XML soll sich als Dokumentationsverarbei-
tungsstandard durchsetzen, so hofft es zumindest das W3C11 (World Wide Web Consorti-
um).
6.1 Unterschiede zu HTML

Der wesentliche Unterschied, neben syntaktischen Verschiedenheiten, im Vergleich zum
oben besprochenen HTML liegt darin, dass XML haupsächlich für Computer – Computer
Datenaustausch Verwendung findet. In XML sind nämlich keinerlei Elemente und Attri-
bute zu finden, welche die Darstellung beeinflussen. Es sind folglich nur strukturelle und
beschreibende Elemente und Attribute vorhanden.
Ein anderer, sehr grosser Vorteil gegenüber HTML ist die Erweiterbarkeit. Verschiedene
Fachgebiete benötigen natürlich auch verschiedene Tags um die, für sie relevante Informa-
tion in geeigneter, logischer Art und Weise zu beschreiben.
Die Beschreibung eines Buches könnte in XML z.B. so aussehen:
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

<!DOCTYPE book SYSTEM "book.dtd">
<book>
<title>Linux in a Nutshell</title>
<subtitle>A Desktop Quick Reference</subtitle>
:
<editor>
<firstname>Andy</firstname>
<lastname>Oram</lastname>
</editor>
:
<ISBN>1-56592-585-8</ISBN>
</book>
Von der ersten Zeile sollte man sich nicht einschüchtern lassen. Sie beschreibt mit ihren
zahlreichen Attributen nur welche XML Version verwendet wird, in welchem Zeichensatz
die Daten geschrieben worden sind und, ob der Parser noch weiter XML Dateien laden
muss (”standalone=’no’”) oder nicht (siehe oben).
Wie man sieht ist es also sehr einfach, eine eigene Markup Sprache zu definieren (es gibt
ja diesbezüglich keine Standards, was auch dem eigentlichen Sinn von XML widersprechen
würde). Aber wie überprüft man nun die Gültigkeit und die Korrektheit einer XML Datei?
In Zeile 2 des obigen Beispiels wird eine Datei namens ”book.dtd” mit ins Spiel gebracht:
11
Homepage: http://www.w3c.org
20
6.2 Document Type Definition (DTD)
Wäre im obigen Beispiel Zeile eins der Wert von standalone auf ”no” gesetzt, so müsste
der Parser weitere XML–Dokumete laden, wie zum Beispiel eine DTD um ein gültiges Do-
kument zu erhalten. Im obigen Fall wurde die DTD aber ohnehin in der 2. Zeile festgelegt.
Sinnvoller weise wurde die DTD im obigen Beispiel in einer eigenen Datei definiert (”book.dtd”).
Diese Datei beschreibt nun welche Elemente in einer XML Datei vorkommen dürfen. Ob
diese Elemente mehrfach vorkommen dürfen/müssen wird mit folgenden Operatoren ange-
geben:
Operator Bedeutung
(default) das Element muss genau einmal vorkommen
? das Element darf genau einmal oder nie vorkommen
+ das Element kommt mindestens einmal vor (1 ... N)
∗ es ist Egal wie oft das Element auftritt (0 ... N)
Für unser obiges Beispiel könnte eine DTD zum Beispiel folgendermassen aussehen:
<?xml version="1.0"?>
<!ELEMENT book(title, subtitle?, ..., editor,..., ISBN?)>
<!ELEMENT editor(firstname+, lastname)>
[McLaughlin 2000]
Eine genaue Beschreibung aller Möglichkeiten ist unter http://www.xml101.com/dtd/ zu
finden.
Unbedingt erforderlich ist eine DTD nicht. Wenn man allerdings Dokumente auf die Rich-
tigkeit überprüfen möchte, vor allem was die Verwendung und Verschachtelung von XML
Elementen und deren Attribute betrifft, wird man um eine DTD nicht herumkommen.
6.3 Zusammenfassung
XML ist wegen seiner Flexibilität und Erweiterbarkeit sicher gut für die Speicherung von
Metadaten geeignet. Dennoch ist es wichtig dass die verwendeten Tags einer Vereinbarung
folgen, um den Datenaustausch zu vereinfachen.
21
7 Hyperwave-Attribute
In diesem Abschnitt soll kurz auf die Struktur und die Attributverwaltung des Hyperwave12
Information Servers Version 6 (IS/6) eingegangen werden.
7.1 Allgemeines
Hyperwave IS/6 ist ein Knowledge Management System, das dem Benutzer mit einem
Standard Web Browser ermöglicht, Information und Wissen in einem technisch hoch ent-
wickelten System zu verwalten und zu verbreiten.
7.2 Struktur
IS/6 besitzt eine hierarchische Struktur, welche sich im Groben aus Collections und Do-
cuments zusammensetzt. Im Groben deshalb, weil es spezielle Typen von Collections (Se-
quence, Multi cluster, Language cluster und Alternative cluster), User– und Anchor Objects
gibt. Näheres zu den speziellen Typen findet man in den Hyperwave Dokumentationen, z.B.
im IS/6 User’s Guide [Hyperwave 2001].
Jedes Objekt, egal welchen Typs, besitzt mehrere Attribute. Diese Attribute beschrei-
ben zum Beispiel wie ein Objekt dargestellt wird, ob es editiert werden darf usw. Einige
dieser Attribute werden automatisch vom Server beim Erstellen eines Objektes zugeordnet,
andere können vom Benutzer festgelegt und/oder editiert werden.
7.3 Vorteile
Hyperwave vergibt zum Teil automatisch einige wichtige Attribute (Author, ObjectID,
Rights...). Andere können vom Benutzer, falls dieser die entsprechenden Rechte besitzt,
während dem Anlegen eines Objektes oder auch im Nachhinein über das Standard User
Interface oder geeignete Tools (z.B. Java Virtual Folders) angegeben oder verändert wer-
den. Sehr interessant ist auch die Möglichkeit, benutzerdefinierte Attribute an Objekte
”anzuhängen”. Diese können, sofern sie nicht den selben Name wie Standard Attribute
haben, frei wählbare Bezeichner bekommen.
7.4 Editieren von Attributen

Vorausgesetzt der User besitzt die entsprechenden Rechte, ist das Bearbeiten von Hyper-
wave – Attributen über das Standard UI (siehe Abbildung 2) oder auch über das von
Hyperwave entwickelte Tool ”Java Virtual Folders”, welches sowohl für Windows als auch
unter Linux verfügbar ist (siehe Abbildung 3), möglich. Die Java Virtual Folders sind von
der Bedienung her an den Dateiexplorer von Microsoft Windows angelehnt und erlauben
12
Homepage der Firma Hyperwave http://www.hyperwave.com
22
browsen in der Hyperwave Objekthierarchie.
Abbildung 2: Hyperwave Standard Dialog zum Editieren von Attributen
Softwareentwickler können Hyperwave Attribute auch mit Serversite Javascript oder

über die Verwendung von HW–Dokumentklassen anlegen, verändern und löschen.
7.5 Zusammenfassung
Hyperwaveattribute sind sicher zur Speicherung von Attributen geeignet. Ein Vorteil ist,
dass mehrere Attribute den selben Bezeichner haben dürfen ohne dass das System den Geist
aufgibt. Die Tatsache, dass die Attribute auch indiziert werden spricht zusätzlich für deren
Verwendung. Leider gibt es keine Möglichkeit Attribute in einer Hierarchie anzulegen.
23
Abbildung 3: Editieren von Hyperwaveattributen mit den Java Virtual Folders
24
8 Open Archive Initiative (OAI)
In diesem Abschnitt soll näher auf den Napster der Wissenschaft [Sietmann 2001]
eingegangen werden.
8.1 Motivation und Hintergrund

OAI wurde entwickelt, um Autoren eine möglichst reibungslose Zusammenarbeit in der
Veröffentlichung und Verbreitung von Information zu ermöglichen. OAI durchforstet In-
formationsdepots unter Verwendung von gemeinsamen Metadaten – Standards. Wenn ein
solcher Informationsspeicher diesem gemeinsamen Standard entspricht, kann er Teil einer
grösseren Community werden und somit den Wert seines eigenen Depots und den der Ge-
meinschaft anheben. Derzeit beteiligen sich zum Beispiel die Digital Library Federation,
CrossRef und OCLC13 rege an diesem Projekt.
Um dies zu ermöglichen wird die Arbeit auf 2 Bereiche aufgeteilt:
• Data Providers: Diese Teilnehmer machen ihre Daten über das OAI – Protokoll
erreichbar.
• Service Providers: Dies sind jene Teilnehmer, welche die Metadaten von den ver-
schiedenen Servern einsammeln und zur Verfügung stellen.
Wie Data– und Service Provider zusammenhängen können sieht man unter Abbildung 4.
Natürlich ist es möglich, dass eine einzelne Organisation für beide Bereiche zur Verfügung
steht. Dies ist in gewisser Hinsicht sogar sehr interessant, weil man dann einerseits An-
erkennung für zur Verfügung gestellte Information und andererseits zugleich Lob für die
Dienstleistung einheimsen kann.
8.2 Das OAI – Framework

OAI bietet nun ein technisches und organisatorisches Framework welches das einsammeln
von Metadaten, aus verteilt zur Verfügung gestellten Informationsdepots, erleichtert. Des-
halb muss dieses Framework aus einer Metadatendefinition und einem gemeinsamen Pro-
tokoll, welches die Teilnehmer verwenden, bestehen. Für den Datenaustausch wird XML
verwendet, in Hinsicht der Metadaten greift OAI auf ein kompatibles und erweiterbares
System, nämlich das Dublin Core Element Set zurück.
8.2.1 Warum Dublin Core?

Die wesentlichsten und zugleich für das OAI Framework interessantesten Gründe sind die
Folgenden:
13
Online Computer Library Center – ein weltweites Konsortium von Bibliotheken und Agenturen
25
Data Provider Service Prov.
Data Provider Service Prov.
Service Prov.
Abbildung 4: Eine Mögliche Verbindung von Service und Dataprovidern
• Einfachheit: Dublin Core ist von der Komplexität her ungefähr vergleichbar mit
einern herkömmlichen Karteikarte wie sie in einer Bücherei Verwendung findet. Mit
seinen 15 Descriptoren, wie z.B.: Autor, Titel, Untertitel, Erscheinungsdatum, ISBN,
usw., ist ein DC Elementset noch überschaubar.
• Lexikalische Kompatibilität: Dublin Core verwendet einen Satz von generell verständ-
lichen Descriptoren, welcher wiederum ein mapping auf andere, kompliziertere Da-
tenstandards erleichtert.
• Internationales Einverständnis in über 20 Ländern auf der ganzen Welt.
• Erweiterbarkeit: Dublin Core ist eine ökonomische Alternative zu viel komplexeren
Metadatenmodellen. Trotzdem bietet es aber die Flexibilität und Erweiterbarkeit,
sich auch an komplexere Metadatenstandards anpassen zu können.
8.3 Protocol for Metadata Harvesting (PMH)

Das OAI–PMH14 (Protocol for Metadata Harvesting) ist eine Ergänzung des http-Protokolls,
eine typische Implementation verwendet daher einen standard Web–Server. Dieser Server
14
http://www.openarchives.org/OAI/openarchivesprotocol.html
26
ist so konfiguriert, dass die OAI–PMH Requests sofort an Software weitergegeben wer-
den, welche mit diesen Requests umgehen kann. Ein abgesetzter OAI–PMH Request muss
entweder die ”HTTP GET” oder ”POST” Methode verwenden. Dabei ist zu beachten, dass
die POST–Methode den Vorteil einer uneingeschränkten Argumentlänge bietet. Es gibt eine
Basis–URL für alle Requests. Sie spezifiziert den Host, das verwendete Port und optio-
nal einen Pfad auf dem Server. Zusätzlich zu dieser Basis–URL besteht jeder Request aus
einer Liste von Argumenten, welche die Form ”key=value” haben. Jeder Request muss
mindestens ein Argument beinhalten. Argumente können in einer beliebigen Reihenfolge
übergeben werden. Mehrere Argumente, müssen durch ein ”&” getrennt sein. key ist immer
die Zeichenkette ”verb”, der Wert ist einer der definierten OAI–Requests (z.B. GetRecord,
Identify, ListIdentifiers...). Ein gültiger Request könnte also zum Beispiel folgendermassen
aussehen:
http://memory.loc.gov/cgi-bin/oai?verb=ListMetadataFormats
[Carl Lagoze 2002]
8.4 Zusammenfassung
Die Open Archive Initiative ist eine interessante Idee um internationalen Datenaustausch
im bibliographischen Bereich zu erleichtern. Als Protokoll eine Erweiterung des HTTP–
Protokolls zu verwenden ist sicherlich ein guter Ansatz. Derzeit wird noch sehr viel Ent-
wicklungsarbeit in das Projekt gesteckt und man ist sehr bemüht Erweiterungen und Ver-
besserungen einzubauen. Es bleibt zu hoffen, dass sich nicht einige kleinere Gruppierungen
herauskristallisieren, welche dann in Hinsicht Datenaustausch nicht mehr kompatibel sind
und damit der Grundidee des gesamten Projekts widersprechen.
27
9 Zusammenfassung
Metadatenformate und –standards im bibliographischen Bereich einzusetzen ist wichtig
und sinnvoll. Je nach Art der zu katalogisierenden Werke gibt es verschiedene geeignete
Standards. Diese reichen vom relativ einfachen Dublin Core bis zum wesentlich komplexer-
en MARC–Standard.
Da es eine Menge an verschiedenen Metadatenstandards gibt, war es nicht möglich auf

alle einzugehen. Aus diesem Grund fehlt auch eine Abhandlung über einige Formate wie
zum Beispiel BibTeX15 oder MPEG 716 .
XML ist wegen seiner Flexibilität und Erweiterbarkeit gut für die Speicherung von Meta-
daten geeignet. Dennoch ist es wichtig, dass die verwendeten Tags einer Vereinbarung
folgen, um einen Datenaustausch mit anderen Benutzern zu ermöglichen.
Dass internationaler Informationsaustausch auch in der Praxis gut funktionieren kann

zeigt die Open Archive Initiative recht eindrucksvoll. Derzeit wird noch sehr viel Zeit
in dieses Projekt investiert. Es ist sicher interessant zu verfolgen, wie sich der ”Napster der
Wissenschaft”[Sietmann 2001] weiterentwickelt.
15
http://www.ecst.csuchico.edu/~jacobsd/bib/formats/bibtex.html
16
http://mpeg.telecomitalialab.com/
28
Literatur
[Carl Lagoze 2002] ONLINE: Technical report, The OAI Executive,
last visited on 2002-07-05, The Open Archives Initiative Protocol
for Metadata Harvesting
http://www.openarchives.org/OAI/openarchivesprotocol.html.
[Harald Forstinger 1999] Harald Forstinger: Analyse gegenwärtiger Suchdienste und Kon-
zepte für künftige Wissensauffindung. Master’s thesis, IICM,
Graz University of Technology, 1999.
[Hyperwave 2001] Hyperwave: IS/6 User’s Guide, 2001.
[Initiative 2002] ONLINE: Technical report, Dublin Core Metadata Initiative,

last visited on 2002-12-06,
http://dublincore.org/.
[Johann Weitzer 2000] Johann Weitzer: Verwendung von Qualitäts–Metadaten zur

verbesserten Wissensauffindung und Testimplementierung im
xFIND System. Master’s thesis, IICM, Graz University of Tech-
nology, 2000.
[McLaughlin 2000] McLaughlin, B.: JAVA and XML. O’Reilly & Associates, Inc.,
101 Morris Street, Sebastopol, CA 95472, 2000.
[Sietmann 2001] Sietmann, R.: Napster für die Wissenschaft. c’t 6/2001, 2001.
[Tim Bray 2001] ONLINE: Technical report, O’Reilly xml.com,

last visited on 2002-07-05, What is RDF?
http://www.xml.com/pub/a/2001/01/24/rdf.html.
[W3C 2002] ONLINE: Technical report, W3C,

last visited on 2002-07-03, RDF/XML Syntax Specification (Re-
vised), W3C Working Draf
http://www.w3.org/TR/rdf-syntax-grammar/.
[Weibel et al. 1998] ONLINE: Technical report, The Internet Society,

last visited on 2002-12-06,
http://www.ietf.org/rfc/rfc2413.txt.
29

Thomas Volcan - Metadatenstandards Und Deren Implementation

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Thomas Volcan - Metadatenstandards Und Deren Implementation

Hochgeladen von

Copyright:

Verfügbare Formate

Seminararbeit

Metadatenstandards und deren Implementation

Betreuer: Dipl.-Ing. Harald Krottmaier

Keywords: Metadaten, Dublin Core, MARC, UNIMARC, USMARC, RDF, Markuplan-

2 Dublin Core (DC) 5

3 MAchine Readable Catalogue (MARC) 8

5 Resource Description Framework (RDF) 16

6 eXtensible Markup Language (XML) 19

2.1 Dublin Core Metadata Element Set, Version 1.1

• Name: der Name für dieses Datenelement

• Identifier: ein eindeutiger Schlüssel für dieses Datenelement

• Version (default: 1.1): die Version dieses Datenelements

• Registration Authority (default: Dublin Core Metadata Initiative): Schlüssel

• Definition: eine aussagekräftige Beschreibung für dieses Element

• Obligation (default: Optional): beschreibt, ob es vorhanden sein muss oder nicht

• Datatype (default: Character String): beschreibt, von welchem Datentyp der

• Maximum Occurrence (default: Unlimited): beschreibt die maximale Anzahl

• Comment: zusätzliche Anmerkung

Die 15 Elemente sind:

• DC.Title: Name der Ressource

• DC.Creator: die für den Inhalt verantwortliche Person oder Organisation

• DC.Subject: Thema des Inhalts

• DC.Description: Zusammenfassung des Inhalts

• DC.Date: üblicherweise das Erstellungsdatum

• DC.Type: Art der Ressource

• DC.Format: digitale oder physikalische Repräsentation der Ressource

• DC.Identifier: eindeutige Referenz der Ressource (z.B. ISBN Nummer, URL)

• DC.Source: Quelle der Ressource

• DC.Language: Sprache des Inhalts

• DC.Relation: Referenz zu anderen, verwandten Ressourcen

• DC.Coverage: Bereich, den der Inhalt abdeckt (Zeitraum, geographisches Gebiet...)

Als Beispiel ein vollständiges Datenelement:

Name: Resource Identifier

• Cataloging Record ist ein bibliographischer Record, oder im ”traditionellen” Sinn

3.2 Warum MARC Records?

3.3 Vorteil von MARC Records

place of publication: New York

Der entsprechende Ausschnitt aus MARC 21 würde folgendermaßen aussehen:

260 ## $a New York

3.5 Tags, Indikatoren und Subfields in MARC 21

• 245 #4 $a Die Keltennadel

4.1 Formelle Struktur

4.1.1 Generelle Struktur

4.1.2 Record Label

• Implementation codes (4 Zeichen, Position 6–9): Diese 4 Zeichen sind nicht im

a sprachliches Material, gedruckt

a ist physikalisch in einem anderen Gegenstand enthalten

# undefinierte hierarchische Beziehung

# (blank) entspricht zur Gänze ISBD

• Directory map (4 Zeichen, Position 20–23): Diese Zeichen beinhalten Informa-

– Position 20, Length of ”Length of field”: Dieses Feld hat in UNIMARC

Data (Control) Field (00x) Layout:

Data F/T (Terminator)

Data Field (01x to 999) Layout:

Indicators Subfield Identifier Other Subfields

5.1 Resource, Property und Statement

5.2 Unterschiede zu XML

dc:title dc:format dc:creator

RDF/XML Syntax text/html

Dave Beckett N/A

Abbildung 1: RDF Metadaten als Graph veranschaulicht

6.1 Unterschiede zu HTML

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>