iiRDS-Metadaten, aber richtig!

Nun ist das erste iiRDS-Paket geschnürt. Es fehlt nur noch der Upload in das Content Delivery Portal (CDP). Dann, Abbruch, kryptische Fehlermeldung! Was ist hier los? Soll der Austauschstandard iiRDS nicht alles einfacher machen?

Wer seine ersten Gehversuche in iiRDS macht, der baut oft seine ersten iiRDS-Pakete von Hand. Oder reichert mit dem iiRDS-Open-Toolkit erstellte Pakete weiter mit eigenen Metadaten an. Oftmals folgt danach die Enttäuschung. Irgendetwas stimmt nicht. Das Paket lässt sich nicht in das CDP importieren. Ist das Paket falsch oder hat der Hersteller des CDP zu viel versprochen und kann kein iiRDS? Um diese Unsicherheit zu beseitigen, kann eine erste einfache Validierung des iiRDS-Pakets Abhilfe schaffen.

Validierung, aber was?

Die Validierung eines iiRDS-Pakets hat mehrere Dimensionen. Der Standard definiert ja ein Paketformat und ein Vokabular an Metadaten. Diesen zwei Dimensionen entsprechend muss ein Paket also nach folgenden Gesichtspunkten validiert werden:

• Paket mit Ordnerstruktur, Dateiformaten und verpflichtenden Dateien für Mime Type und Metadaten
• Metadaten in RDF

Dieser Beitrag befasst sich mit dem zweiten Punkt, der einfachen Validierung der Metadaten-Datei in RDF. Auch die Validierung der Metadaten-Datei selbst hat wieder mehrere Dimensionen. Da die Spezifikation als Serialisierung zur Zeit nur RDF/XML unterstützt, muss das XML entsprechend der syntaktischen Vorgaben des XML-Standards validiert werden. Dann folgt die Überprüfung der RDF-Syntax und als letzter Punkt die Validierung unter iiRDS-Gesichtspunkten. Entsprechend dieser Dimensionen kann die Validierung der Metadaten-Datei mit unterschiedlichen technischen Mitteln umgesetzt werden:

1. Wohlgeformtheit des XML mit XML-Tool prüfen
2. RDF-Syntax mit semantischem Tool und optional einem Reasoner prüfen
3. iiRDS-Regeln zu Kardinalitäten der Beziehungen mit semantischem Tool und SHACL-Regeln prüfen

Mein XML, so wohlgeformt!

Werden in ein bestehendes iiRDS-Paket Metadaten von Hand ergänzt oder die Metadaten-Dateien von Grund auf neu gebaut, so ist es nicht unwahrscheinlich, dass sich Fehler einschleichen. iiRDS ist als Austauschformat nicht dafür angelegt, von Hand erzeugt zu werden, auch wenn es für geübte Hände durchaus möglich ist. Aber wer ist schon geübt, bei den ersten Gehversuchen in iiRDS?

Da iiRDS als Serialisierung RDF/XML vorschreibt, muss also erst einmal ausgeschlossen werden, dass sich einfache XML-Fehler eingeschlichen haben. Da wir nicht gegen eine DTD prüfen, gilt es bei der XML-Prüfung auf die Wohlgeformtheit zu achten. Zum Beispiel müssen alle ergänzten Elemente ein öffnendes und schließendes XML-Tag haben. Dabei ist Groß- und Kleinschreibung zu beachten. Eine häufige Fehlerquelle sind hierbei die Directory-Node-Strukturen, die oft ergänzt werden, um ein Inhaltsverzeichnis zu erstellen. Um hier Fehler zu vermeiden, lohnt sich ein Blick in die iiRDS-Spezifikation. Oft kann einfach ein passendes Beispiel kopiert und etwas angepasst werden.

Um Fehler zu finden, können alle gängigen XML-Tools verwendet werden. Eine kostenlose Option sind Texteditoren mit entsprechenden XML-Plugins. So lassen sich zum Beispiel mit dem Editor Atom und dem XML-Plugin linter-autocomplete-jing XML-Dateien beim Bearbeiten auf Wohlgeformtheit prüfen. Auch prima ist Notepad++ mit dem Plugin XML Tools.

RDF-Syntax, wtf?

Wenn die Metadaten-Datei ein gültiges XML enthält, sind wir schonmal auf einem guten Weg. Als nächstes müssen wir sicherstellen, dass das XML auch ein gültiges RDF ist. Eine sehr einfache Form der Validierung ist der RDF-Validator des W3C-Konsortiums. Der RDF-Validator zeigt auch Fehler im XML-Format an, allerdings geht die eigentliche Fehlerquelle in einer Vielzahl an Fehlermeldungen zu Folgefehlern unter. Fehler im RDF werden hingegen recht schlüssig aufgezeigt.

Darf der Inhalt der Datei aus Datenschutzgründen nicht online überprüft werden, kann ein semantisches Framework für eine lokale Prüfung verwendet werden. So bietet das Framework Apache Jena die Möglichkeit, über die Kommandozeile eine Metadaten-Datei zu validieren. Wir wollen dafür aus dem Jena-Framework das Kommandozeilen-Tool riot verwenden. Mit folgendem Aufruf kann eine Metadaten-Datei in RDF geprüft werden:

java -cp „C:\\Apache-Jena\lib\*“ riotcmd.riot –validate „C://package/metadata.rdf“

