Formale Beschreibung des 1dok-Metadatenmodells

Das Vorhaben, das 1dok Metadatenmodell mit Hilfe eines Schemas formal zu beschreiben, ergab einige interessante Erkenntnisse, die die Ergebnisse unserer Arbeit um einige Aspekte bereichert haben.
Unter anderem stellte sich schnell heraus, dass für die Beschreibung von Metadaten mit dem Resource Description Framework (RDF) [RDF99] bereits eine XML-basierte Sprache definiert ist, die bereits vom W3C als Empfehlung veröffentlicht wurde und damit den Status eines normativen Standard erreicht hat.
RDF bietet eine eindeutige Notation an, die die Beschreibung von Objekten durch ihnen zugeschriebene Eigenschaften ermöglicht.

Es war naheliegend, diese Technologie zur Beschreibung der Metainformationen über 1dok-Dokumente zu verwenden, verfolgt sie doch die gleichen Ziele wie unser Projekt: Bereitstellung von Informationen über (Web-) Ressourcen (in unserem Fall digitale Dokumente) in der Weise, dass beliebige Software-Applikationen, wie z.B. Web-Agenten diese weitestgehend automatisiert verarbeiten können [Be98].

Wir schlagen hier ein RDF-Schema (RDFS) [RDFS03] vor, das beispielhaft für den Anwendungsfall "formloses Anschreiben" in verschiedenen, aufeinander aufbauenden Spezialisierungsgraden Vokabulare angibt und formal die Ableitungsbeziehungen zwischen den verschiedenen Dokumentenklassen und deren jeweilige Eigenschaften beschreibt.
Dieses kann dank RDFS ohne die Notwendigkeit einer zentralen Koordinierung beliebig weiterentwickelt werden.

Das Grundprinzip des 1dok-Metadatenmodells, nämlich die Schaffung eines schrittweise erweiterbaren, aber auf jeder Stufe der Festlegung dann verbindlichen Kanons lässt sich durch das RDF-Schema alleine jedoch nicht abbilden. Es fehlt die formale Möglichkeit, Pflichtinhalte, die durch Elterndokumentenklassen vorgegeben sind, verbindlich vorzuschreiben.
Parallel zur semantischen Beschreibung der Metadaten über ein RDF-Schema bedarf es daher der Festlegung struktureller Restriktionen durch ein begleitendes XML-Schema [XMLS01]. Liegt dieses vor, kann jederzeit die Validität eines 1dok-Dokuments, auch in Hinblick auf das Vorhandensein und die Konsistenz von obligatorischen oder optionalen Attributen, sichergestellt werden.

Wie sich herausstellte, darf sich die uneingeschränkte Erweiterbarkeit des 1dok-Metadatenmodells nicht nur auf die Erbfolge der Dokumentenklassen beschränken, sondern muss auch deren Attribute einbeziehen.
Während wir beispielhaft für ein Anschreiben als Absenderinformationen die Attribute Vorname, Nachname, Straße und Hausnummer, Postleitzahl, Stadt, Land, Organisation und 1dok-URL als verbindlich festgelegt haben, kann für eine große Organisation die Notwendigkeit bestehen, die Absenderangaben um z.B. Abteilungsbezeichnungen und Kennzeichen für Sachbearbeiter zu ergänzen.
Auch hier erweist sich die Anwendung eines Vererbungsmechanismus als sinnvoll, da dieser sicherstellt, dass auch Attribute rückwirkungsfrei um weitere Unterattribute ergänzt werden können.
"Rückwirkungsfrei" bezeichnet hier die Eigenschaft, dass ein Attribut als Instanz einer Klasse "B" von einer Applikation verarbeitet werden kann, obwohl diese ursprünglich für die Verarbeitung dieses Attributs als Instanz der Klasse "A" implementiert wurde, vorausgesetzt dass die Klasse "B" von Klasse "A" abgeleitet ist.

Ausgehend von einmal festgelegten Basisinhalten muss jedes Attribut also so angelegt sein, dass es flexibel durch Vererbung erweiterbar ist. Dies erreichen wir dadurch, dass wir sowohl im RDF- als auch im XML-Schema einfache Datentypen für Attribute nicht verwenden, weil diese sich (in unserem Sinne) nicht rückwirkungsfrei um weitere Attribute erweitern lassen.

