Seminararbeit Metadatenstandards und deren Implementation
Thomas Volcan 12. Juli 2002 Betreuer: Dipl.-Ing. Harald Krott...
13 downloads
689 Views
493KB Size
Report
This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form
Seminararbeit Metadatenstandards und deren Implementation
Thomas Volcan 12. Juli 2002 Betreuer: Dipl.-Ing. Harald Krottmaier
Keywords: Metadaten, Dublin Core, MARC, UNIMARC, USMARC, RDF, Markuplanguages, XML, HTML, Hyperwave Atrribute, Speichern, Editieren, Open Archive Initiative (OAI)
1
Inhaltsverzeichnis 1 Einleitung
4
2 Dublin Core (DC) 2.1 Dublin Core Metadata Element Set, Version 1.1 . . . . . . . . . . . . . . . 2.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 5 7
3 MAchine Readable Catalogue (MARC) 3.1 Begriffe . . . . . . . . . . . . . . . . . . . . . 3.2 Warum MARC Records? . . . . . . . . . . . . 3.3 Vorteil von MARC Records . . . . . . . . . . 3.4 MARC 21 . . . . . . . . . . . . . . . . . . . . 3.5 Tags, Indikatoren und Subfields in MARC 21 . 3.6 Zusammenfassung . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
8 8 8 8 9 9 10
4 UNIMARC 4.1 Formelle Struktur . . . . . 4.1.1 Generelle Struktur 4.1.2 Record Label . . . 4.1.3 Directory . . . . . 4.1.4 Data Fields . . . . 4.1.5 Pflichtfelder . . . . 4.2 Zusammenfassung . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
11 11 11 11 13 14 14 15
5 Resource Description Framework (RDF) 5.1 Resource, Property und Statement . . . 5.2 Unterschiede zu XML . . . . . . . . . . . 5.3 Aufbau . . . . . . . . . . . . . . . . . . . 5.4 Beispiel . . . . . . . . . . . . . . . . . . 5.5 Zusammenfassung . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
16 16 16 17 17 17
6 eXtensible Markup Language (XML) 6.1 Unterschiede zu HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Document Type Definition (DTD) . . . . . . . . . . . . . . . . . . . . . . . 6.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19 19 20 20
7 Hyperwave-Attribute 7.1 Allgemeines . . . . . . . 7.2 Struktur . . . . . . . . . 7.3 Vorteile . . . . . . . . . 7.4 Editieren von Attributen 7.5 Zusammenfassung . . . .
21 21 21 21 21 22
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
2
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
8 Open Archive Initiative (OAI) 8.1 Motivation und Hintergrund . . . . . . . . 8.2 Das OAI – Framework . . . . . . . . . . . 8.2.1 Warum Dublin Core? . . . . . . . . 8.3 Protocol for Metadata Harvesting (PMH) . 8.4 Zusammenfassung . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
24 24 24 24 25 26
9 Zusammenfassung
27
Literaturverzeichnis
28
3
Zusammenfassung Metadaten, also Daten, die Daten genauer beschreiben, werden bei der steigenden Informationsflut immer wichtiger. Um Daten zu kategorisieren, sortieren und dann auch wieder m¨oglichst schnell auffindbar zu machen, m¨ ussen geeignete L¨oungen f¨ ur die Speicherung der Metadaten gefunden werden. Diese Arbeit besch¨aftigt sich nun mit verschiedenen L¨osungsans¨atzen. Insbesondere wird auf die Verwendung von Hyperwave Attributen und Markupsprachen wie XML, HTML und MARC bzw. RDF eingegangen. Weiterf¨ uhrend besch¨aftigt 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 st¨andig wachsenden Informationsflut immer wichtiger. Laut Statistiken verdoppelt sich die Anzahl der im Internet verf¨ ugbaren Dokumente innerhalb weniger Monate [Harald Forstinger 1999]. Vor allem in Hinsicht auf die kategorisierte Speicherung und eine m¨oglichst schnelle und pr¨azise Wiederauffindung von relevanten Dokumenten 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 n¨aher zu kommen, wurden im Laufe der Zeit verschiedene Element– Sets f¨ ur 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 Informationsaustausch u ¨ber geografische Grenzen hinweg zu erleichtern und zu standartisieren. Um dies zu erm¨oglichen, werden Element Sets in Markup Languages wie z.B. XML eingebunden. 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 f¨ ur einen Datenaustausch geeignet sind und zum Beispiel von der, kurz besprochenen, Open Archive Initiative verwendet werden. Im Anhang soll kurz erl¨autert werden, wie Metadaten zu Artikeln, die auf einem Hyperwave– Server (J.UCS1 ) gespeichert sind, in ein XML–Format konvertiert werden. Dies soll geschehen, 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 entwickelt. Genauere und st¨andig die neuesten Informationen erh¨alt 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 f¨ ur einen breiten Anwendungsbereich einsetzbar sind, besch¨aftigt. Die Aktivit¨aten des DCMI sind vielf¨altig um den Standard so weit wie m¨oglich 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 gen¨ ugen (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 angef¨ uhrt): • Name: der Name f¨ ur dieses Datenelement • Identifier: ein eindeutiger Schl¨ ussel f¨ ur dieses Datenelement • Version (default: 1.1): die Version dieses Datenelements • Registration Authority (default: Dublin Core Metadata Initiative): Schl¨ ussel des Autorisierten dieses Datenelement anzulegen • Language (default: en): die Sprache, in der dieses Datenelement spezifiziert ist • Definition: eine aussagekr¨aftige Beschreibung f¨ ur 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: zus¨atzliche Anmerkung 2 3
http://dublincore.org/ n¨ahere 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 angef¨ uhrten Attribute beschrieben, wobei eben jene 6 Attribute f¨ ur jedes Element gleich sind. Da ”Obligation” immer den Wert ”Optional” enth¨alt kann nat¨ urlich jedes Element fehlen. Die 15 Elemente sind: • DC.Title: Name der Ressource • DC.Creator: die f¨ ur den Inhalt verantwortliche Person oder Organisation • DC.Subject: Thema des Inhalts • DC.Description: Zusammenfassung des Inhalts • DC.Publisher: Organisation oder Person die den Inhalt zug¨anglich gemacht hat • DC.Contributor: Organisation oder Person die eine Beitrag zum Inhalt der Ressource geleistet hat • DC.Date: u ¨blicherweise das Erstellungsdatum • DC.Type: Art der Ressource • DC.Format: digitale oder physikalische Repr¨asentation 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 verkn¨ upften Rechten (z.B. Copyright) Als Beispiel ein vollst¨andiges Datenelement: Name: Identifier: Version: Registry Authorisation: Language: Definition:
Resource Identifier Identifier 1.1 Dublin Core Metadata Initiative en An unambiguous reference to the resource 7
Obligation: Datatype: Maximum Occurrence: Comment:
2.2
within a given context. Optional Character String Unlimited 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).
Zusammenfassung
Zusammenfassend kann man sagen, dass Dublin Core f¨ ur Beschreibungen von B¨ uchern etc. in groben Z¨ ugen durchaus geeignet ist. Allerdings ist Dublin Core schon veraltet. Ein weiterer Nachteil ist, dass Dublin Core der v¨ollig objektiven Beschreibung von Ressourcen dient. Somit bietet DC auch keine M¨oglichkeit, Ressourcen zu bewerten oder zu kritisieren. Diese T¨atigkeit wird ohnehin nicht von Bibliothekaren durchgef¨ uhrt, sondern von Kritikern, Pr¨ ufern und Publizisten [Johann Weitzer 2000].
8
3
MAchine Readable Catalogue (MARC)
In diesem Abschnitt soll einer der Wegbereiter der elektronischen Metadaten Formate beschrieben werden. MARC4 ist eigentlich nicht ein einziges Format sondern eine Familie von Formaten mit ¨ahnlicher Struktur. Diese nationalen Formate (z.B. UK-MARC, USMARC...) haben sich auf Grund unterschiedlicher lokaler Anforderungen, wie z.B. zweisprachige 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 Maschine, 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 zielf¨ uhrend 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. f¨ ur Autor, Titel usw.) nicht begrenzt, sondern erweiterbar sind und die Eintr¨age von variabler L¨ange sein k¨onnen. Die Erweiterbarkeit ist notwendig, da z.B. einige B¨ ucher Teile von Serien sein k¨onnen, ein katalogisierter Artikel k¨onnte Bestandteil einer Artikelreihe aus einer monatlich erscheinenden Zeitschrift sein usw. Man sieht schnell, dass es sehr kompliziert werden kann, wenn man all diese Informationen in vern¨ unftiger Art und Weisse aufbereiten und abspeichern will. Um dies zu erm¨oglichen, ist es also unbedingt notwendig, eine unbegrenzte, aber trotzdem strukturierte Anzahl von Feldern mit variabler L¨ange zur Verf¨ ugung 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 ”Inhaltsverzeichnis” und ”Hinweise” wie ein Wert zu interpretieren ist f¨ ur das Record, welches einem gewissen Standard folgt. Es gibt eine Vielzahl von Systemen f¨ ur Bibliotheken, welche mit dem MARC Standard umgehen k¨onnen. 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 f¨ ur 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 verschiedene Informationstypen zu kennzeichnen. Aus st¨andiger Weiterentwicklung ist schließlich das MARC 21 Format entstanden, welches Standard f¨ ur die am weitesten verbreiteten bibliothekarischen 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 herk¨ommlicher Datensatz Ausschnitt k¨onnte so aussehen: place of publication: New York name of publisher: Lothrop, Lee & Shepard Books date of publication: 1987 Der entsprechende Ausschnitt aus MARC 21 w¨ urde 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 (jeweils eine Zahl von 0 – 9). Werden sie nicht verwendet, so werden sie durch den Platzhalter ”#” oder ein BLANK ersetzt. Manche Tags k¨onnen zus¨atzlich 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. Indikator 1 ist hier nicht definiert (”#”), interessant ist aber der 2. Indikator (die Ziffer ”4”): Dieser bedeutet n¨amlich, dass die ersten Zeichen des Titels (in diesem Fall eben 4) bei der Katalogisierung und Sortierung nicht ber¨ ucksichtigt werden sollen. Dieses Buch findet man also unter ”K”.
10
• 300 ## $a 675 p. : $b ill. ; $c 24 cm. Tag ”300” markiert den Bereich f¨ ur physikalische Angaben, die 2 Indikatoren sind nicht definiert, die Subfields ”$a”, ”$b”, ”$c” stehen f¨ ur ”Seitenanzahl”, ”weitere physikalische Details” und ”Dimension in Zentimetern”.
3.6
Zusammenfassung
Zusammenfassend kann man sagen, dass MARC mit Sicherheit als Wegbereiter der elektronischen Metadaten Formate bezeichnet werden kann. Leider ist die Verwendung von MARC sehr kompliziert und verlangt dementsprechende, fortgeschrittene Kenntnisse in der Katalogisierung. F¨ ur 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 Austausches von bibliographischen, machine-readable Daten. Dabei ist UNIMARC so generell gehalten, dass es auch f¨ ur die Entwicklung und den Entwurf weiterer bibliographischer, machine-readable Formate geeignet ist. UNIMARC, das als ein Austauschformat entwickelt wurde, spezifiziert die Bezeichner, welche bibliographischen Records zugeordnet sind. Das Format kann f¨ ur einen weiten Bereich verwendet werden. Beispiele w¨aren B¨ ucher, elektronische Ressourcen, kartographisches Material usw. Die Herausgeber des Manuals f¨ ur USMARC (1994) waren Brian P. Holt von der British 5 Library 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 internationale 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 Reihenfolge 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 aufgef¨ ullt. • Record status (1 Zeichen, Position 5): Beinhaltet ”c” f¨ ur einen korrigierten Record, ”d” f¨ ur einen gel¨oschten, nicht mehr g¨ ultigen Record, ”n” f¨ ur einen neuen Record, ”o” ein neuer Record in einer hierarchisch niedrigeren Ebene publiziert als ein vorheriger, oder ”p” ein Record f¨ ur 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 6
Homepage: http://www.bl.uk/ 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 b c d e f g i j k l m r
sprachliches Material, gedruckt sprachliches Material, Manuskript Musiknoten, gedruckt Musiknoten, Manuskript Kartographisches Material, gedruckt Kartographisches Material, Manuskript Projektions– und Videomaterial (Videoaufzeichnungen, Filme...) Tonaufzeichnungen, nicht musikalisch (Ansprachen...) Tonaufzeichnungen, musikalisch (Konzerte...) Zweidimensionale Grafiken (Bilder, Skizzen, etc.) Elektronische Ressourcen Multimediale Ressourcen Dreidimensionale Artefakte und Realit¨aten
– Position 7, Bibliographic level: Kann einen der 4 folgenden Zeichen beinhalten: a m s c
ist ist ist ist
physikalisch in einem anderen Gegenstand enthalten komplett in einem Gegenstand oder in einer endlichen Anzahl Teil einer Serie Teil einer Sammlung
– Position 8, Hierarchical level code: An dieser Position im Record wird die hierarchische Beziehung durch eines der folgenden 4 Zeichen beschrieben: # 0 1 2
undefinierte hierarchische Beziehung keine hierarchische Beziehung Record der h¨ochsten Ebene Record unter der h¨ochsten 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 L¨ange des Indikators angibt. In UNIMARC ist dies unver¨anderlich ”2”! • Subfield identifier length (1 Zeichen, Position 11): Gibt an, wie lang ein Subfield Identifier (z.B. ”$a”) ist. In UNIMARC ist dieser Wert unver¨anderlich ”2”! • Base adress of data (5 Zeichen, Position 12–16): F¨ unf Ziffern, wenn n¨otig 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, n¨otige Informationen f¨ ur 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 G¨anze ISBD i teilweise in ISBD n nicht in ISBD – Position 19, Undefined: Dieses Zeichen ist in UNIMARC nicht definiert und enth¨alt ein Blank. • Directory map (4 Zeichen, Position 20–23): Diese Zeichen beinhalten Informationen u ¨ber die Directory Entries jedes UNIMARC Feldes. – Position 20, Length of ”Length of field”: Dieses Feld hat in UNIMARC unver¨anderlich den Wert ”4”, was zugleich eine maximale Feldl¨ange von ”9,999” bedeutet. – Position 21, Length of ”Starting character position”: Wert in UNIMARC ist ”5”. Somit wird eine ungef¨ahre Record – L¨ange von ”100,000” Zeichen erlaubt. – Position 22, Length of ”implementationdefinedportion”: Gibt die L¨ange des implementationsdefinierten Teils jedes Directories an. Da dieser Teil in UNIMARC nicht existiert, ist der Wert st¨andig ”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 L¨ange 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 L¨ange 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 alphabetisches 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 m¨ ussen in einem g¨ ultigen UNIMARC Datensatz vorhanden sein, kursiv geschriebene m¨ ussen sogar ohne Ausnahme in jedem Datensatz vorhanden sein 001,100,200,801: 001 100 101 120
RECORD IDENTIFIER GENERAL PROCESSING DATA LANGUAGE OF THE WORK (when applicable) 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 k¨onnen, sollten sie zur G¨anze weggelassen werden. Ansonsten k¨onnte Feld 101 aus obigem Beispiel etwa so aussehen: 101 |#$a|||
4.2
Zusammenfassung
MARC 21 ist sicher eines der wichtigsten Schemata, um die L¨ ucke zwischen technischer Implementation und der tats¨achlichen Verwendung von Metadaten zu schliessen. Vor allem wenn es um bibliographische Daten geht, eignet sich dieses Format f¨ ur die strukturierte 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 sozusagen als Nachfolger von PICS9 ins Leben gerufen. Wie der Name schon sagt ist RDF ein Framework f¨ ur 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 w¨are das z.B. der Autor, der Titel usw. • Ein Statement besteht aus einer Resource, Property und Wert Kombination. Diese Teile werden auch als ”Subjekt”, ”Pr¨adikat” und ”Objekt” bezeichnet. Ein Beispiel f¨ ur ein Statement w¨are: ”Der Autor von http://www.xyz.org ist Franz Huber”. Der Wert ist in diesem Beispiel ein einfacher String (”Franz Huber”), k¨onnte aber wie das n¨achste 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–Ausdr¨ ucke einfach und 3–teilig sind (Resource, Property und value). Deshalb sind diese Ausdr¨ ucke 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 bedeutungsvoll. 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 Datensatz aufscheint? • In XML w¨are z.B. folgendes Konstrukt erlaubt: The value of this property contains some text, mixed up with child properties such as its temperature (48) and longitude (101). [&Disclaimer;] 8
http://www.w3.org/RDF/ Platform for Internet Content Selection http://www.w3.org/PICS 10 Uniform Resource Identifier 9
17
Wenn man also XML–Dokumente im Speicher des Computers ablegt, kann es passieren, dass man verwirrende Strukturen, welche B¨aume, 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 k¨onnen Instanzen von anderen Metadaten oder jegliche Art von Web Ressource sein. Das RDF–Modell kann auch als gerichteter Graph veranschaulicht werden. Dabei w¨ urden 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 Webadresse, wie leicht nachvollziehbar ist: RDF/XML Syntax Specification (Revised) text/html Dave Beckett N/A ... Das Listing stammt u ¨brigens von der beschriebenen Seite und wurde leicht modifiziert [W3C 2002]. Der dazugeh¨orige gerichtete Graph w¨ urde wie in Abbildung 1 dargestellt aussehen.
5.5
Zusammenfassung
Wie auch der Vorg¨anger von RDF (PICS) enth¨alt RDF selbst keine vordefinierten ”Vokabeln” f¨ ur die Erstellung von Metadaten. 18
http: //www.w3.org/TR/rdf−syntax−grammar
dc:title
RDF/XML Syntax Specification (Revised)
dc:format
dc:creator
text/html p:name
Dave Beckett
p:email
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 Dokumentationsverarbeitungsstandard durchsetzen, so hofft es zumindest das W3C11 (World Wide Web Consortium).
6.1
Unterschiede zu HTML
Der wesentliche Unterschied, neben syntaktischen Verschiedenheiten, im Vergleich zum oben besprochenen HTML liegt darin, dass XML haups¨achlich f¨ ur Computer – Computer Datenaustausch Verwendung findet. In XML sind n¨amlich keinerlei Elemente und Attribute zu finden, welche die Darstellung beeinflussen. Es sind folglich nur strukturelle und beschreibende Elemente und Attribute vorhanden. Ein anderer, sehr grosser Vorteil gegen¨ uber HTML ist die Erweiterbarkeit. Verschiedene Fachgebiete ben¨otigen nat¨ urlich auch verschiedene Tags um die, f¨ ur sie relevante Information in geeigneter, logischer Art und Weise zu beschreiben. Die Beschreibung eines Buches k¨onnte in XML z.B. so aussehen: Linux in a Nutshell <subtitle>A Desktop Quick Reference : <editor> Andy Oram : 1-56592-585-8 Von der ersten Zeile sollte man sich nicht einsch¨ uchtern 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 diesbez¨ uglich keine Standards, was auch dem eigentlichen Sinn von XML widersprechen w¨ urde). Aber wie u uft man nun die G¨ ultigkeit und die Korrektheit einer XML Datei? ¨berpr¨ 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)
W¨are im obigen Beispiel Zeile eins der Wert von standalone auf ”no” gesetzt, so m¨ usste der Parser weitere XML–Dokumete laden, wie zum Beispiel eine DTD um ein g¨ ultiges Dokument 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 d¨ urfen. Ob diese Elemente mehrfach vorkommen d¨ urfen/m¨ ussen wird mit folgenden Operatoren angegeben: Operator (default) ? + ∗
Bedeutung 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)
F¨ ur unser obiges Beispiel k¨onnte eine DTD zum Beispiel folgendermassen aussehen: [McLaughlin 2000] Eine genaue Beschreibung aller M¨oglichkeiten ist unter http://www.xml101.com/dtd/ zu finden. Unbedingt erforderlich ist eine DTD nicht. Wenn man allerdings Dokumente auf die Richtigkeit u ufen m¨ochte, vor allem was die Verwendung und Verschachtelung von XML ¨berpr¨ Elementen und deren Attribute betrifft, wird man um eine DTD nicht herumkommen.
6.3
Zusammenfassung
XML ist wegen seiner Flexibilit¨at und Erweiterbarkeit sicher gut f¨ ur 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 erm¨oglicht, Information und Wissen in einem technisch hoch entwickelten System zu verwalten und zu verbreiten.
7.2
Struktur
IS/6 besitzt eine hierarchische Struktur, welche sich im Groben aus Collections und Documents zusammensetzt. Im Groben deshalb, weil es spezielle Typen von Collections (Sequence, Multi cluster, Language cluster und Alternative cluster), User– und Anchor Objects gibt. N¨aheres 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 beschreiben 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 k¨onnen vom Benutzer festgelegt und/oder editiert werden.
7.3
Vorteile
Hyperwave vergibt zum Teil automatisch einige wichtige Attribute (Author, ObjectID, Rights...). Andere k¨onnen vom Benutzer, falls dieser die entsprechenden Rechte besitzt, w¨ahrend dem Anlegen eines Objektes oder auch im Nachhinein u ¨ber das Standard User Interface oder geeignete Tools (z.B. Java Virtual Folders) angegeben oder ver¨andert werden. Sehr interessant ist auch die M¨oglichkeit, benutzerdefinierte Attribute an Objekte ”anzuh¨angen”. Diese k¨onnen, sofern sie nicht den selben Name wie Standard Attribute haben, frei w¨ahlbare Bezeichner bekommen.
7.4
Editieren von Attributen
Vorausgesetzt der User besitzt die entsprechenden Rechte, ist das Bearbeiten von Hyperwave – Attributen u ¨ber das Standard UI (siehe Abbildung 2) oder auch u ¨ber das von Hyperwave entwickelte Tool ”Java Virtual Folders”, welches sowohl f¨ ur Windows als auch unter Linux verf¨ ugbar ist (siehe Abbildung 3), m¨oglich. 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 k¨onnen Hyperwave Attribute auch mit Serversite Javascript oder u ber die Verwendung von HW–Dokumentklassen anlegen, ver¨andern und l¨oschen. ¨
7.5
Zusammenfassung
Hyperwaveattribute sind sicher zur Speicherung von Attributen geeignet. Ein Vorteil ist, dass mehrere Attribute den selben Bezeichner haben d¨ urfen ohne dass das System den Geist aufgibt. Die Tatsache, dass die Attribute auch indiziert werden spricht zus¨atzlich f¨ ur deren Verwendung. Leider gibt es keine M¨oglichkeit 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 n¨aher auf den Napster der Wissenschaft [Sietmann 2001] eingegangen werden.
8.1
Motivation und Hintergrund
OAI wurde entwickelt, um Autoren eine m¨oglichst reibungslose Zusammenarbeit in der Ver¨offentlichung und Verbreitung von Information zu erm¨oglichen. OAI durchforstet Informationsdepots unter Verwendung von gemeinsamen Metadaten – Standards. Wenn ein solcher Informationsspeicher diesem gemeinsamen Standard entspricht, kann er Teil einer gr¨osseren Community werden und somit den Wert seines eigenen Depots und den der Gemeinschaft anheben. Derzeit beteiligen sich zum Beispiel die Digital Library Federation, CrossRef und OCLC13 rege an diesem Projekt. Um dies zu erm¨oglichen 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 verschiedenen Servern einsammeln und zur Verf¨ ugung stellen. Wie Data– und Service Provider zusammenh¨angen k¨onnen sieht man unter Abbildung 4. Nat¨ urlich ist es m¨oglich, dass eine einzelne Organisation f¨ ur beide Bereiche zur Verf¨ ugung steht. Dies ist in gewisser Hinsicht sogar sehr interessant, weil man dann einerseits Anerkennung f¨ ur zur Verf¨ ugung gestellte Information und andererseits zugleich Lob f¨ ur 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 Verf¨ ugung gestellten Informationsdepots, erleichtert. Deshalb muss dieses Framework aus einer Metadatendefinition und einem gemeinsamen Protokoll, welches die Teilnehmer verwenden, bestehen. F¨ ur den Datenaustausch wird XML verwendet, in Hinsicht der Metadaten greift OAI auf ein kompatibles und erweiterbares System, n¨amlich das Dublin Core Element Set zur¨ uck. 8.2.1
Warum Dublin Core?
Die wesentlichsten und zugleich f¨ ur das OAI Framework interessantesten Gr¨ unde 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 M¨ogliche Verbindung von Service und Dataprovidern • Einfachheit: Dublin Core ist von der Komplexit¨at her ungef¨ahr vergleichbar mit einern herk¨ommlichen Karteikarte wie sie in einer B¨ ucherei Verwendung findet. Mit seinen 15 Descriptoren, wie z.B.: Autor, Titel, Untertitel, Erscheinungsdatum, ISBN, usw., ist ein DC Elementset noch u ¨berschaubar. • Lexikalische Kompatibilit¨ at: Dublin Core verwendet einen Satz von generell verst¨andlichen Descriptoren, welcher wiederum ein mapping auf andere, kompliziertere Datenstandards erleichtert. • Internationales Einverst¨ andnis in u ¨ber 20 L¨andern auf der ganzen Welt. • Erweiterbarkeit: Dublin Core ist eine o¨konomische Alternative zu viel komplexeren Metadatenmodellen. Trotzdem bietet es aber die Flexibilit¨at und Erweiterbarkeit, sich auch an komplexere Metadatenstandards anpassen zu k¨onnen.
8.3
Protocol for Metadata Harvesting (PMH)
Das OAI–PMH14 (Protocol for Metadata Harvesting) ist eine Erg¨anzung 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 werden, 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 uneingeschr¨ankten Argumentl¨ange bietet. Es gibt eine Basis–URL f¨ ur alle Requests. Sie spezifiziert den Host, das verwendete Port und optional einen Pfad auf dem Server. Zus¨atzlich 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 k¨onnen in einer beliebigen Reihenfolge u ussen durch ein ”&” getrennt sein. key ist immer ¨bergeben werden. Mehrere Argumente, m¨ die Zeichenkette ”verb”, der Wert ist einer der definierten OAI–Requests (z.B. GetRecord, Identify, ListIdentifiers...). Ein g¨ ultiger Request k¨onnte 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 Entwicklungsarbeit in das Projekt gesteckt und man ist sehr bem¨ uht Erweiterungen und Verbesserungen 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 komplexeren MARC–Standard. Da es eine Menge an verschiedenen Metadatenstandards gibt, war es nicht m¨oglich auf alle einzugehen. Aus diesem Grund fehlt auch eine Abhandlung u ¨ber einige Formate wie 15 16 zum Beispiel BibTeX oder MPEG 7 . XML ist wegen seiner Flexibilit¨at und Erweiterbarkeit gut f¨ ur die Speicherung von Metadaten geeignet. Dennoch ist es wichtig, dass die verwendeten Tags einer Vereinbarung folgen, um einen Datenaustausch mit anderen Benutzern zu erm¨oglichen. 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 16
http://www.ecst.csuchico.edu/~jacobsd/bib/formats/bibtex.html 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 gegenw¨artiger Suchdienste und Konzepte f¨ ur k¨ unftige 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 Qualit¨ats–Metadaten zur verbesserten Wissensauffindung und Testimplementierung im xFIND System. Master’s thesis, IICM, Graz University of Technology, 2000.
[McLaughlin 2000]
McLaughlin, B.: JAVA and XML. O’Reilly & Associates, Inc., 101 Morris Street, Sebastopol, CA 95472, 2000.
[Sietmann 2001]
Sietmann, R.: Napster f¨ ur 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 (Revised), 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