formal implementation of the 1dok meta data model

Our plan to describe the 1dok meta data model with the help of a schema, produced some interesting insights increasing the results of our work by some aspects.
We soon found out among other things that for the description of meta data with the Resource Description Framework (RDF) [RDF99], an XML-based language is already defined, published as a recommendation by the W3C and therefore having achieved the state of a normative standard.
RDF offers an unambiguous notation allowing objects to be described by properties ascribed to them.

To use this technology for the description of the meta informations about 1dok documents suggested itself since its aim and our project´s is the same: to provide items of information on (web) resources (in our case digital documents) in a way that arbitrary software applications, as web agents e.g., may process these automatically as far as possible [Be98].

We propose an RDF-schema (RDFS) [RDFS03] here which, as an example for the case "formless letter", gives glossaries in different stages of specialization based on each other and which formally describes the derivation relations between the different document classes and their respective properties.
Due to RDFS, this may be developed further at will without need of central coordination.

But it is not possible to describe the basic principle of the 1dok meta data model, that is the creation of a stepwise extensible canon, obligatory at each step of predefinition, by the RDF-schema alone. The formal possibility to prescribe obligatory contents determined by parent document classes is missing.
What is needed therefore, is an XML-schema [XMLS01] predefining structural restrictions parallel to the RDF-schema describing the meta data semantically. With the help of the XML-schema, the validity of a 1dok document could be guaranteed at any time, also with regard to the presence and the consistency of obligatory or optional attributes.

It appeared that the unrestricted extensibility of the 1dok meta data model may not be limited to the derivation of the document classes but has to include their attributes as well.
Whereas we predefined the attributes name, postcode, town, street and house number as obligatory address information in our exemplary case of a letter, a big organization might want to add e.g. department designations or reference codes for persons in charge to the address items.
Here also, the application of a derivation mechanism proves to be sensible since it guarantees that attributes, too, may be completed by sub attributes without retroactive damaging effects, that is the completion would be absent of reaction.
The property "absent of reaction" means that an attribute as an instance of a class "B" may be processed by an application even though this application was originally implemented for the processing of the attribute as an instance of the class "A", supposed class "B" being derived from class "A".

Proceeding from once predefined basic contents, each attribute must be structured in such a way that it would be flexibly extensible by derivation. We achieve this by using simple data types neither for properties in the XML-schema nor in the RDF-schema, because they cannot be extended by further properties in an absent-of-reaction way (as defined by us).

For a given document class, it is therefore possible to design a first draft of a canon, able to be subsequently developed further by derivation, both on the level of the according document class and on the level of its attributes. If a document class is derived accordingly, this happens without affecting the processing of documents based on lower versions (parent classes) and having emerged in the meantime. Vice versa, the document class may also be processed by applications conceived for the processing of the parent document classes. Both ways form fundamental preconditions to make an exchange of digital documents as smooth as possible within arbitrary communication situations.

With the "formless letter" as an example, we worked out a first draft which can be extended by the specializations DOMEA-administration paper or business letter, as described in the 1dok meta data model. We offer the community this draft for application as a well-tried canon borrowed from the real world.

We made our 1dok basic document agree with the widespread Dublin Core contents (DC) [DC] so that 1dok documents may be processed immediately by the help of agents or applications that are in conformity with DC.

To describe personal data in our example, we resort to the vCard schema [vCard01] published by the W3C.

With that, it is obvious that the 1dok meta data model requires only minimal predefinitions with regard to content, but is able to describe existent standards with reference to their contents (as e.g. EDI to describe invoices, delivery notes, offers etc.).

thanks

The high level state of the technical accomplishment within the 1dok.org project is due to the energetic specialistic support of the following persons, who we want to thank here very much:

	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

hint: Why XML-schema and not DTD?

Unlike DTDs, the XML-schema standard, stable since May 2001, supports productive structuring mechanisms, with the help of which element types can be derived from each other. Those mechanisms form preconditions to describe the derivation structure of the 1dok meta data model.