Einsatz von RDF/XML in MONARCH Alexander Schreiber 2. Mai 2000 Zusammenfassung Im Rahmen der vorliegenden Studienarbeit sollen der Stand und die Praktikabilit¨ at von RDF/XML untersucht und eine auf XML/RDF basierende Technologie zum MetadatenHandling in MONARCH entwickelt werden. Weiterhin sollen auf der Grundlage von RDF/XML neue Features f¨ ur MONARCH, speziell aggregierte Dokumente, entwickelt werden.

Inhaltsverzeichnis ¨ 1 XML - Einf¨ uhrung und Uberblick 1.1 XML-Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Die Entwicklung von XML . . . . . . . . . . . . . . . 1.1.2 XML-Dokumente . . . . . . . . . . . . . . . . . . . . . 1.1.3 XML - eine Metasprache . . . . . . . . . . . . . . . . . 1.1.4 Beschreibungen f¨ ur XML-Dokumente . . . . . . . . . . 1.1.5 XML Inclusions (XInclude) . . . . . . . . . . . . . . . 1.1.6 XML Linking Language (XLink) . . . . . . . . . . . . 1.2 XML-Visualierung . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Document Style Semantics and Specification Language 1.2.2 XML Stylesheet Language (XSL) . . . . . . . . . . . . 1.2.3 Spezifische Visualisierungsl¨osungen . . . . . . . . . . . 1.3 XML-Anwendungen . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Remote Prozedure Call mit XML (XML-RPC) . . . . 1.3.2 Precision Graphics Markup Language (PGML) . . . . 1.3.3 Text Encoding Initiative (TEI) . . . . . . . . . . . . . 1.3.4 Open Catalog Protocol (OCP) . . . . . . . . . . . . . 1.3.5 Weitere Anwendungen - Portale . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (DSSSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

5 5 5 6 7 7 8 8 9 9 9 10 10 11 11 11 11 11

2 XML als Publikationswerkzeug ¨ 2.1 XML als Dokumentenformat f¨ ur Publikationen - Ubersicht . 2.2 Portables Dokumentenformat XML . . . . . . . . . . . . . . 2.3 Trennung von Inhalt und Darstellung . . . . . . . . . . . . . 2.4 Verschiedene Visualierungen aus einem Dokument . . . . . 2.5 Archivierungsfreundliches Format . . . . . . . . . . . . . . . 2.6 Flexibles Dokumentenformat . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

12 12 12 12 12 13 13

3 XML und MONARCH 3.1 XML als Publikationsformat f¨ ur MONARCH . . . . . . . . . . . . . . . . . 3.1.1 MONARCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Dokumentenformate in MONARCH . . . . . . . . . . . . . . . . . . 3.1.3 XML als neues Format in MONARCH . . . . . . . . . . . . . . . . . 3.1.4 Darstellung von XML-Dokumenten in MONARCH . . . . . . . . . . 3.1.5 Integration von XML-Dokumenten in MONARCH-Recherchesystem 3.2 Interne Einsatzm¨ oglichkeiten f¨ ur XML im MONARCH-System . . . . . . . 3.2.1 XML f¨ ur die Metadaten in MONARCH . . . . . . . . . . . . . . . . 3.2.2 XML f¨ ur Logdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 XML f¨ ur Konfigurationsdaten . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

14 14 14 14 15 16 17 17 18 19 19

4 Schlußfolgerungen zu XML 4.1 Einsatz von XML f¨ ur Publikation und Archivierung . . . . . . . . . . . . . . . . . 4.2 XML und MONARCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 20 20

5 RDF 5.1 RDF - Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Entwicklung von RDF . . . . . . . . . . . . . . . . . . 5.1.3 Entwurfsziele f¨ ur RDF . . . . . . . . . . . . . . . . . . 5.1.4 RDF am Beispiel . . . . . . . . . . . . . . . . . . . . . 5.2 Anwendungsbeispiele von RDF . . . . . . . . . . . . . . . . . 5.2.1 Unterst¨ utzung von Suchmaschinen durch eingebettetes 5.2.2 RDF in Mozilla . . . . . . . . . . . . . . . . . . . . . .

21 21 21 21 21 21 22 22 22

2

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RDF in Webseiten . . . . . . . . . . .

. . . . . . . .

5.2.3

RDF und DublinCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 RDF und MONARCH 6.1 Einsatzm¨ oglichkeiten von RDF in MONARCH . . . . . . 6.1.1 Unterst¨ utzung f¨ ur Suchmaschinen . . . . . . . . . 6.1.2 RDF als internes Speicherformat der Metadaten . 6.1.3 RDF zur Realisierung grunds¨atzlich neuer Features 6.2 Aggregierte Dokumente in MONARCH . . . . . . . . . . 6.2.1 Konzept aggregierter Dokumente . . . . . . . . . . 6.2.2 Realisierung in RDF . . . . . . . . . . . . . . . . .

23

. . . . . . .

25 25 25 25 25 25 25 26

7 Schlußfolgerungen zu RDF 7.1 RDF in Publikation und Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 RDF in MONARCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 27

8 Fazit

28

3

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Abbildungsverzeichnis 1 2 3 4 5

Beispiel f¨ ur ein wohlgeformtes XML-Dokument Beispiel f¨ ur ein g¨ ultiges XML-Dokument . . . . Die DTD f¨ ur das vorhergehende Beispiel . . . . Einfaches Beispiel f¨ ur RDF . . . . . . . . . . . Ausf¨ uhrliches Beispiel f¨ ur den Einsatz von RDF

4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mit DublinCore

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6 7 7 22 23

¨ XML - Einfu ¨ hrung und Uberblick

1

Es soll der aktuelle Stand und die Einsatzm¨oglichkeiten von RDF/XML untersucht werden. Dazu wird zuerst die Grundlage XML untersucht um darauf aufbauend anschließend auf RDF als spezielle Anwendung von XML einzugehen. Dabei wird nach der Behandlung der Grundlagen und allgemeinen M¨ oglichkeiten die Aufmerksamkeit immer wieder auf Einsatzm¨oglichkeiten im Kontext des MONARCH-Systems gerichtet werden.

1.1 1.1.1

XML-Grundlagen Die Entwicklung von XML

Die eXtensible Markup Language XML beschreibt eine Klasse von Objekten - XML-Dokumente - sowie teilweise das Verhalten der diese Dokumente verarbeitenden Software. Die Grundlage f¨ ur XML ist die Standard Generalized Markup Language SGML. Da sich SGML nicht nur als sehr leistungsf¨ ahig sondern leider auch als zum Teil extrem komplex herausstellte wurde nach einem Mittel gesucht um den breiten Einsatz von SGML zu f¨ordern. Es sollte die wichtigsten Vorteile von SGML: • Plattformunabh¨ angigkeit, • hohe Flexibilit¨ at, • strukturierte Erzeugung und Verarbeitung von Dokumenten, bewahren und gleichzeitig weniger komplex als SGML sein, um die Verbreitung zu beg¨ unstigen. Dieses Mittel ist XML, eine vereinfachte Form von SGML. XML wurde 1996 von der XML Working Group unter F¨ uhrung des W3-Consortiums entwickelt. Die Entwurfsziele f¨ ur die Entwicklung von XML aus SGML waren: • einfache Nutzbarkeit u ¨ber das Internet, • Unterst¨ utzung einer großen Bandbreite von Anwendungen, • kompatibel mit SGML, • das Schreiben von Programmen zum Verarbeiten von XML sollte m¨oglichst einfach sein, • m¨ oglichst keine optionalen Features, • XML-Dokumente sollten menschenlesbar und m¨oglichst klar sein, • XML-Design formal und pr¨ azise, • XML-Dokumente sollen einfach zu erzeugen sein, • Knappheit des Markups spielt f¨ ur XML eine minimale Rolle. Die schließlich entstandene XML-Spezifikation [1] bildet zusammen mit anderen, zugeh¨origen Standarddokumenten (Unicode [7] und ISO/IEC 10646 [6] f¨ ur die Zeichenspezifikation, Internet RFC 1766 [3] f¨ ur die Sprachidentifikations-Tags, ISO 639 [4] f¨ ur die Codes zur Auszeichnung der Sprachnamen, und ISO 3166 [5] f¨ ur die L¨andercodes) den gesamten Informationsbestand der zum Verst¨ andnis von XML Version 1 und zur Entwicklung von damit arbeitenden Programmen notwendig ist. Da jedes XML-Dokument auch zugleich ein SGML-Dokument darstellt (Entwurfsziel) k¨onnen zum Bearbeiten von XML-Dokumenten die bereits existierenden SGML-Werkzeuge verwendet werden. Dies ist besonders dort von Vorteil wo bereits eine ausgebildete SGML-Infrastruktur existiert.

5

1.1.2

XML-Dokumente

Ein Datenobjekt gilt als XML-Dokument wenn es wohlgeformt ist. Dies bedeutet daß das Objekt der XML-Syntax entspricht (korrekte Verschachtelung der Tags, korrekter Aufbau der Tags, genau ein root-Element, . . . siehe [1]). F¨ ur ein wohlgeformtes XML-Dokument kann man die verwendeten Tags prinzipiell frei vergeben, da nur die Struktur des Dokuments gem¨aß XML u uft wird. Ein einfaches, wohlgeformtes ¨berpr¨ XML-Dokument beginnt mit der XML-Verarbeitungsanweisung die darauf hinweist daß es sich um ein XML-Dokument handelt sowie die XML-Version angibt. Darauf folgt genau ein root-Element welches seinerseits wieder eine beliebige Anzahl anderer Elemente enthalten kann.

This is an example Item one Item two Abbildung 1: Beispiel f¨ ur ein wohlgeformtes XML-Dokument

In diesem Beispiel sieht man den typischen Aufbau eines wohlgeformten XML-Dokumentes: • es beginnt mit einer Verarbeitungsanweisung diese enth¨ alt – den Dokumententyp: XML – die Versionsnummer der XML-Definition: 1.0 – die Definition daß es sich um ein standalone-Dokument (also ohne DTD) handelt • es folgt das nur einmal auftretende root-Element, hier • innerhalb des root-Elements folgen, teilweise verschachtelt, verschiedene andere Tags und Inhalte die prinzipiell frei vergeben werden k¨onnen F¨ ur wohlgeformte XML-Dokumente gelten verschiedene Grundregeln: • ge¨ offente Tags m¨ ussen auch wieder geschlossen werden • beim Verschachteln von Tags m¨ ussen ge¨offnete Tags auch wieder in der korrekten Reihenfolge geschlossen werden, Konstrukte wie: foo die z.B. bei HTML meist trotzdem korrekt interpretiert werden, sind bei XML Fehler die nicht akzeptiert werden • XML unterscheidet zwischen Groß- und Kleinschreibung, somit sind foo und Foo unterschiedliche Objekte 6

Neben den wohlgeformten XML-Dokumenten gibt es auch die striktere Form der g¨ ultigen XMLDokumente. Bei diesen XML-Dokumenten wird in einer Dokumenttyp-Anweisung die Document Type Description DTD angegeben der das Dokument gen¨ ugt. In der DTD wird die Struktur eines XML-Dokumentes beschrieben. Dies umfaßt unter anderem die Definition des root-Elements, der darin verwendbaren erlaubten Tags, der Verschachtelungsstruktur und verschiedene andere Details der Dokumentenstruktur. Hello, world!

Abbildung 2: Beispiel f¨ ur ein g¨ ultiges XML-Dokument

Abbildung 3: Die DTD f¨ ur das vorhergehende Beispiel Die Definition der Document Type Description findet sich ebenfalls in [1]. 1.1.3

XML - eine Metasprache

Ebenso wie SGML ist XML eine Metasprache, also eine Sprache zur Beschreibung von Sprachen. XML an sich definiert lediglich wie XML-konforme Dokumente auszusehen haben, es definiert aber noch kein verwendbares Dokumentenformat. Dies muß der Nutzer von XML selbst tun. Unabh¨angig davon kann aber jedes XML-Dokument - egal wie es definiert wurde - mit den gleichen XML-Werkzeugen verarbeitet werden. Ein Beispiel daf¨ ur: Es gibt auf CPAN [8] ein Perl-Modul namens XML::Parser welches beliebige XML-Dokumente parsen kann. Zur Verarbeitung der jeweiligen Tags kann man dann tagspezifizische Handler einklinken die bei Auftreten ihres“ Tags entsprechende Aktionen ausf¨ uhren. ” Entsprechende Werkzeuge gibt es nat¨ urlich auch f¨ ur Java , C++ und andere Programmiersprachen. 1.1.4

Beschreibungen f¨ ur XML-Dokumente

Da XML nur die Mittel zur Sprachdefinition festlegt, ist es m¨oglich f¨ ur jede beliebige Anwendung eine optimal darauf zugeschnittene Sprachdefinition zu erstellen. Dabei kann man im einfachsten Falle mit lediglich wohlgeformten Dokumenten (also ohne formale Definition) arbeiten. Damit fehlt allerdings die M¨ oglichkeit die resultierenden Dokumente auf strukturelle Korrektheit (alle notwendigen Tags vorhanden, keine nicht-definierten Tags verwendet, . . . ) zu pr¨ ufen ohne speziell auf die jeweiligen Dokumente angepaßte spezielle Tools zu verwenden. Mit einer formalen Definition der Dokumentenstruktur erh¨ alt man diese M¨oglichkeit und kann u.a. die Dokumente vom Parser auf Konformit¨ at mit einer entsprechenden Dokumentenbeschreibung verifizieren. Urspr¨ unglich war f¨ ur die Beschreibung der Dokumentenstruktur die Dokument Type Description (DTD) vorgesehen. Da diese jedoch eine eigene, von XML abweichenden Syntax verwendet und somit nicht mit den gleichen Tools verarbeitet werden kann, die auch die XML-Dokumente verarbeiten kam, die Forderung auf, die Definition der Dokumentenstruktur ebenfalls mit XML-Mitteln realisieren zu k¨onnen. Zudem bietet die DTD kaum M¨oglichkeiten die im XML-Dokument gespeicherten und zul¨assigen Daten detaillierter zu beschreiben (z.B. Angabe von Wertebereichen).

7

Aufgrund dieser Anforderungen wurde die XML Schema Working Group [10] ins Leben gerufen die sich mit der Entwicklung der XML Schemas [11] besch¨aftigt. Diese bieten im Gegensatz zu den nur strukturbeschreibenden DTD sehr umfangreiche Beschreibungs- und Definitionsm¨oglichkeiten f¨ ur XML-Dokumente. Es ist unter anderem m¨oglich, sehr pr¨azise Typ- und WertebereichEinschr¨ankungen vorzugeben. Ein kurzer Auszug aus den M¨oglichkeiten der XML Schemas: • Datentypdefinition f¨ ur Werte - es sind u ¨ber 40 Datentypen vorgesehen, • Ableitung von Untertypen von den vorgegebenen Typen durch Einschr¨ankung des Wertebereichs, • Vorgabe von Datenmustern mit regul¨aren Ausdr¨ ucken (z.B. Regeln f¨ ur Modellnummern), • Aufz¨ ahlungen, • zusammengesetzte Typen, • Anmerkungen in Definition, sowohl f¨ ur Mensch (Dokumentation) als auch Maschine (Hinweise f¨ ur verarbeitende Programme), • Namensr¨ aume, ¨ • Aquivalenzklassen f¨ ur Elemente, sowie verschiedene andere M¨ oglichkeiten um sowohl Dokumentenstruktur als auch die enthaltenen Informationen sehr pr¨ azise zu beschreiben. Das Hauptgewicht liegt bei den XML Schemas offensichtlich auf der Datenbeschreibung, dies kommt Anwendungen die XML-Dokumente als Datenbanken benutzen sehr entgegen. Weiterhin erm¨oglichen XML Schemas auch sehr weitgehende strukturelle Beschreibungen von Dokumenten. Als Beispiel daf¨ ur findet sich am Ende von [12] die eine XML Schema Definition f¨ ur XML Schema: Struktures , zum Vergleich gefolgt von einer DTD daf¨ ur. Aufgrund der sehr umfangreichen Beschreibungsf¨ahigkeiten bietet sich XML Schema u ¨berall dort als der bessere Ersatz f¨ ur eine DTD an, wo es um eine detaillierte und exakte Dokumentenbeschreibung, besonders im Hinblick auf die im XML-Dokument gespeicherten Daten, geht. Allerdings ist festzustellen das bis jetzt von den XML Schemas noch keine feste Version sondern nur Working Drafts vorliegen. Die derzeit aktuelle Version der XML Schema Working Drafts [11] stammt vom 7. April 2000, es ist also noch mit Bewegung in diesem Bereich zu rechnen. Laut [13] endet der Aufruf f¨ ur weitere Vorschl¨ age am 12. Mai 2000, danach ist die Freigabe des bis dahin aktuellen Entwicklungsstandes als XML Schema 1.0 zu erwarten. 1.1.5

XML Inclusions (XInclude)

Die XML Inclusions beschreiben eine M¨oglichkeit XML-Dokumente zu einem zusammengesetzten Dokumente zu verschmelzen. Die Grundidee ¨ahnelt dem #include Befehl des C-Pr¨aprozessors. Im Gegensatz zu XLink , der XML Linking Language die eine medientypunabh¨angige Syntax spezifiert, wird von XInclude eine medientypspezifische XML-zu-XML Transformation spezifiziert. Es wird ein spezifisches Verarbeitungsmodell zum Verschmelzen von Informationseinheiten definiert welches auf niedriger Ebene agiert. Prinzipiell agiert der XInclude Verarbeitungsprozess ¨ahnlich wie ein C-Preprozessor der nur die #include Anweisung kennt. Damit bietet sich XInclude als Werkzeug zur einfachen Strukturierung gr¨oßerer XML-Dokumente durch komponentenbasierte Wiederverwendung an. Die Spezifikation findet sich auf [14] 1.1.6

XML Linking Language (XLink)

Die XML Linking Language (XLink) erm¨oglicht das Einf¨ ugen von Elementen in XML-Dokumente zur Realisierung von Links. Damit sind nicht nur die bereits von HTML bekannten Hyperlinks m¨oglich sondern auch erweiterte Linkm¨oglichkeiten. Ein Link ist dabei definiert als URI (Uniform Resource Locator). Ein Link kann bei XLink verschiedene Attribute erhalten, u.a. k¨onnen lokale Ressourcen eingebunden werden. Die Spezifikation findet sich unter [15]. 8

1.2

XML-Visualierung

Bisher wurden die Grundlagen von XML eingef¨ uhrt. Allerdings konzentriert sich XML auf den Inhalt der Dokumente und beschreibt - im Gegensatz zu HTML - nicht die Darstellung derselben. F¨ ur den Einsatz von XML als Dokumentenformat f¨ ur Publikationszwecke besteht nat¨ urlich auch Bedarf an M¨ oglichkeiten die in XML niedergelegten Inhalte auch in eine geeignete Darstellung zu u uhren. Dazu wurden Technologien im Bereich der Stylesheets entwickelt. Aus der ¨berf¨ Kombination der inhaltlichen Beschreibung in XML-Form und der Layout-Beschreibung der Informationselemente in Form von Stylesheets entsteht schließlich eine geeignete Visualisierung der Inhalte der XML-Dokumente. Im Wesentlichen gibt es zwei M¨oglichkeiten um Stylesheets mit XML zu kombinieren: • XML Stylesheet Language (XSL) • Document Style Semantics and Specification Language (DSSSL) In den folgenden beiden Abschnitten soll auf diese beiden Systeme n¨aher eingegangen werden. 1.2.1

Document Style Semantics and Specification Language (DSSSL)

Die Document Style Semantics and Specification Language (DSSSL) wurde 1996 als Norm ISO/IEC 10179 definiert. DSSSL definiert zwei Sprachen mit gemeinsamen Konzepten: • eine Style-Language und • eine Transformation-Language Urspr¨ ungliche wurde die Transformation-Language f¨ ur Formatierungsaufgaben ben¨otigt. Dies kann die Style-Language mittlerweile selbst erledigen, die Transformation-Language wurde jedoch beibehalten da sie sich als n¨ utzlich erwies. Als Ausgabeziele f¨ ur die DSSSL-Transformationen sind sowohl Online- als auch Druckformate vorgesehen, dabei wird die Ausgabe vom Stylesheet bestimmt. Das verwendete Sprachkonzept ist der Aufgabenstellung deklarativ und sollte mit geeigneten Werkzeugen trotz der großen Leistungsf¨ahigkeit auch f¨ ur Nicht-Progammierer beherrschbar sein (auch wenn sich die Syntax an Scheme/LISP anlehnt). Als Format u ¨ber dem DSSSL arbeitet ist SGML vorgesehen. Da jedes wohlgeformte XML-Dokument auch ein SGML-Dokument darstellt ist somit auch die Verarbeitung von XML m¨oglich. Der komplette Prozess von den urspr¨ unglichen SGML-Quellen bis hin zum fertig formatierten und darstellbaren Format verl¨ auft u ¨ber mehrere Schritte und ist relativ aufwendig, es werden mehrfach Baumstrukturen aufgebaut und umgewandelt, Flow Objekte erzeugt und schließlich formatiert um das Zielformat (Online - oder Druckformat) zu erhalten, deshalb soll aus Gr¨ unden der K¨ urze nicht n¨ aher darauf eingegangen werden. Die vollst¨andige Standardspezifikation [17] umfaßt 293 Seiten. Eine Implementation von DSSSL ist James Clarks DSSSL Engine - Jade [18]. 1.2.2

XML Stylesheet Language (XSL)

XSL ist eine Sprache zum Formulieren von Stylesheets. Sie besteht aus zwei Teilen: • einer Sprache zur Transformation von XML-Dokumenten und • einem Vokabular zur Specifikation von Formatierungssemantiken Die Transformationssprache von XML kann unabh¨angig von der Formatierungssprache verwendet werden. Als Beispiel daf¨ ur kann mit der Transformationssprache XSL Transformations[28] XML-Dokument in ein wohlgeformtes HTML-Dokument umgeformt werden, wobei die XSL formatting objects vollkommen ignoriert werden - das ist zum Beispiel der vom Microsoft Internet Explorer unterst¨ utzte XSL-Style. Die Formatierungssprache von XSL ist sehr leistungsf¨ahig. Ihre F¨ahigkeit, Daten von einer XML-Repr¨asentation in eine andere zu u uhren macht sie zu einem ¨berf¨ 9

sehr m¨achtigen Werkzeug f¨ ur den Austausch von Metadaten, elektronischen Datenaustausch und viele andere Anwendungen, bei denen Daten zwischen verschiedenen XML-Darstellungen umgewandelt werden m¨ ussen. XSL basiert sowohl auf DSSSL als auch auf CSS. Entsprechend dem bei der Ableitung von XML aus SGML herrschenden Gedanken der Vereinfachung ist auch XSL weniger komplex als DSSSL. So besteht der Verarbeitungslauf bei XSL nur aus zwei grunds¨atzlichen Phasen: • Erstellung des fo (formatting objects) Baumes • Transformation des fo-Baumes in das Ausgabeformat Da XSL als XML-Anwendung implementiert ist verwendet es im Gegensatz zu DSSSL keine eigene Syntax sondern XSL-Stylesheets sind in der vertrauten XML-Syntax realisiert. Obwohl XSL als Standard durchaus noch sehr in Bewegung ist, gibt es bereits zahlreiche Anwendungen und XSLf¨ahige Werkzeuge: • XALAN [19] ist ein XSL-Prozessor aus dem Apache-Projekt [20] der XML in HTML, einfachen Text oder andere XML-Formate umwandelt, • LotusXSL[21]: eine XSL Transformation Engine von IBM, implementiert in Java; der Code findet sich im Xalan des Apache-Projekts wieder, • XMLWriter[22], ein XML-Editor der mittels XSL aus XML HTML erzeugen kann, • XSL wird auch im Microsoft Internet Explorer 5[23] verwendet um XML in HTML zu konvertieren und dann mittels CSS anzuzeigen, dabei wird der Schritt der Erzeugung der formatting objects (fo) weggelassen • eXcelon Stylus[26] ist ein visueller Editor f¨ ur XML“ der verschiedene Tools kombiniert um XSL-Stylesheets in einer visuellen Umgebung zu erzeugen und mit dem visuell StyleSheets bearbeitet werden k¨ onnen • Henry Thompsons xsjl-Filter [24] u ¨bersetzt von XSL in extended DSSSL welches von Jade[18] verarbeitet werden kann • IBM XSL Editor[25] - eine Anwendung die das Importieren, Bearbeiten, Exportieren von XSL Stylesheets und XML Quelldokumenten erlaubt Der aktuelle Stand von XSL ist in einem W3C Working Draft [27] vom 27. M¨arz 2000 f¨ ur die Version 1.0 festgelegt. 1.2.3

Spezifische Visualisierungsl¨ osungen

Das Problem mit den beiden vorgenannten Visualierungsm¨oglichkeiten f¨ ur XML besteht darin, daß entweder ein nicht geringer Aufwand f¨ ur das Aufsetzen des Systems (DSSSL) notwendig, ist oder aber das verwendete Visualisierungsmittel noch in Entwicklung begriffen ist (XML). F¨ ur manche Anwendungsf¨ alle kann es daher durchaus sehr sinnvoll sein spezielle XML-Verarbeitungssoftware zum Erstellen des endg¨ ultigen Publikationsformates aus den XML-Quellen zu verwenden. Falls man sich zu einer solchen selbst entwickelten L¨osung entschließt so gibt es ein umfangreiches Angebot an Software die man entweder an die eigenen Anspr¨ uche anpassen oder als Komponenten f¨ ur ein eigenes System verwenden kann. Exemplarisch sei hier das Perl-Modul XML::Parser [29] welches auf CPAN[8] zu finden ist genannt. Wie bereits erw¨ahnt existieren XML-Tools f¨ ur verschiedene Programmiersprachen, darunter Perl, Tcl, C++, Java und andere.

1.3

XML-Anwendungen

¨ Im folgenden sollen kurz verschiedene XML-Anwendungen dargestellt werden. Dieser Uberblick soll dazu dienen ein wenig von den zahlreichen Einsatzm¨oglichkeiten von XML zu pr¨asentieren. 10

1.3.1

Remote Prozedure Call mit XML (XML-RPC)

XML-RPC ist eine Technologie zur Implementation von Remote Procedure Calls u ¨ber XML. Dabei dient XML als Formulierungswerkzeug f¨ ur Prozedureaufrufe und deren Resultate. Als Transportprotokoll dient HTTP. Der Vorteil dieses Ansatzes ist eine leichte Lesbarkeit der RPC-Protokolle was nicht nur die Portierung auf andere Systeme sondern die Implementation generell - verglichen mit einem bin¨ aren Protokoll - vereinfacht. Als Nachteil mag gelten, daß der protokollspezifische Overhead - besonders bei Verwendung langer, beschreibender XML-Tags relativ hoch ist und gerade beim Transfer kleiner Datenmengen die Nutzdatenmenge u ¨bersteigt. Die entsprechende Spezifikation [30] - zusammen mit verschiedenen weiteren Informationen und Beitr¨ agen - findet sich auf der Webseite des XML-RPC Projektes [31]. 1.3.2

Precision Graphics Markup Language (PGML)

Die Precision Graphics Markup Language (PGML)[32] ist ein Format zur Speicherung skalierbarer zweidimensionaler Vektorgrafiken. Das verwendete Imaging Model lehnt sich an PostScript und PDF an, zudem sind weitere, speziell auf die Darstellung im WWW angepaßte Features implementiert. Verwendet wird das PGML-Format derzeit zum Beispiel vom KIllustrator[33], dem Vektorgrafikprogramm aus der KOffice-Suite[34]. Einer der auff¨alligen Vorteile ist die M¨oglichkeit mit relativ einfachen Werkzeugen die entstehenden Vektorformat-Dateien zu manipulieren - es reicht im Grunde ein simpler Texteditor. 1.3.3

Text Encoding Initiative (TEI)

Die Text Encoding Initiative (TEI)[35] hat ein relativ umfassendes XML-Dokumentenformat zur digitalen Erfassung von Dokumenten entwickelt. Das prim¨are Ziel dieses Projektes ist die Digitalisierung gedruckter Texte und der Austausch von Texten in portablen Formaten. Das Hauptziel der TEI liegt derzeit auf der Erfassung von insbesondere in nicht-digitalen Formaten vorliegenden Texten (B¨ ucher, Zeitschriften, . . . ) und der Archivierung dieser Texte in einem dauerhaft verwendbaren Format. 1.3.4

Open Catalog Protocol (OCP)

Das Open Catalog Protocol[38] wurde von Martsoft[37] entwickelt um komplexe Daten zwischen Produktkatalogen auszutauschen. Als Datenformat f¨ ur den Austausch wird das Open Catalog Format (OCF)[39] verwendet - eine XML Anwendung. Das Protokoll ist von Martsoft zur freien Benutzung freigegeben, an einer Einreichung an das W3 Consortium wird gearbeitet. Verwendet wird das Protokoll in Martsofts IntuiCat, einer XML-basierten E-Commerce-L¨osung. 1.3.5

Weitere Anwendungen - Portale

Es gibt eine nahezu unbegrenzte Anzahl an weiteren XML-Anwendungen die derzeit geplant, entwickelt, erprobt oder sogar schon eingesetzt werden. Eine der zentralen Informationsquellen dazu ist das sich als Industrieportal f¨ ur XML-Anwendungen verstehende XML.org Portal[36] . Eine weitere, sehr umfangreiche Sammlung von Links und Informationen zu XML-Anwendungen aller Art ist die XML-Seite von Oasis Open[40]. Dort finden sich Links zu XML-Anwendungen - viele davon noch in Entwicklung, manche schon im Einsatz - u ¨ber alle denkbaren Bereiche hinwege, von Werbung und Buchhaltung u ¨ber Directory Services und finanzielle Anwendungen bis hin zu User Interface und WWW-spezifischen Anwendungen.

11

2

XML als Publikationswerkzeug

2.1

¨ XML als Dokumentenformat fu ¨ r Publikationen - Ubersicht

F¨ ur den Einsatz von XML als Dokumentenformat f¨ ur Publikationen verschiedenster Art sprechen verschiedene Gr¨ unde: • portables Dokumentenformat, • Trennung von Inhalt und Darstellung, • ein Dokument - verschiedene Visualisierungen, • archivierungsfreundliches Format, • optimal an die jeweilige Aufgabe anpassbares, flexibles Dokumentenformat um die offensichtlichsten zu nennen. Im folgenden soll auf diese detaillierter eingegangen werden.

2.2

Portables Dokumentenformat XML

Im Gegensatz zu anderen Dokumentenformaten wie zum Beispiel dem Microsoft Word Format ist XML ein auf einfachem ASCII-Text aufsetzendes portables Format. Zur Bearbeitung von XML sind keine speziellen Werkzeuge erforderlich (obwohl es entsprechend angepaßte Editoren gibt), grunds¨atzlich reicht ein einfacher Texteditor - damit kann man XML-Dokumente auf allen Plattformen (u.a. UNIX, Windows, Macintosh,. . . ) bearbeiten.

2.3

Trennung von Inhalt und Darstellung

Bei der Verwendung von XML ist es m¨oglich sich bei der Erstellung des Dokumentes nur auf den Inhalt zu konzentrieren - und das Layout vorerst zu ignorieren. Die Layout-Beschreibung kann getrennt vom Inhalt realisiert werden - daf¨ ur bietet sich XSL an. Erst aus der Zusammenf¨ uhrung von Inhalt (XML-Dokument und Stilbeschreibung) in Form eines XSL-Stylesheets entsteht die endg¨ ultige Darstellung.

2.4

Verschiedene Visualierungen aus einem Dokument

XML erm¨ oglicht es ein Dokument einmal zu schreiben und dann ausgehend von dieser Quelle das Dokument in verschiedenen Fomaten (HTML, WML, PDF, PostScript, einfacher Text, gedruckt, . . . ) zu ver¨ offentlichen. Als Mittel zu diesem Zweck bietet sich die Kombination aus XML-Dokument und XSL-Stylesheet an. Damit sind nicht nur Visualisierungen in verschiedenen Formaten m¨ oglich, sondern man kann auch ein einem Schritt die Darstellung einer Publikation ¨ ver¨andern ohne die Publikation selbst ¨ andern zu m¨ ussen - einfach durch Austausch oder Anderung des Stylesheets. Das erm¨ oglich zum Beispiel bei der Online-Darstellung von Dokumenten eine sehr hohe Flexibilit¨ at der Darstellung. Unter anderem kann man damit ein und dasselbe Dokument sehr einfach in verschiedener Form darstellen - je nach Umgebung und Zielgruppe. Entsprechende Webserver-Technologie die serverseitig XML-Dokumente und Stylesheets verarbeiten und daraus dann dynamisch die HTML-Darstellung erzeugen kann ist verf¨ ugbar, zum Beispiel aus dem Apache XML Project[41]. Damit wird ein XML-basiertes Publishing m¨oglich, das im Gegensatz zum klassischen HTML eine viel gr¨ oßere Flexibilit¨at bietet. Eingesetzt wird derartige Technologie zum Beispiel bei der Encyclopaedia Britannica[42] - siehe auch das Transcript eines Vortrages zum Thema Encyclopaedia Britannica und XML[43].

12

2.5

Archivierungsfreundliches Format

Bei verschiedenen aktuellen Dokumentenformaten besteht das Problem, daß das verwendete Format nur von bestimmten Versionen bestimmter Software verarbeitet werden kann. Bei der Archivierung solcher Dokumente m¨ ußte strenggenommen auch die entsprechende Software archiviert werden. Da dies aber aus verschiedenen Gr¨ unden im Allgemeinen weder w¨ unschenswert noch sinnvoll ist wird ein Dokumentenformat ben¨otigt, das auch noch nach langer Zeit verarbeitbar bleibt. Auch hier bietet sich XML an. Falls irgendwann die Software zur Verarbeitung des Formats nirgends mehr l¨ auft so ist es relativ einfach anhand der offenen Spezifikationen f¨ ur XML geeignete Software zu schreiben. Zudem hat XML als Archivierungsformat auch den Vorteil das man mit der gleichen Technologie die dynamische Publizieren auf XML-Basis erm¨oglicht (XML + Stylesheets) auch eine sehr hohe Flexibili¨ at der Darstellung in der Archivierung erh¨alt. Man kann damit aus den einmal archivierten XML-Quellen immer aktuelle Darstellungsformen (HTML 4.0, XHTML, . . . ) generieren - ohne die archivierten Daten ver¨andern zu m¨ ussen, angepaßt werden muß lediglich das entsprechende Frontend zur Erzeugung der endg¨ ultigen Darstellungsform. Damit erm¨ oglicht es XML wahrhaft dauerhaft archivierbare Dokumente zu erstellen.

2.6

Flexibles Dokumentenformat

Aufgrund des Charakters von XML kann man die Dokumente optimal an die jeweilige Aufgabenstellung - Vortrag, Studienarbeit, Forschungsbericht, . . . - anpassen ohne dabei Funktionalit¨at zu verlieren. Es kommt lediglich darauf an die Struktur des Dokumentes der Bestimmung entsprechend zu definieren. Dies kann entweder mit DTD’s oder aber mit den wesentlich m¨achtigeren XML Schemas geschehen. Zusammen mit den M¨ oglichen von Werkzeugen wie der XML Linking Language[15] und XML Inclusions[14] k¨ onnen zum Beispiel auf einfache Weise Verbunddokumente erstellt werden. Deren Darstellung als: • fortlaufender Text als monolithische HTML-Datei • verlinktes HTML-Dokument aus mehreren HTML-Dateien • fortlaufender Text f¨ ur die gedruckte Form kann dann mit den entsprechenden Werkzeugen bei Bedarf erzeugt werden. Ebenfalls m¨ oglich ist die Unterbringung von mehreren Informationsebenen in einem XMLDokument. So w¨ are es zum Beispiel m¨oglich Vortragsunterlagen in XML zu schreiben die alle Informationen - sowohl die Kurzdarstellung f¨ ur die Folien, die zus¨atzlichen Erl¨auterungen f¨ ur die Handouts als auch den kompletten Volltext f¨ ur das Paper zum Vortrag - in einem Dokument enthalten. Als abschließende Aktion nach Fertigstellung des Dokumentes k¨onnen dann mit einem Durchlauf alle drei Darstellungen, zum Beispiel: • die Folien, entweder als PostScript zum Ausdruck oder PDF f¨ ur eine computergest¨ utzte Pr¨asentation • die Handouts als PostScript f¨ ur den Laserdrucker, • das Paper in verschiedenen geeigneten Formaten (PostScript, PDF, HTML, . . . ) erzeugt werden. Damit entf¨ allt der Aufwand drei verschiedene Varianten desselben Materials erstellen und vor allem inhaltlich synchron halten zu m¨ ussen.

13

3

XML und MONARCH

3.1 3.1.1

XML als Publikationsformat fu ¨ r MONARCH MONARCH

Das MONARCH-System[44] ist das digitale Archiv der TU Chemnitz[45]. Es ist ein web-basiertes Archivierungssystem welches vom Universit¨atsrechenzentrum[46] der TU Chemnitz in Zusammenarbeit mit der Bibliothek[47] betrieben und weiterentwickelt wird. Es erm¨oglicht die Archivierung von Publikation unter festen und damit dauerhaft zitierf¨ahigen URLs. Dazu werden sowohl der Volltext der Publikation als auch ein dazugeh¨origer Satz an Metadaten (Titel, Autor, Schlagworte, Abstract, . . . ) archiviert und aus den Metadaten eine Index-Seite in einem einheitlichen Format generiert, die eine diesen Metadaten entsprechende Beschreibung der Publikation enth¨alt und als einheitlicher Einsprungpunkt“ den Zugriff auf den Volltext der Publikation erm¨oglicht. Ausser” dem existiert ein Recherchesystem mit dem auf verschiedene Weise (nach Publikationstypen, in den Metadaten, Volltextrecherche) in den archivierten Publikationen recherchiert werden kann. W¨ahrend der lesende Zugriff auf MONARCH weltweit ohne Einschr¨ankungen m¨oglich, ist erfordert das Archivieren von Publikation ein g¨ ultiges Nutzerkennzeichen des URZ - dies ist unter anderem aus Gr¨ unden der Authentisierung des Archivierenden notwendig. Da bei der Ver¨offentlich von Publikationen in MONARCH auch Fragen des Urheberrechtes zu beachten sind, ist eine anonyme Archivierung nat¨ urlich nicht m¨oglich. 3.1.2

Dokumentenformate in MONARCH

Bisher werden f¨ ur die Archivierung einer Publikation in MONARCH die folgenden Dokumentenformate akzeptiert: • Text (.txt) - einfacher ASCII-Text , fast u ¨berall lesbar, lediglich bei Sonderzeichen kann es in Abh¨ angigkeit vom verwendeten Zeichensatz zu Problemen kommen, • HTML[52] (.html) - Dokumente in der Hypertext Markup Language, praktisch auf allen relevanten Plattformen mittels eines geeigneten HTML-Browsers lesbar, die entsprechende Software kann zum gegenw¨ artigen Zeitpunkt als vorhanden angenommen werden, • Device Independent (.dvi) - erzeugt von TEX/LATEX, auf allen Plattformen lesbar f¨ ur die es eine TEX/LATEX-Implementation gibt, allerdings ist die zum Anzeigen ben¨otigte Software (DVI-Viewer) auf Nicht-UNIX Plattformen nur selten vorhanden und muß gegebenenfalls nachinstalliert werden, • PostScript[48] (.ps) - erzeugt von den verschiedensten Programmen, als Anzeigesoftware wird typischerweise GhostScript [49] verwendet - w¨ahrend dies auf UNIX-Plattformen im Allgemeinen als vorhanden vorausgesetzt werden kann muß es auf anderen Systemen meist nachinstalliert werden, • Portable Dokument Format (.pdf) - erzeugt von verschiedenen Programmen, oft von Acrobat Distiller[51] , als Anzeigeprogramm wird normalerweise der Adobe Acrobat[50] benutzt, der auf den meistverbreiteten Plattformen (UNIX, Windows, Mac) typischerweise als vorhanden vorausgesetzt werden kann Jedes dieser derzeit gelisteten Publikationsformate hat seine eigenen Probleme: • Text (TXT): Die M¨ oglichkeiten f¨ ur Formatierung sind extrem begrenzt, die Darstellung von nicht US-ASCII Symbolen (deutsche Umlaute und anderes) kann abh¨angig vom verwendeten Zeichensatz fehlerhaft sein, Grafiken k¨onnen gar nicht eingebettet werden - vor allem Nachteile aus der Sicht des Autors,

14

• Device Independent (DVI): vor allem problematisch aus der Sicht des Lesers wenn er eine nicht-UNIX Plattform verwendet - die entsprechende Darstellungssoftware existiert zwar gegebenenfalls (zum Beispiel f¨ ur Windows), ist aber nur selten vorhanden und muß somit vom Leser installiert (und vorher erst einmal gefunden werden), • PostScript (PS: hier gilt praktisch identisch das vorher zu Device Independent Gesagte, dazu kommt noch ein Problem aus der Sicht des Archivierungssystems: bestimmte PostScripterzeugende Software (speziell Microsoft-PostScript-Druckertreiber unter Microsoft Windows) erzeugen einen derartig schlechten PostScript-Code (jedes Zeichen (einschließlich Leerzeichen) wird separat auf der Seite positioniert, . . . ) daß eine sinnvolle Indizierung (f¨ ur die Volltextrecherche) praktisch nicht m¨oglich ist • Portable Dokument Format (PDF): dieses Format erscheint zwar aus der Sicht von Autoren (praktisch beliebige Gestaltungsm¨oglichkeiten) und Nutzern (Software zum Anzeigen fast immer schon vorhanden) ideal, aber von der Seite der Archivierung gibt es Probleme dahingehend, daß PDF-Dokumente nur in den seltensten F¨allen u ur eine ¨berhaupt brauchbar f¨ Volltextrecherche indizierbar sind ¨ Zur Uberwindung dieser Probleme w¨are nun ein Dokumentenformat sinnvoll welches: 1. dem Autor volle Flexibilit¨ at bei der Gestaltung seiner Dokumente bietet 2. plattform¨ ubergreifend verwendbar ist 3. plattform¨ ubergreifend darstellbar ist 4. einfach f¨ ur eine Volltextrecherche indizierbar ist Wenn wir uns die bisher verwendeten Formate ansehen so bietet sich als Kandidat eigentlich nur HTML an - aber ist es wirklich so geeignet ? Die Punkte 2 und 4 werden von HTML erf¨ ullt, bei den Punkten 1 und 3 hingegen sieht es weniger gut aus. HTML war urspr¨ unglich nur zur semantischen Auszeichnung von Texten gedacht und enthielt nur sehr wenige Layout-Elemente. Diese klare Strukturierung wurde jedoch bald gebrochen und es wurden dem HTML-Sprachumfang zahlreiche Layouting-Features hinzugef¨ ugt (Font- Definitionen u.a.). Dies geschah zum Teil sowohl aufgrund entsprechender Forderungen von Nutzern als auch im Rahmen der sogenannten Browser-Wars“ ” in denen sich Anbieter von WWW-Browsern gegenseitig mit den zus¨atzlichen und nicht selten fragw¨ urdigen1 besonderen Features die ihre Browser dem HTML-Sprachumfang hinzuf¨ ugten voneinander abheben wollten. Im Endergebnis ist das aktuelle HTML ein ziemlicher Wildwuchs aus semantischen und Layout-Elementen, HTML-Dokumente werden - sofern man nicht viel Arbeit in ein einheitliches Erscheinungsbild investiert - von jedem Browser anders dargestellt. Damit ist die von Autorenseite gew¨ unschte Kontrolle u ¨ber die Darstellung der Dokumente aber de facto nicht mehr existent (es sei denn man erlaubt die Betrachtung der jeweiligen Dokumente nur mit wenigen, getesteten Browser-Versionen und schließt alle Nutzer anderer Browser aus2 Um ein bestimmtes Aussehen eines HTML-Dokumentes zu erreichen - speziell bei komplexeren Layouts - m¨ ussen zum Teil recht verdrehte Tricks angewendet werden die mit einer strukturierten Darstellung von Informationen kaum noch etwas gemein haben. Damit erf¨ ullt HTML weder den Punkt 1 (Flexibilit¨at der Gestaltung) noch den Punkt 3 (plattform¨ ubergreifende Darstellbarkeit) in akzeptablem Umfang. Es wird also ein anderes Dokumentenformat ben¨otigt. 3.1.3

XML als neues Format in MONARCH

Als Ausweg aus diesem Dilemma bietet sich XML an. Wie aus den bisherigen Ausf¨ uhrung ersichtlich ist erf¨ ullt XML die vorgenannten 4 Punkte mit Bravour - einen entsprechenden sinnvollen Umgang mit den umfangreichen vorhandenen M¨oglichkeiten nat¨ urlich vorausgesetzt. 1 Hier 2 So

seien besonders die BLINK- (Netscape) und MARQUEE-Tags (Internet Explorer) genannt. unsinnig das klingt wird es doch tats¨ achlich von einigen Websites so praktiziert.

15

Aufgrund der vorhergehenden Ausf¨ uhrungen zu XML ist es an dieser Stelle nicht notwendig noch einmal detailliert die Vorteile des Einsatzes von XML f¨ ur Publikationen zu erl¨autern. Daher soll hier nur auf die f¨ ur den Einsatz von XML in MONARCH relevanten Bereiche eingegangen werden: • Flexibilit¨ at in der Dokumentengestaltung - dieser Aspekt des Publizierens mit XML wurde bereits erl¨ autert, allerdings wirft diese Flexibilit¨at auch Probleme auf f¨ ur die im folgenden L¨osungsans¨ atze diskutiert werden sollen, • plattform¨ ubergreifende Verwendung - wie bereits mehrfach beschrieben ist das bei XML kein Problem da das eines der Entwurfsziele f¨ ur XML war, • plattform¨ ubergreifende Darstellung - aufgrund der geringen Verbreitung XML-f¨ahiger Browser ist dies ein Problem f¨ ur das es jedoch eine relativ einfache, zweiteilige L¨osung gibt die im folgenden diskutiert werden soll, • einfache Indizierbarkeit f¨ ur eine Volltextsuche - da es sich bei XML um ein textbasiertes Format handelt sind XML-Dokumente problemlos mit vorhandener Software zu indizieren, auf die besonderen M¨ oglichkeiten die strukturierte Dokumente f¨ ur eine Recherche bieten soll noch eingegangen werden 3.1.4

Darstellung von XML-Dokumenten in MONARCH

Aufgrund der noch geringen Verbreitung von wirklich vollst¨andig XML-f¨ahigen Browsern besteht bei der Archivierung von XML-Dokumenten das Problem der Visualisierung. Dem Nutzer das reine XML zur Darstellung anzubieten ist naheliegenderweise nicht zumutbar, da es sich als reine String-Ansammlung ohne Layout pr¨ asentieren w¨ urde wenn sein Browser nicht XML-f¨ahig ist und nur HTML beherrscht (momentan die Standardsituation). Somit muß die Publikation vom Archivierungsformat XML in das Darstellungsformat HTML konvertiert werden. Die Methodik dazu wurde bereits erl¨ autert - Kombination von XML und Stylesheets. Ob diese Umwandlung bereits bei der Archivierung oder erst beim Zugriff auf die Publikation geschieht sei dahingestellt - sicherlich ist es schneller und effizienter diese Konvertierung einmal bei der Archivierung vorzunehmen. F¨ ur die Erzeugung des Darstellungsformates ben¨otigt man nat¨ urlich neben dem XML-Dokument auch das dazugeh¨ orige Stylesheet. An dieser Stelle muß bei der Implementation des XML-Supports von MONARCH entschieden werden welche der 3 sich dabei bietenden M¨oglichkeiten zum Einsatz kommen sollen: • Festlegung auf eine einzige Style-Definition3 . Dies vereinfacht nat¨ urlich die Implementation enorm, allerdings schr¨ ankt eine ung¨ unstige Wahl der Style-Definition die Autoren unter Umst¨ anden stark ein. Es m¨ ußte dann also eine hinreichend umfassende und flexible StyleDefinition ausgew¨ ahlt werden - es bietet sich die XML-Version[54] von DocBook[53] an. • Festlegung auf einen Satz von Style-Definitionen. Dies bewahrt weitestgehend die implementationstechnischen Vorteile des vorhergehenden Ansatzes, entsch¨arft aber etwas das Problem der Einengung der Autoren. Auch hier w¨are eine wohl¨ uberlegte Auswahl geeigneter StyleDefinitionen n¨ otig. • Volle Flexibilit¨ at, bei der Archivierung wird vom Autor die verwendete Style-Definition mitgeliefert. Dies erh¨ oht allerdings den damit verbundenen Implementationsaufwand unter Umst¨ anden nicht unerheblich da es verschiedene Definitionsm¨oglichkeiten (DTD oder Schemas, DSSSL oder XSL, . . . ) gibt. Es m¨ ußte dann die Entscheidung getroffen werden ob alle M¨oglichkeiten oder nur ein definiertes Subset dieser M¨oglichkeiten unterst¨ utzt wird. 3 An dieser Stelle wird davon ausgegangen das die Style-Definition aus Dokumentenstrukturbeschreibung und Stylesheet besteht

16

Diese Fragen weiter zu verfolgen w¨ urde jedoch den Rahmen der vorliegenden Studienarbeit sprengen. Es sei darum auf die Diplomarbeit zum Thema langlebiger Dokumentenformate von Bert Auerbach verwiesen. Sie besch¨ aftigt sich unter anderem mit der Integration von XML in das Archivierungssystem von MONARCH und sollte zum Abgabetermin dieser Studienarbeit bereits vorliegen. 3.1.5

Integration von XML-Dokumenten in MONARCH-Recherchesystem

F¨ ur die Integration von XML-Dokumenten in das Recherchesystem von MONARCH bieten sich zwei M¨oglichkeiten an: • Einfache Integration in die Volltextrecherche durch einfache Volltextindizierung des Dokumentes. Dies ist mit geringf¨ ugigem Aufwand unter Einsatz von bereits vorhandenen und in MONARCH integrierten Werkzeugen m¨oglich • Implementierung einer strukturierten Suche u ¨ber dem Dokument. Dazu w¨aren allerdings neue Werkzeuge zu implementieren. Die Idee einer strukturierten Suche in einem archivierten Dokument ist auf den ersten Blick auf jeden Fall verlockend - besonders wenn es sich um ein umfangreiches Dokument handelt. Wie k¨onnte so etwas realisiert werden ? Zuallererst m¨ ußte die grunds¨atzliche Dokumentenstruktur bekannt sein. Dies liesse sich erreichen indem: • eine einzige Dokumentenstruktur (z.B. DocBook XML verwendet wird oder • ein Satz von Dokumentenstrukturen mit einheitlichen Elementen verwendet wird oder • die vom Author verwendete Dokumentenstruktur bestimmten, vorher zu definierenden Bedingungen gen¨ ugt (Verwendung bestimmter standardisierter Elemente) Eine strukturierte Recherche u utzung ¨ber eine unbekannte Dokumentenstruktur ist ohne Unterst¨ durch den Suchenden nicht sinnvoll, es m¨ ußten in diesem Fall die relevanten Strukturelemente selektiert werden (eventuell mit einer Art Dokumentenstruktur-Explorer“ der die Dokumen” tenstruktur anhand der Strukturdefinition visualisiert). Eine strukturierte Suche u ¨ber ein XMLDokument w¨ urde sinnvollerweise direkt u ¨ber dem Dokument arbeiten - entsprechende Software zum Herausfischen“ von Informationen aus XML-Dokumenten gibt es bereits. Allerdings w¨are ” vorher zu kl¨ aren ob u ¨berhaupt ein hinreichend großer Bedarf an einem derartig komplexen Feature besteht. Da bereits die vorhandene detaillierte Suche in MONARCH deutlich weniger genutzt wird als die einfach Suche ist davon auszugehen daß die zu erwartende geringe Nutzung einer strukturierten Suche u ¨ber XML-Dokumenten den Implementationsaufwand nicht rechtfertigt - dazu kommt das vorl¨aufig nur mit einer geringen Anzahl von archivierten XML-Dokumenten zu rechnen ist, auch wenn sich das mit zunehmener Akzeptanz und Verbreitung von XML als Dokumentenformat durchaus ¨ andern kann.

3.2

Interne Einsatzm¨ oglichkeiten fu ¨ r XML im MONARCH-System

Wie von vielen anderen XL-basierten Projekten immer wieder bewiesen wird kann man XML wesentlich mehr machen als nur Dokumente publizieren - auch wenn sich die die Untersuchung bisher besonders darauf konzentriert hat. Zum Beispiel kann XML als als Speicherformat f¨ ur Daten verschiedenster Art im Sinne einer Datenbank (im Kleinformat) verwendet werden. In MONARCH finden sich verschiedene Stellen an denen XML als Speicherformat verwendet werden k¨onnte, diese lassen sich in drei Gruppen zusammenfassen: • Metadaten • Konfiguration • Logs Diese drei m¨ oglichen Anwendungsgebiete sollen im folgenden detaillierter untersucht werden. 17

3.2.1

XML f¨ ur die Metadaten in MONARCH

Zu jeder Publikation wird in MONARCH ein Satz Metadaten gespeichert. Dieser Datensatz beschreibt die Publikation und enth¨ alt Informationen wie zum Beispiel: • Titel, • Autor, • Co-Autoren, • Schlagworte f¨ ur die Publikation, • einen Abstract f¨ ur die Publikation, • den URL der Publikation. Die Metadaten der Publikation entsprechen dabei den Vorgaben des DublinCore[55] Metadatensatzes. Erzeugt werden die gespeicherten Metadaten in zwei Schritten: 1. Eingabe der Metadaten im Verlauf der Archivierung durch den Archivierenden (¨ uber das Webformular der Archivierung [57]), die Metadaten werden dann zusammen mit den weiteren Daten des Archivierungsauftrages in einem tempor¨aren Format gespeichert, 2. Erzeugung der Metadatendatei im SOIF-Format, Erzeugung der Indizierungsdaten f¨ ur die Volltextindizierung und Erweiterung der Metadatendatei um diese Indizierungsdaten Derzeit werden diese Metadaten intern im Summary Object Interchange Format (SOIF)[56] gespeichert. Im Rahmen der Einf¨ uhrung von XML-Technologie in MONARCH k¨onnte man dieses Format durch XML ersetzen. Allerdings bringt dies keine Vorteile - weder in der Speicherung noch in der Handhabung oder Auswertung der Metadaten. Dazu kommt daß es sich bei SOIF um eine standardisierte, getestet und bew¨ahrte Technologie handelt. Der Umstieg auf XML w¨ urde die unter anderem die Anpassung existierender Software sowie entsprechende Testserien erfordern - also ein nicht unerheblicher Aufwand ohne Gewinn an Funktionalit¨at. Solange die Metadaten weitestgehend in der derzeitigen Datenform verwendet werden gibt es keine Gr¨ unde das SOIF ¨ durch ein anderes Datenformat abzul¨ osen. Sollte eine Anderung des Metadaten-Formats anstehen ¨ so ist gegebenfalls dieAnderung des Speicherformates zu erw¨agen, doch auf diese Problematik soll sp¨ater in diesem Text noch einmal eingegangen werden. Außer den publikationsbeschreibenden werden in MONARCH noch weitere Metadaten verwendet, unter anderem: • zur Beschreibung des Archivierungsauftrages, • zur Speicherung der Daten f¨ ur die Volltextrecherche Die Metadaten zur Beschreibung der Archivierungsauftr¨age werden vom Archivierungsformular erzeugt und bestehen aus mehreren Dateien. Eine Umstellung auf XML w¨ urde erheblichen Aufwand verursachen - schon deswegen weil das zentrale Archivierungsskript von dem diese Beschreibungsdateien verarbeitet werden in einer Form implementiert ist bei der die Integration von XML gewisse Probleme aufwirft - Shell Skript. Zudem ist auch zu beachten daß der Umstieg auch hier keinen Gewinn an Funktionalit¨ at liefern w¨ urde und somit nicht gerechtfertigt ist. Die Daten f¨ ur die Volltextrecherche werden mit verschiedenen Tools als ASCII-Text aus den Publikationen extrahiert und schließlich mit glimpse[58] indiziert. Dabei speichert glimpse die entstehenden Metadaten in einem eigenen Format - ein Umstieg auf XML ist an dieser Stelle also nicht m¨ oglich und auch nicht sinnvoll da glimpse in kompaktes, auf die Volltextrecherche optimiertes Format verwendet.

18

3.2.2

XML f¨ ur Logdaten

Das Format der in MONARCH - insbesondere w¨ahrend der Archivierung - anfallende Logdaten ist ein einfaches Textformat mit einem Eintrag pro Zeile. Jeder Eintrag bvesteht dabei aus einem Zeitstempel und dem Eintragstext. Die Logs werden nicht maschinell verarbeitet sondern bei Bedarf (wenn Porbleme auftreten) vom MONARCH-Admin oder vom MONARCH-Systemprogrammier gelesen. Eine Verwendung von XML daf¨ ur w¨are theoretisch m¨oglich, ist aber unsinnig da sie die sehr einfache Struktur der Logsfiles unn¨otig komplizieren w¨ urde und keine Vorteile dadurch erzielt w¨ urden. 3.2.3

XML f¨ ur Konfigurationsdaten

Um die Konfiguration der verschiedenen Teilkomponenten von MONARCH zu vereinfachen wird der u uhrt. ¨berwiegende Teil der Konfigurationsdaten in einer zentralen Konfigurationsdatei gef¨ Diese benutzt derzeit eine eigene, makrof¨ahige Syntax. Ein Umstieg auf XML an dieser Stelle w¨ urde eventuell eine klarere (hierarchische) Strukturierung der Konfigurationsdaten erm¨oglichen. Das w¨ urde aber bedeuten das in allen Teilsystemen die Routinen zum Laden der Konfigurationsdaten zu ersetzen w¨ aren. Obwohl daf¨ ur bereits an den jeweiligen Stellen eine Standardprozedur verwendet wird w¨are es doch mit einem gewissen Aufwand verbunden. Meiner Einsch¨atzung nach rechtfertigt der Gewinn an Strukturierungsm¨ oglichkeiten den notwendigen Aufwand der Implementierung einer XML-L¨osung an dieser Stelle nicht.

19

4 4.1

Schlußfolgerungen zu XML Einsatz von XML fu ¨ r Publikation und Archivierung

Es hat sich gezeigt das XML sich hervorragend als Werkzeug zum Erstellen, Publizieren und Archivieren von Dokumenten verschiedenster Art eignet. XML und verschiedene, f¨ ur das Publizieren mit XML interessante, XML-Anwendungen sind entweder bereits als Standards vom W3 Consortium definiert oder befinden sich gerade in diesem Prozess und existieren als Working Drafts. Es gibt ein sehr umfangreiches Angebot, sowohl kommerziell als auch nicht-kommerziell, an Werkzeugen und Applikationen die XML-f¨ ahig sind oder auf XML basieren. Die meisten dieser Werkzeuge lassen sich recht einfach gem¨ aß den eigenen Bed¨ urfnissen anpassen oder erweitern. Somit ist der Bereich der notwendigen Anwendungen und Werkzeuge vollkommen abgedeckt - zumal immer noch die Option steht eigene Werkzeuge zu entwickeln was aufgrund der offenen Struktur von XML einerseits und des großen Angebots von XML-Libraries, XML-Modules und anderen XML-relevanten Programmierwerkzeugen andererseits relativ einfach m¨oglich ist. XML bietet aber nicht nur die M¨oglichkeiten der Erstellung und Verarbeitung strukturierter Dokumente. Zusammen mit den M¨ oglichkeiten von XSL und DSSSL er¨offnet sich auch ein breites Spektrum an Darstellungsformaten f¨ ur die XML-Dokumente. Mit den entsprechenden Werkzeugen k¨onnen aus XML-Dokumenten zusammen mit den entsprechenden Stylesheets die unterschiedlichsten Darstellungsformate (HTML, PostScript) und -formen (Website, Buch) erzeugt werden. Aus den Eigenschaften von XML als offene, portabler Metasprache resultiert auch die gute Eignung von XML-Dokumenten f¨ ur die Aufbewahrung in digitalen Archiven. Im Gegensatz von herstellerspezifischen, geschlossenen, nicht standardisierten Dokumentenformaten hat XML den Vorteil, daß ein Zugriff auf Struktur und Inhalt des Dokumentes bereits mit sehr einfachen Mitteln m¨ oglich ist und jederzeit Werkzeuge verwendet werden k¨onnen um aus dem strukturierten Speicherformat XML eine jeweils geeignete und den aktuellen M¨oglichkeiten entsprechende Darstellungsform zu erzeugen. Das Risiko den Zugriff auf die Inhalte eines XML-Dokuments zu verlieren“ weil die das Format verstehende“ Software nicht mehr verf¨ ugbar ist entf¨allt bei XML ” ” aufgrund der Offenheit des Formates.

4.2

XML und MONARCH

Der Einsatz von XML in MONARCH ist bereits vorgesehen - festzustellen bleibt in welchem Umfang er erfolgen soll. Es l¨ auft derzeit eine Diplomarbeit zur Integration von XML-Dokumenten in MONARCH, durchgef¨ uhrt von Bert Auerbach . Die Ergebnisse dieser Arbeit sollten zum Abgabetermin der vorliegenden Studienarbeit verf¨ ugbar sein. Daher er¨ ubrigen sich weitere Ausf¨ uhrungen zum Thema XML-Dokumente in MONARCH an dieser Stelle. Es wurden aber noch weitere m¨ ogliche Einsatzbereiche f¨ ur XML in MONARCH angesprochen. Das ein unkritisches Ersetzen von bisherigen Technologien in MONARCH durch XML nicht sinnvoll ist liegt auf der Hand, allerdings bleibt ein Bereich in dem sich gegebenenfalls der Umstieg auf eine XML-basierte Technologie als sinnvoll erweisen k¨onnte: die Speicherung der publikationsspezifischen Metadaten. Es bietet sich jedoch eine XML-basierte Technologie an die sich f¨ ur diesen Zweck eignet: RDF. Auf dieser Grundlage w¨are es m¨oglich auch die Funktionalit¨at der Metadaten zu erweitern. Das Thema RDF soll in den folgenden Kapiteln weiter untersucht werden.

20

5

RDF

5.1 5.1.1

RDF - Grundlagen Hintergrund

Eines der gr¨ oßten Probleme f¨ ur die Resourcenbeschreibung war die mangelnde Austauschbarkeit der Datens¨ atze aufgrund der Verwendung zahlreicher unterschiedlicher Formate, sowohl f¨ ur die Speicherung als auch f¨ ur die Erfassung der Metadaten. Das Problem der Metadatenstandardisierung wurde weitestgehend mit dem DublinCore[55] gel¨ost der einen Satz von Metadaten definierte. Nicht gel¨ ost wurde das Problem der standardisierten Speicherung der Metadaten. Eines der verbreiteteren Formate zur Speicherung von Metadaten ist das auch in MONARCH verwendete Summary Object Interchange Format (SOIF)[56]. Aber es ist nur eines von mehreren zur Speicherung von Metadaten verwendeten Formaten und das Problem eines einheitlichen Formates zur Speicherung und zum Austausch von Metadaten stand noch zur L¨osung aus. 5.1.2

Entwicklung von RDF

Die Bem¨ uhungen zur Schaffung eines einheitlichen Metatdaten-Standards zur Beschreibung von Internet-Resourcen f¨ uhrten zur Definition der Resource Description Framework(RDF) Model and Syntax Specification[59] deren erste Fassung als W3C Working Draft[60] am 2. Oktober 1997 ver¨offentlicht wurde. Die aktuelle Version liegt als W3C Empfehlung vom 22. Februar 1999 vor und gilt somit als stabiles Dokument. RDF ist einerseits ein graphenbasiertes Modell zur Beschreibung von Internetressourcen (die durch URIs4 spezifiziert werden) und deren Beziehungen untereinander und andererseits eine Serialisierungssyntax die es erlaubt dieses Graphenmodell zwischen Agenten“ auszutauschen. Das ” Grundmodell von RDF besteht aus einer durch eine URI spezifizierten Ressource und den Eigenschaften dieser Ressource die sich aus einem Eigenschaftstyp und einem Eigenschaftswert zusammensetzen. 5.1.3

Entwurfsziele f¨ ur RDF

Die Zielsetzung f¨ ur RDF bestand in der Definition eines nicht nur maschinenlesbaren sondern maschinenverst¨ andlichen Metadatenformates. Es sollte ein Metadatenformat geschaffen werden das von Softwaresysteme, sogenannten Agenten“ selbstt¨atig gefunden, weitergegeben, ausgetauscht, ” analysiert und verarbeitet werden kann. Gedacht als universelles Beschreibungsformat f¨ ur Ressourcen im Netz kann man sich RDF am einfachsten als eine Art Indexkarten“-System f¨ ur das ” Netz vorstellen, ein Hilfsmittel um mittels standardisiert strukturierter Beschreibungen Resourcen im Netz einfacher lokasieren und bewerten zu k¨onnen - nicht nur manuell sondern vor allem automatisch durch autonome Agentensysteme. 5.1.4

RDF am Beispiel

Ein Beispiel f¨ ur eine einfache RDF-Beschreibung sieht man in der Abbildung. An dieser Stelle f¨ allt bereits wieder die bekannte XML-Syntax ins Auge. Das liegt nat¨ urlich daran daß es sich bei RDF um eine XML-Anwendung handelt. RDF erweitert das XML Modell und die XML Syntax um Mittel zur Beschreibung von Resourcen. Dazu bedient sich RDF der XML Namespaces[63] um einen eigenen Namensraum zu definieren. Das vorige Beispiel definiert zwei Namensr¨ aume: den RDF-Namensraum (aus dem das Description-Tag stammt) und dazu den DublinCore-Namensraum f¨ ur den das Tag-Prefix DC: verwendet wird. Nat¨ urlich k¨onnen verschiedene Metadaten-Definitionen verwendet werden - vorausgesetzt sie benutzen keine kollidierenden Namensr¨ aume. 4 Uniform

Resource Identifier

21

The Future of Metadata Jacky Crystal 1998-01-01 Metadata, RDF, Dublin Core Abbildung 4: Einfaches Beispiel f¨ ur RDF

5.2

Anwendungsbeispiele von RDF

Im den folgenden Unterabschnitten sollen die M¨oglichkeiten von RDF anhand einiger Bereiche vorgestellt werden in denen RDF bereits verwendet wird. 5.2.1

Unterst¨ utzung von Suchmaschinen durch eingebettetes RDF in Webseiten

Es ist m¨oglich und vorgesehen RDF-Datens¨atze in Webseiten einzubetten - dies soll in der HEADSektion geschehen, wie jetzt schon f¨ ur Metadaten in Form von META-Tags u ¨blich. Entsprechend clevere“ Suchmaschinen k¨ onnten beim automatischen Entdecken“ und Katalogisieren dieser ” ” Webseite dann den eingebetteten RDF-Datensatz in ihre interne Beschreibung der Webseite u ¨bernehmen. Die anschließende Suche eines Nutzers einer solchen Suchmaschine k¨onnte dann durch Ber¨ ucksichtigung der Metadaten aus dem RDF-Datensatz mit besseren Ergebnissen aufwarten. Obwohl dies die Rechercheergebnisse bei der Benutzung von Suchmaschinen deutlich verbessern k¨onnte scheitert der breite Erfolg dieses Ansatzes bisher an zwei Problemen: 1. Es m¨ ussen RDF-Datens¨ atze in den Webseiten vorhanden sein. Dies wird am ehesten noch bei automatisch generierten Seiten passieren w¨ahrend individuell erstellte Seiten wohl nur in den seltensten F¨ allen derartig bereichert werden. 2. Zum jetzigen Zeitpunkt (April 2000) sind nur wenige Suchmaschinen bekannt die RDF u ¨berhaupt kennen. Eine davon ist das Open Directory dmoz.org[66] - dort wird sogar ein RDF-Dump des aktuellen Inhaltes[67] angeboten. Allerdings ist Open Directory eher ein Verzeichnis-System als eine selbstst¨andig agierende Suchmaschine. Die Datenbest¨ande des Open Directory werden jedoch von einer sehr großen Anzahl anderer Suchmaschinen mitgenutzt. 5.2.2

RDF in Mozilla

Das Mozilla-Projekt[65] verwendet RDF an verschiedenen Stellen, darunter: • Sitemaps, • Bookmarks, • Smart Browsing, • Search Results, In all diesen genannten Bereichen sind Informationen zu speichern, zu verwalten und zu organisieren die prinzipiell identische Strukturen haben: es handelt sich um Ressourcen und die dazugeh¨ origen Beschreibungen - also genau das wof¨ ur RDF entwickelt wurde. Die Vorteile der

22

Zusammenfassung der Datenverwaltung in einem gemeinsamen, RDF-basierten Modell sind offensichtlich: • vereinfachte weil einheitliche Implementation der Handhabung, • freie Kombinierbarkeit der Objekte - zum Beispiel k¨onnte man sich als Nutzer einen Ordner erstellen der Elemente aus allen vier obigen Kategorien enth¨alt und alle Objekte mit den gleichen Operationen bearbeiten, • vereinfachte Handhabung - beim Anlegen einer Bookmark zu einer Website k¨onnten die entsprechenden Eigenschaften (nicht nur URL sondern auch Titel, Autor, Abstract, . . . ) bereits automatisch vorausgef¨ ullt sein weil sie einem in der Webseite eingebetteten RDFDatensatz entnommen wurden. Dabei wird von Mozilla der DublinCore Namespace zur detaillierten Beschreibung der jeweiligen Ressourcen verwendet. 5.2.3

RDF und DublinCore

RDF und DublinCore sind zwei sich gegenseitig hervorragend erg¨anzende Entwicklungen, da beide die jeweils andere H¨ alfte des Problems austauschbarer, universaler Metadaten l¨osen: • RDF beschreibt eine einfach zu verarbeitende Syntax f¨ ur einen Metadaten-Container, macht aber kaum Aussagen u ¨ber die Semantik, • DublinCore beschreibt sehr genau die Semantik der Metadaten, d.h. die Bezeichner und zugeh¨ origen Inhalte der Metadatenfelder, definiert jedoch kein Containerformat. Als Folge davon wurden Metadaten nach DublinCore in den unterschiedlichsten, nicht zueinander kompatiblen Containerformaten gespeichert.

Guidance on expressing the Dublin Core within the Resource Description Framework (RDF) Eric Miller Paul Miller Dan Brickley Dublin Core; Resource Description Framework; RDF; eXtensible Markup Language; XML Dublin Core Metadata Initiative Dublin Core Data Model Working Group 1999-07-01 text/html en

Abbildung 5: Ausf¨ uhrliches Beispiel f¨ ur den Einsatz von RDF mit DublinCore Erst die Kombination der beiden liefert eine optimale L¨osung - die Definition des portablen Containerformats gem¨ aß RDF das gem¨aß den semantischen Vorgaben von DublinCore mit Metadaten gef¨ ullt wird.

23

Diese Kombination erweitert zudem die M¨oglichkeiten von DublinCore: urspr¨ unglich war in DublinCore nicht vorgesehen, daß die Metadaten in einer anderen Sprache als die von ihnen beschriebene Publikation abgefaßt sein k¨onnten. Mit dem Language-Tag von XML ist es jedoch m¨oglich zum Beispiel einen deutschen Metadatensatz zu einer englischsprachigen Publikation zu realisieren und das auch im Metadatensatz kenntlich zu machen. Die DublinCore Initiative hat f¨ ur die Kodierung von DublinCore in RDF insgesamt drei Namensr¨aume definiert: • der eigentliche DublinCore Namensraum[69], • der DublinCore Qualifier Namensraum[70], • der DublinCore Terms Namensraum.[71] Die beiden letztgenannten Namensr¨aume definieren M¨oglichkeiten zur genaueren Beschreibung der Metadaten nach DublinCore. Dadurch wird eine weitere Erh¨ohung der Dichte und Genauigkeit der in den Metadaten gem¨ aß DublinCore gespeicherten Informationen m¨oglich. Weiterhin k¨onnen nat¨ urlich die DublinCore Namensr¨ aume auch mit anderen Namensr¨aumen kombiniert werden. So w¨are es zum Beispiel m¨ oglich f¨ ur jede in den Metadaten einer Publikation genannte Person (Autor, Co-Author, . . . ) eine Visitenkarte im vcard-Format zu integrieren (nat¨ urlich in entsprechender XML-konformer Syntax ausgef¨ uhrt) um die Person detaillierter zu beschreiben.

24

6

RDF und MONARCH

6.1

Einsatzm¨ oglichkeiten von RDF in MONARCH

F¨ ur das RDF-Format bieten sich in MONARCH mehrere Anwendungsm¨oglichkeiten an. Diese sollen im folgenden untersucht werden. 6.1.1

Unterst¨ utzung f¨ ur Suchmaschinen

Die einfachste aller Anwendungen von RDF in MONARCH besteht darin, RDF als Format zur Kommunikation von Metainformationen u ¨ber Publikationen zu verwenden um Suchmaschinen bei der Klassifikation der in MONARCH archivierten Publikationen zu unterst¨ utzen. Der Ansatzpunkt daf¨ ur sind die automatisch generierten Indexseiten der archivierten Publikationen. Daf¨ ur wird aus der - wie auch immer realisierten - MONARCH-internen Speicherungsform der Metadaten der jeweiligen Publikation ein RDF-Datensatz gem¨aß DublinCore erzeugt und in die HEAD-Sektion der automatisch erzeugten Indexseite eingebettet. Dies ist mit relativ geringem Aufwand machbar und sollte realisiert werden. 6.1.2

RDF als internes Speicherformat der Metadaten

In MONARCH werden die Metadaten nach DublinCore erfaßt und derzeit als SOIF gespeichert. Da RDF im Verbund mit DublinCore die gleiche Information auszudr¨ ucken vermag k¨onnte man ohne Verlust an Funkionalit¨ at auf RDF als Speicherformat umsteigen. Ohne wirkliche Vorteile ist eine solcher Umstieg - der ja schließlich mit einem gewissen Aufwand verbunden ist - nicht sinnvoll. ¨ Es gibt jedoch bereits Uberlegungen die in MONARCH gespeicherten Metadaten irgendwann um Qualified DublinCore zu erweitern. Dies w¨are zwar prinzipiell auch in der bisherigen Form in SOIF zu speicherbar, allerdings ist RDF 1. zum einen das bessere Werkzeug f¨ ur diese Aufgabe und zum anderen 2. w¨ urde diese Umstellung grunds¨atzlich - unabh¨angig vom gew¨ahlten Speicherformat f¨ ur die Metadaten - einen gewissen Umstellungsaufwand bedeuten, diesen kann man auch f¨ ur eine grunds¨ atzliche Umstellung und damit saubere L¨osung (auf Basis von RDF) investieren. 6.1.3

RDF zur Realisierung grunds¨ atzlich neuer Features

Eine weitere M¨ oglichkeit f¨ ur den Einsatz von RDF in MONARCH w¨are die Realisierung von neuen Features auf Grundlage von RDF. Bei diesen sollte es sich um Features handeln f¨ ur die RDF die optimale L¨ osung darstellt. Ein solches Feature ist die Implementation aggregierter Dokumente eine Idee welche noch weiter verfolgt werden soll.

6.2 6.2.1

Aggregierte Dokumente in MONARCH Konzept aggregierter Dokumente

Ein aggregiertes Dokument ist eine Publikation die durch die Zusammenfassung mehrere Teilpublikationen entsteht. Dabei k¨ onnen mehrere Ebenen ineinander geschachtelt sein. Ein Beispiel sind die URZ-Nachrichten die mehrmals j¨ahrlich erscheinen und aus mehreren Artikeln bestehen. Derzeit wird diese Publikation als eine Publikation der jweiligen Ausgabe archiviert. Eine m¨ogliche hierarchische Gliederung als aggregiertes Dokument w¨are zum Beispiel: 1. die gesamten URZ-Nachrichten als Zeitschrift bestehend aus Jahrg¨angen, 2. der Jahrgang der URZ-Nachrichten bestehend aus Ausgaben, 3. die Ausgaben der URZ-Nachrichten bestehend aus den einzelnen Artikeln.

25

Jede dieser drei Stufen stellt eine eigene Aggregatestufe dar. Jedes Aggregat ist eine Ressource, eindeutig identifiziert durch ihren URI. Diese Ressource besteht aus Teilkomponenten die wiederum ihrerseits Ressourcen darstellen. 6.2.2

Realisierung in RDF

Als Speicherformat f¨ ur eine solche Technologie bietet sich RDF an da es alle notwendigen Eigenschaften besitzt. Eine m¨ ogliche Implementation daf¨ ur in RDF k¨onnte wie folgt aussehen: • jedes Aggregat ist eine Ressource die in einem eigenen RDF-Datensatz beschrieben wird, • zu diesem RDF-Datensatz geh¨ oren ein paar Angaben die globale Eigenschaften des Aggregates sind (Editor, Herausgeber, Titel, . . . ) sowie die Verweise auf die Einzelkomponenten des Aggregats, • zu jedem Aggregat geh¨ ort eine entweder vom Archivierenden angebene, sonst automatisch generierte Inhaltsseite die alle Komponenten des Aggregats auf einer Seite als Links vereint • diese Kombination als Inhaltsseite und RDF-Datensatz zum Aggregat wird in MONARCH als eigenst¨ andige Publikation archiviert. • im Verlaufe der Archivierung wird auf Grundlage des RDF-Datensatzes der Metadatensatz des Aggregates im internen Format generiert und daraus wiederum die Einstiegsseite des als einzelne Publikation archivierten Aggregats. Diese Implementation nutzt die Eigenschaften von RDF und paßt sich gut in die vorhandene MONARCH-Technologie ein. F¨ ur eine konkrete Realisierung die dann auch im MONARCHSystem genutzt wird sind nat¨ urlich vorherige Arbeitsbesprechungen mit dem Team der Universit¨atsbibliothek unbedingt notwendig da nat¨ urlich f¨ ur die Realisierung einer solchen Technologie auch bibliothekarische Erfordernisse einfließen m¨ ussen. Als Vorf¨ uhrung der prinzipiellen Funktionalit¨at sowie als Diskussionsgrundlage f¨ ur die eigentliche Implementation wird eine einfache Implementation im Entwicklungssystem von MONARCH realisiert. Diese wird jedoch nur kurze Zeit existieren um von der eigentlichen Implementation abgel¨ost zu werden. Eine vollst¨ andige Durchimplementierung w¨ urde unter anderem • eine Schnittstelle zum Zusammenfassen von Publikationen zu Aggregaten, • eine Schnittstelle zur Integration in die Metadatenverwaltung von MONARCH sowie • eine nutzertransparente Integration in das Suchsystem von MONARCH (so das bei Suchtreffern in Aggregatkomponenten auch das Aggregat selbst als Treffer angezeigt wird) erfordern. Ausserdem sind verschiedene andere Fragen, wie zum Beispiel • inhaltliche Gestaltung der Metadaten des Aggregats, • Gestaltung der Darstellung des Aggregats (Frontdoor-Layout) in Zusammenarbeit mit dem Team der Universit¨atsbibliothek zu kl¨aren. Die w¨ urde zum einen den Bereich dieser deutlich u uhrimple¨berschreiten und zum anderen w¨are eine voll ausgebaute Vorf¨ mentation ohne die oben erw¨ ahnte Zusammenarbeit nur sehr begrenzt sinnvoll. Aus diesem Grund wird sich die (kurzlebige) Beispielimplementation nur auf eine einfache Vorf¨ uhrung des Prinzips der Aggregation beschr¨ anken.

26

7

Schlußfolgerungen zu RDF

7.1

RDF in Publikation und Archivierung

Wie gezeigt wurde eignet sich RDF hervorragend zur Speicherung, Weitergabe und automatischen Verarbeitung von Metadaten zu Ressourcen. F¨ ur den Einsatz im Bereich des digitalen Publizierens ergibt sich daraus die Empfehlung an die Autoren einer digitalen Publikation zur Erstellung eines RDF-Metadatensatzes zur Publikation um weitere automatisierte Behandlung (Eingliederung in Suchsysteme, Publikationsindex-Systeme, . . . ) zu vereinfachen. Im Umfeld digitaler Archivierungssysteme bietet RDF sehr gute M¨oglichkeiten zur Speicherung von Metadaten. Ausserdem vereinfacht RDF das Zusammenf¨ uhren von Metadatenbest¨anden und deren automatisches Durchsuchen mit Agentensystemen. Obwohl RDF (vereinfacht betrachtet) der digitale Nachfolger der alten Indexkarten von Bibliotheken ist so reichen die M¨oglichkeiten von RDF doch weit dar¨ uber hinaus.

7.2

RDF in MONARCH

F¨ ur den Einsatz von RDF in MONARCH haben sich drei Bereiche ergeben die kurz-, mittel- und langfristig realisierbar sind: • kurzfristig: Einbau von RDF-Metadatens¨atzen in die automatisch generierten FrontdoorSeiten der archivierten Publikationen, • mittelfristig: Implementation der Technologie aggregierter Dokumente auf Grundlage von RDF als Metadatentechnologie, • langfristig: Umstellung der Metadatenverwaltung in MONARCH auf RDF im Zuge der Erweiterung des verwendeten Metadatensatzes.

27

8

Fazit

Diese Betrachtung der M¨ oglichkeiten von XML und RDF im Umfeld von digitaler Publikation und Archivierung hat verschiedene Vorteile dieser Technologien beleuchtet. Es wurden die Vorteile der Verwendung offener standardisierter und m¨oglichst einfacher Datenformate gezeigt. Ein Konzentration auf derartige Formate f¨ordert die Entwicklung zahlreicher verschiedener, auf ¨ diesen Formaten aufsetzender Anwendungen. Gleichzeitig wurde ein kleiner Uberblick u ¨ber die umfangreichen M¨ oglichkeiten und das enorme Potential gegeben u ¨ber das die beiden behandelten Basistechnologien XML und RDF verf¨ ugen. Auch wenn der Umfang darauf basierender Anwendungen bereits jetzt schon kaum noch zu u ur ¨bersehen ist - es wird sich auch in Zukunft noch sehr vieles in diesen Bereichen entwickeln, daf¨ sorgen schon die sehr flexiblen M¨ oglichkeiten dieser Technologien.

28

Literatur [1] XML-Spezifikation: http://www.w3.org/TR/REC-xml [2] IANA (Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. See ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets. [3] IETF RFC 1766 IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of Languages, ed. H. Alvestrand. 1995. [4] ISO 639 (International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988. [5] ISO 3166 (International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions – Part 1: Country codes [Geneva]: International Organization for Standardization, 1997. [6] ISO/IEC 10646 ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology – Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7). [7] Unicode The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996. [8] CPAN (The Comprehensive Perl Archive Network): http://www.cpan.org [9] XML Schema: http://www.w3.org/TR/xmlschema-0/ [10] XML Schema Working Group: http://www.w3.org/XML/Activity.html#schema-wg [11] XML Schema Working Draft: http://www.w3.org/TR/xmlschema-0/ [12] XML Schema Part 1: Structures: http://www.w3.org/TR/xmlschema-1/ [13] Extensible Markup Language (XML): http://www.w3.org/XML/ [14] XML Inclusions (XInlude): http://www.w3.org/TR/xinclude [15] XML Linking Language (XLink): http://www.w3.org/TR/xlink/ [16] DSSSL Documentation Project: http://www.mulberrytech.com/dsssl/dsssldoc/index.html [17] DSSSL Standard Spezifikation: ftp://ftp.ornl.gov/pub/sgml/WG8/DSSSL/dsssl96b.pdf [18] JADE: http://www.jclark.com/jade/ [19] XALAN: http://xml.apache.org/xalan/ [20] Apache: http://www.apache.org [21] LotusXSL: http://www.alphaworks.ibm.com/tech/LotusXSL [22] XMLWriter: http://xmlwriter.net/index.html [23] Microsoft Internet Explorer 5: http://microsoft.com/windows/ie/ie5/default.asp [24] xslj von Henry Thompson: http://www.cogsci.ed.ac.uk/ ht/xslj.html [25] IBM XSL Editor: http://www.alphaworks.ibm.com/tech/xsleditor/ [26] eXcelon Stylus: http://www.exceloncorp.com/products/excelon stylus.html 29

[27] XSL Working Draft: http://www.w3.org/TR/xsl/ [28] XSL Transformations: http://www.w3.org/TR/xslt/ [29] XML::Parser: http://search.cpan.org/doc/COOPERCL/XML-Parser-2.28/Parser.pm [30] XML-RPC Spezifikation: http://www.xmlrpc.com/spec/ [31] XML-RPC Website: http://www.xmlrpc.com [32] Precision Graphics Markup Language (PGML): http://www.w3.org/TR/1998/NOTE-PGML [33] KIllustrator: http://wwwiti.cs.uni-magdeburg.de/ sattler/killustrator.html [34] KOffice: http://koffice.kde.org/ [35] Text Encoding Initiative: http://www.hti.umich.edu/docs/TEI/ [36] XML.org Portal: http://www.xml.org [37] Martsoft: http://www.martsoft.com [38] Open Catalog Protokoll (OCP): http://www.martsoft.com/ocp/ [39] Open Catalog Format: http://www.martsoft.com/ocp/ [40] Oasis Open, XML-Seite: http://www.oasis-open.org/cover/xml.html [41] Apache XML Project: http://xml.apache.org/ [42] Encyclopaedia Britannica: http://www.britannica.com [43] Dynamic Publishing: The XML Difference: http://www.seyboldseminars.com/Events/sf98/transcripts/Eday8 1.html [44] Multimedia ONline Archiv CHemnitz: http://archiv.tu-chemnitz.de [45] Technische Universit¨ at Chemnitz: http://www.tu-chemnitz.de [46] Universit¨ atsrechenzentrum der TU Chemnitz: http://www.tu-chemnitz.de/urz/ [47] Universit¨ atsbibliothek Chemnitz: http://www.bibliothek.tu-chemnitz.de/ [48] Adobe PostScript: http://www.adobe.com/print/postscript/main.html [49] GhostScript - der Software-Renderer f¨ ur PostScript: http://www.ghostscript.com/ [50] Adobe Acrobat: http://www.adobe.com/products/acrobat/ [51] Adobe Distiller: http://www.adobe.com/products/acrdis/ [52] HyperText Markup Language (HTML): http://www.w3.org/MarkUp/ [53] DocBook: http://www.docbook.org [54] DocBook XML: http://www.docbook.org/xml/ [55] Dublin Core Metadata Initiative: http://purl.org/DC/ [56] The Summary Object Interchange Format (SOIF) in the Harvest Users Manual version 1.4, 1996, http://harvest.transarc.com/afs/transarc.com/public/trg/Harvest/usermanual/node151.html oder direkt via AFS: /afs/transarc.com/public/trg/Harvest/usermanual/node151.html 30

[57] MONARCH Archivierungsformular (erfordert g¨ ultiges Nutzerkennzeichen des URZ der TU Chemnitz): https://archiv.tu-chemnitz.de/cgi-bin/auth/Formular Archivieren.cgi [58] GLIMPSE: http://glimpse.cs.arizona.edu/ [59] Resource Description Framework (RDF) Model and Syntax Specification: http://www.w3.org/TR/REC-rdf-syntax/ [60] RDF Working Draft 19991002: http://www.w3.org/TR/WD-rdf-syntax-971002/ [61] RDF Schema: http://www.w3.org/TR/rdf-schema/ [62] An Idiot´s Guide to the Resource Description Framework: http://archive.dstc.edu.au/RDU/reports/RDF-Idiot/ [63] Namespaces in XML: http://www.w3.org/TR/REC-xml-names [64] RDF in Mozilla: http://www.mozilla.org/rdf/doc/ [65] mozilla.org: http://www.mozilla.org/ [66] Open Directory Project: http://dmoz.org/ [67] Open Directory RDF dumps: http://dmoz.org/rdf.html [68] Guidance on expressing the Dublin Core within the Resource Description Framework (RDF): http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/ [69] DublinCore Namespace: http://purl.org/dc/elements/1.0/ [70] DublinCore Qualifier Namespace: http://purl.org/dc/qualifiers/1.0/ [71] DublinCore Terms Namespace: http://purl.org/dc/terms/1.0/

31

Index LotusXSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 TEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Metadaten. . . . . . . . . . . . . . . . . . . . . . . .14, 18, 23 MONARCH . . . . . . . . . . . . . . . . . . . . . . 14, 17, 21 Mozilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Adobe Acrobat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Acrobat Distiller . . . . . . . . . . . . . . . . . . . . 14 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 XML Project . . . . . . . . . . . . . . . . . . . . . . . . 12 Archiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 ASCII-Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Oasis Open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 OCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 OCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Open Catalog Format . . . . . . . . . . . . . . . . . . . . 11 Open Catalog Protocol . . . . . . . . . . . . . . . . . . 11 Open Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Browser-Wars . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 15 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 PGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Portable Dokument Format . . . . . . . . . . . . . . 14 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 PostScript . . . . . . . . . . . . . . . . . . . . . . . . 11, 14, 15 Preprozessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7, 10 CPAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7, 10 dmoz.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 DocBook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 DocBook XML . . . . . . . . . . . . . . . . . . . . . . . 16, 17 Document Type Description . . . . . . . . . . . . . . 7 Dokumentenstruktur . . . . . . . . . . . . . . . . . . . . . 17 DSSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7, 13 DublinCore . . . . . . . . . . . . . . . . . . . 18, 21, 23, 25 Namensraum . . . . . . . . . . . . . . . . . . . . . . . . 24 Qualifier Namensraum. . . . . . . . . . . . . . .24 Terms Namensraum . . . . . . . . . . . . . . . . . 24 Dublincore Qualified . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 DVI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20, 22, 23 Model and Syntax Specification . . . . . 21 root-Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 SGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 SOIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 21, 25 Standard Generalized Markup Language . . 5 strukturiere Suche . . . . . . . . . . . . . . . . . . . . . . . 17 Stylesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 16 Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 TEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Text Encoding Initiative . . . . . . . . . . . . . . . . . 11 TU Chemnitz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

E-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Encyclopaedia Britannica . . . . . . . . . . . . . . . . 12 eXcelon Stylus . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 eXtensible Markup Language . . . . . . . . . . . . . 5

Universit¨atsbibliothek . . . . . . . . . . . . . . . . . . . . 14 Universit¨atsrechenzentrum . . . . . . . . . . . . . . . 14

GhostScript. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 glimpse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

vcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Visitenkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Volltext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Indizierung . . . . . . . . . . . . . . . . . . 15, 17, 18 Recherche . . . . . . . . . . . . . . . . 14, 15, 17, 18

HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14–16 Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 HTML-Dokument. . . . . . . . . . . . . . . . . . . . . . . .15 IBM XSL Editor . . . . . . . . . . . . . . . . . . . . . . . . . 10

WWW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 WWW-Browser . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 10 Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7, 10

XALAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 XInclude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 XLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 15, 18 Anwendungen . . . . . . . . . . . . . . . . . . . . . . . 10

KIllustrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 KOffice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 32

Dokument . . . . . . . . . . . . . . . . . 7, 12, 16, 17 g¨ ultig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 standalone . . . . . . . . . . . . . . . . . . . . . . . . . 6 wohlgeformt . . . . . . . . . . . . . . . . . . . . . . . . 6 Inclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8, 13 Linking Language . . . . . . . . . . . . . . . . . 8, 13 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 8, 13 Structures. . . . . . . . . . . . . . . . . . . . . . . . . .8 working draft . . . . . . . . . . . . . . . . . . . . . . 8 Working Group . . . . . . . . . . . . . . . . . . . . 8 Stylesheet Language . . . . . . . . . . . . . . . . . . 9 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . 18 XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . 11 XML-Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . 5 XML.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 XML::Parser . . . . . . . . . . . . . . . . . . . . . . . . . . 7, 10 XMLWriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 XSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9, 12 formatting objects . . . . . . . . . . . . . . . . . . . 10 Stylesheet . . . . . . . . . . . . . . . . . . . . . . . 10, 12 Transformations . . . . . . . . . . . . . . . . . . . . . . 9 xslj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

33