Eine weitere Option der RDF-Validierung ist es, die Metadaten-Datei in einem semantischen Tool zu öffnen. Zum Beispiel kann Protégé Fehler im RDF anzeigen. Allerdings ist die Verwendung von Protégé eher etwas für geübte Nutzer. Da Protégé eigentlich für die Bearbeitung von Ontologien in OWL entwickelt wurde, interpretiert es das RDF unserer Metadaten-Datei unter OWL-Gesichtspunkten und erzeugt Artefakte, die unsere Fehlersuche erschweren können.

iiRDS und SHACL, Schluss mit lustig!

Haben wir XML-Syntax und RDF überprüft, stellt sich die Frage, wie die Konformität der Metadaten-Datei mit dem iiRDS-Standard geprüft werden kann. Die iiRDS-Spezifikation legt zum Beispiel fest, welche Beziehungen eine Instanz einer Klasse haben kann und wie häufig es diese Beziehung hat. Diese Kardinalitäten sind aber nur in textueller Form in der Spezifikation und als Beschreibungen in dem iiRDS-RDF enthalten. Daher ist eine automatische Validierung dieser iiRDS-spezifischen Business-Rules nicht einfach möglich.

Um solche Beziehungen und Pfade aus semantischen Tripeln zu prüfen, bietet sich eine spezielle Sprache an. Die Shape Constraint Language (SHACL) kann Regeln formulieren, die semantische Beziehungen erfüllen müssen. Das iiRDS-Konsortium verfügt über ein Set an SHACL-Regeln, um Kardinalitäten zu prüfen.

Folgendes Beispiel illustriert eine SHACL-Regel für einen Kardinalitäten-Check:

<sh:NodeShape xmlns:sh=“http://www.w3.org/ns/shacl#“
                 rdf:about=“http://iirds.tekom.de/iirds#DirectoryNode“>
      <rdfs:subClassOf xmlns:rdfs=“http://www.w3.org/2000/01/rdf-schema#“
                       rdf:resource=“http://www.w3.org/2000/01/rdf-schema#Resource“/>
      <rdfs:label xmlns:rdfs=“http://www.w3.org/2000/01/rdf-schema#“/>
      <rdf:type rdf:resource=“http://www.w3.org/2000/01/rdf-schema#Class“/>
      <sh:property>
         <sh:PropertyShape>
            <sh:description>iirds:has-directory-structure-type Cardinality: http://iirds.tekom.de/iirds#DirectoryNode [0..1]</sh:description>
            <sh:name>iirds:has-directory-structure-type</sh:name>
            <sh:path rdf:resource=“http://iirds.tekom.de/iirds#has-directory-structure-type“/>
            <sh:node rdf:resource=“http://iirds.tekom.de/iirds#DirectoryNodeType“/>
            <sh:minCount rdf:datatype=“http://www.w3.org/2001/XMLSchema#integer“>0</sh:minCount>
            <sh:maxCount rdf:datatype=“http://www.w3.org/2001/XMLSchema#integer“>1</sh:maxCount>
         </sh:PropertyShape>
      </sh:property>
   </sh:NodeShape>

Diese SHACL-Regeln sind für Konsortiumsmitglieder verfügbar, aber das hilft uns bei den ersten Schritten mit iiRDS natürlich nicht weiter. Uns hilft nur ein gründliches Lesen der Spezifikation, um sicher zu sein, dass wir keine Fehler im Paket haben, die auf mangelnde iiRDS-Konformität zurückzuführen sind. Sind wir sicher, dass wir keine XML- und RDF-Syntaxfehler in der Metadaten-Datei haben, bleibt uns bei weiteren Upload-Problemen nur das Gespräch mit dem Hersteller des verarbeitenden Systems. Gemeinsam lässt sich dann hoffentlich der Fehler finden.

Schöne Metadaten, alles gut?

Nachdem wir uns nun verschiedene technische Möglichkeiten der Validierung von Metadaten angeschaut haben, sind wir dann auf der sicheren Seite? Leider ist die Antwort darauf nicht einfach. Denn selbst wenn wir technisch die Syntax prüfen und die Vereinbarkeit unserer Metadaten mit den Angaben im Standard zu iiRDS und den Kardinalitäten geprüft haben, bleiben weitere Fehlerquellen.

Ein iiRDS-Paket wird durch das Zusammenspiel von Paketformat und Metadaten zu einem mächtigen Austauschformat für Technische Dokumentation. Aber dieses Zusammenspiel haben wir bisher noch nicht betrachtet. Sind die in den Metadaten referenzierten Dateien wirklich vorhanden? Passen die Angaben in den Metadaten zu den tatsächlichen Dateiformaten? Das sind Fragen, die sich auch technisch prüfen und beantworten lassen, aber nicht im Rahmen einer einfachen Validierung. Darüber hinaus können Fehler auch in der falschen Verwendung und Zuweisung von Metadaten begründet liegen. Eine solche Validierung ist in letzter Instanz nur redaktionell möglich.

Trotz aller Einschränkungen lassen sich durch die einfachen ersten Prüfungen, die wir in diesem Beitrag gesehen haben, sehr viele Fehler vermeiden. Hoffentlich klappt’s dann auch mit dem Upload in das CDP der Wahl.

Weitere spannende Inhalte zum Thema iiRDS finden Sie im iiBlog und in unserer iiRDS-Playlist. 

Sie brauchen iiRDS-Support? Erfahren Sie mehr über unsere iiRDS-Services.