Auf diese Weise ist der erste Entwurf eines Kanons für eine gegebene Dokumentenklasse möglich, der nachträglich durch Vererbung sowohl auf der Ebene der betreffenden Dokumentenklasse als auch auf der Ebene seiner Attribute fortentwickelt werden kann. Wird eine Dokumentenklasse in diesem Sinne abgeleitet, kann dies geschehen, ohne dass dadurch die Verarbeitung zwischenzeitlich entstandener, auf niedrigeren Versionen (Elternklassen) beruhender Dokumente beeinträchtigt wird. Umgekehrt kann die neue Dokumentenklasse auch durch Applikationen verarbeitet werden, die für die Verarbeitung der Elterndokumentenklassen konzipiert sind. Beides sind wesentliche Grundvoraussetzungen für den möglichst reibungsfreien Austausch digitaler Dokumente in beliebigen Kommunikationsbeziehungen.

Einen ersten Entwurf haben wir exemplarisch mit dem "formlosen Anschreiben" fertiggestellt, der wie im Klassendiagramm des 1dok-Metadatenmodells gezeigt um die Spezialisierungen DOMEA-Verwaltungsschriftstück bzw. Geschäftsbrief erweitert werden kann. Diesen bieten wir der Community als einen der realen Welt entliehenen, altbewährten Kanon zur Verwendung an.

Unser 1dok-Basisdokument haben wir mit den weit verbreiteten Dublin Core-Inhalten (DC) [DC] zur Deckung gebracht, so dass 1dok-Dokumente sofort mit Hilfe von DC-konformen Agenten bzw. Applikationen verarbeitet werden können.

Zur Beschreibung von personenbezogenen Daten greifen wir in unserem Beispiel auf das vom W3C veröffentlichte vCard-Schema [vCard01] zurück.

Damit wird auch deutlich, dass das 1dok-Metadatenmodell inhaltlich nur minimale Festlegungen trifft, dafür aber in der Lage ist, bestehende Standards bezüglich ihrer Inhalte (wie z.B. EDI zur Beschreibung von Rechnungen, Lieferscheinen, Angeboten etc.) abzubilden.

Danksagung

Der gegenwärtige Stand der technische Ausarbeitungen im Rahmen des Projekts 1dok.org war möglich durch die tatkräftige fachliche Unterstützung folgender Personen, denen wir hiermit ausdrücklich unseren Dank aussprechen:

	Jeen Broekstra, aidministrator nederland
	James Michael DuPont, MCI Worldcom Deutschland GmbH
	Alexander Jerusalem, Vienna Knowledge Net
	Alexander Maedche, Forschungszentrum Informatik
	Henrik Oppermann, Professional Services, ontoprise GmbH
	Karsten Otto, Freie Universität Berlin, Fachbereich Mathematik und Informatik
	Roland Schwaenzl, Universität -Osnabrueck, Fachbereich Mathematik / Informatik
	Rigo Wenning, W3C

Links:

[Be98] Berners-Lee, Tim: Why RDF model is different from XML model, 1998,
http://www.w3.org/DesignIssues/RDF-XML.html
[RDF99] W3C Resource Description Framework (RDF);
http://www.w3c.org/RDF/
[RDFMS99] Resource Description Framework (RDF) Model and Syntax, 1999,
http://www.w3.org/TR/REC-rdf-syntax/
[RDFS03] RDF Vocabulary Description Language 1.0: RDF Schema; W3C Working Draft,
http://www.w3.org/TR/1998/WD-rdf-schema
[XMLS01] XML Schema Part 0: Primer, W3C Recommendation,
http://www.w3.org/TR/xmlschema-0/
[XML00] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation,
http://www.w3.org/TR/REC-xml
[vCard01] Representing vCard Objects in RDF/XML,
http://www.w3.org/TR/vcard-rdf
[DC] Dublin Core Metadata Initiative,
http://dublincore.org/
[Comparison] Markup Languages: Comparison and Examples,
http://trellis.semanticweb.org/expect/web/semanticweb/comparison.html
[Problemseminar] Problemseminar "Datenbankeinsatz im Internet", Resource Description Framework,
http://dbs.uni-leipzig.de/seminararbeiten/semSS99/arbeit5/Rdf.html

Hinweis: Warum XML-Schema und nicht DTD?

Im Gegensatz zu DTDs unterstützt der seit Mai 2001 stabile XML-Schema Standard leistungsfähige Strukturierungsmechanismen, mit denen Elementtypen voneinander abgeleitet werden können. Diese Mechanismen sind Voraussetzung für die Abbildung der Vererbungsstruktur des 1dok Metadatenmodells.