2021.06 2022.06

XML-Syntax eines MyCoRe-Objektes

In diesem Abschnitt wird der Syntax der einzelnen XML-Daten-Dateien näher beschrieben. Die Kenntnis des Syntax ist notwendig, um eigene Datensätze für zu erstellen.

Das Metadatenmodell

Die zu speichernden Daten einer Anwendung teilen sich in unserem Modell in Metadaten und digitale Objekte. Dies gilt auch für die vom Anwender entwickelten Applikationen. Unter Metadaten verstehen wir in MyCoRe alle beschreibenden Daten des Objektes, die außerhalb des eigentlichen digitalen Objektes existieren und separat hinzugefügt, separat gespeichert und gesucht werden können. Dem gegenüber stehen Daten welche die digitalen Objekte selbst mitbringen, wie z. B. EXIF-Daten. In diesem Abschnitt werden nur erstere behandelt.

Um die Metadaten besser auf unterschiedlichen Datenspeichern ablegen zu können, wurde ein System von XML-Strukturen entwickelt, das es gestattet, neben den eigentlichen Daten wie Titel, Autor usw. auch Struktur- und Service-Informationen mit abzulegen. Die eigentlichen Nutzerdaten sind wiederum typisiert, was deren speicherunabhängige Aufzeichnung erheblich vereinfacht. Es steht dem Entwickler einer Anwendung jedoch frei, hier bei Bedarf weitere hinzuzufügen. Im Folgenden soll nun der Aufbau der Metadatenobjekte im Detail beschrieben werden. Die Metadaten werden komplett in XML erfasst und verarbeitet. Für die Grundstrukturen und Standardmetadatentypen werden seitens MyCoRe bereits XML Schema-Dateien mitgeliefert. Die Modellierung eigener Datenmoelle innerhalb des metadata-Tags wird in einem gesonderten Abschnitt behandelt.

Aufbau eines MyCoRe-Objektes

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


<?xml version="1.0" encoding="UTF-8" ?>
<mycoreobject
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="....xsd"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    ID="..."
    label="..." >
 <structure>
 ...
 </structure>
 <metadata xml:lang="de">
 ...
 </metadata>
 <service>
 ...
 </service>
</mycoreobject>

Die oben gezeigte Syntax stellt den Rahmen eines jeden Metadaten-Objektes dar. Diese Struktur ist immer gleich und muss so eingehalten werden.

Für xsi:noNamespaceSchemaLocation ist das entsprechende XMLSchema-File des Metadatentyps anzugeben (document.xsd)
Die ID ist die eindeutige MCRObjectID.
Der label ist ein kurzer Text-String, der bei administrativen Arbeiten an der Datenbasis das Identifizieren einzelner Datensätze erleichtern soll. Er kann maximal 256 Zeichen lang sein.
Innerhalb der XML-Datenstruktur gibt es die Abschnitte structure, metadata und service zur Trennung von Struktur-, Beschreibungs- und Wartungsdaten. Diese Tag-Namen sind reserviert und dürfen NICHT anderweitig verwendet werden!

Aufbau des XML-Knotens structure

Im XML-Knoten structure sind alle Informationen über die Beziehung des Metadatenobjektes zu anderen Objekten abgelegt. Es werden derzeit die folgenden XML-Daten unter diesem Knoten abgelegt. Die Tag-Namen parents/parent, children/child und derobjects/derobject sind reserviert und dürfen NICHT anderweitig verwendet werden! Alle Sub-Knoten haben im LTS 2018.06 einen Aufbau wie für MCRMetaLinkID beschrieben. Mit LTS 2018.06 hat sich dies für das Tag derobjects geändert.

In parents wird ein Link zu einem Elternobjekt gespeichert, sofern das referenzierende Objekt Eltern hat. Ob dies der Fall ist, bestimmt die Anwendung. Das Tag dient der Gestaltung von Vererbungsbäumen und kann durch den Anwender festgelegt werden. Das Thema Vererbung wird gesondert an den entsprechenden Stellen beschrieben. Die Werte für xlink:title und xlink:label im parent -Objekt werden vom Anwender vorgegeben.

Die Informationen über die children hingegen werden durch das MyCoRe-System beim Laden der Daten automatisch erzeugt und dürfen nicht per Hand geändert werden, da sonst das Gesamtsystem nicht mehr konsistent ist. Werden die Metadaten eines Kindes oder eines Baumes von Kindern gelöscht, so wird in diesem Teil des XML-Knotens der Eintrag durch die Software entfernt.

Dasselbe gilt unter LTS 2018.06 auch für den XML-Unterknoten derobjects. In diesem Bereich werden alle Verweise auf die an das Metadatenobjekt angehängten digitalen Objekte gespeichert. Jeder Eintrag verweist mittels einer Referenz auf ein MyCoRe-Derivate.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<structure>
  <parents class="MCRMetaLinkID">
    <parent xlink:type="locator" xlink:href="...mcr_id..." />
  </parents>
  <children class="MCRMetaLinkID">
    <child xlink:type="locator" xlink:href="...mcr_id..." xlink:label="..." xlink:title="..." />
    ...
  </children>
  <derobjects class="MCRMetaLinkID">
    <derobject xlink:type="locator" xlink:href="...mcr_id..." xlink:label="..." xlink:title="..." />
    ...
  </derobjects>
</structure>

Ab LTS 2019.06 wurde der Abschnitt derobjects umstrukturiert. Für den Umstieg von LTS 2018.06 ist eine Datenmigration erforderlich! Jedes derobject ist nun vom Metadatentyp MCRMetaEnrichedLinkID. Dieses hat die folgenden Unterfelder:

order - Die Ordnungsnummer des Derivates im MCRObject.
maindoc - Die Startdatei für die Anzeige des Derivates.
title - Sprachabhängiger Titel des Derivates (wiederholbar).
classification - Klassifkationsreferenz zu Eigenschaften des Derivates (wiederholbar).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


<structure>
  <parents class="MCRMetaLinkID">
    <parent xlink:type="locator" xlink:href="...mcr_id..." />
  </parents>
  <children class="MCRMetaLinkID">
    <child xlink:type="locator" xlink:href="...mcr_id..." xlink:label="..." xlink:title="..." />
    ...
  </children>
  <derobjects class="MCRMetaEnrichedLinkID">
    <derobject xlink:type="locator" xlink:href="...mcr_id..." xlink:label="..." xlink:title="..." >
      <order>{number_of_derivate}</order>
      <maindoc>{main_file_name}</maindoc>
      <title xml:lang="{lang}">{title_lang}</title>
      ...
      <classification classid="{classid}" categid="categid}" />
      ...
    </derobject>
    ...
  </derobjects>
</structure>

Aufbau des XML-Knotens metadata

Der Abschnitt metadata des MyCoRe-Metadatenobjektes nimmt alle Beschreibungsdaten des eigentlichen Datenmodells auf. Diese werden ihrerseits in vordefinierten Datentyp-Strukturen mit festgelegter Syntax abgelegt. Die Liste der Einzelelemente und die Reihenfolge der Typen ist dabei quasi beliebig in Anordnung und Länge. Wichtig ist nur, dass alle Datentypen bestimmte gemeinsame Eigenschaften haben. Es ist auch jederzeit möglich, weitere Typen den Projekten der Anwender hinzuzufügen. Diese Definitionen sind analog der von MyCoRe mitgebrachten Vorlagen zu erstellen.

Die Metadaten bestehen aus einer Ansammlung von Informationen rund um das multimediale Objekt. Vorrangig wird dieser Teil in der Suche abgefragt. Jedes Metadatum (auch Metadaten-Tag) enthält im class Attribut den Namen des MCRMeta-Typs bzw. der gleichnamigen MCRMeta-Java Klasse. Daneben gibt es noch ein Attribut heritable, in dem festgelegt wird, ob diese Metadaten vererbbar sein sollen. Es sind jeweils die booleschen Werte true oder false möglich. Das Attribute notinherit legt die Eigenschaft eines Elements fest, von dem Parent-Element zu erben. Auch hier sind die booleschen Werte true oder false möglich. Ist heritable="true" und notinherit nicht angegeben, so wird implizit notinherit="false" angenommen.

Für MyCoRe wurden einige Basismetadatentypen festgelegt, mit denen die Mehrzahl der bisher in Betracht kommenden Anwendungen gelöst werden können. Die einzelnen Daten treten dabei als Liste auf, in denen mehrere Elemente des gleichen Typs erscheinen können, beispielsweise ein Titel in verschiedenen Sprachen. Jedes Listenelement hat wiederum per Default ein type Attribut und in allen sinnvollen Fällen eine gemäß W3C spezifizierte Sprache im Attribut xml:lang. Die Angabe der Sprache im Tag metadata ist für alle eingeschlossenen Metadatentypen der Default-Wert.

Für interne Zwecke wurde ein weiteres Attribut inherited eingeführt. Dieses ist NICHT durch den Anwender zu verändern! Es wird gesetzt, wenn das betreffende Metadatum von einem Elternteil geerbt wurde (siehe Vererbung) und gibt die Stufe der Vererbung an. Diese Information ist für die Datenpräsentation sehr hilfreich.

1
2
3
4
5
6


<metadata>
  <... class="MCRMeta..." heritable="..." notinherit="...">
   ...
  </...>
  ...
</metadata>

Für das MyCoRe-Beispiel mit einem MODS Datenmodell werden bereits einige Metadatentypen verwendet, welche dem MyCoRe-Kern beigefügt sind. Die Syntax der einzelnen Typen wird in den nachfolgenden Absätzen genau beschrieben.

Aufbau des XML-Knotens service

Für die Einrichtung eines Workflow und um die Wartung großer Datenmengen zu vereinfachen sowie für den Import / Export der ACL's, wurde der XML-Abschnitt service in das Metadatenobjekt integriert. Hier sind Informationen wie Datumsangaben, ACL's und Texte für die Verarbeitung im Batch-Betrieb enthalten. Achtung: die Tag-Namen sind fest vorgegeben und dürfen NICHT anderweitig verwendet werden!

Die Datumsangaben servdates verhalten sich analog zu denen in MCRMetaISO8601Date. Folgende Möglichkeiten für das Attribut type sind vorgesehen. Weitere Typen sind jedoch integrierbar.

acceptdate: Datum aus dem Dublin Core, kann frei verwendet werden.
createdate: Das Erzeugungsdatum des Objektes, dieser Wert wird automatisch beim Anlegen des Objektes erzeugt und bleibt immer erhalten!
modifydate: Das Datum des letzten Update, dieser Wert wird automatisch beim Update des Objektes erzeugt und bleibt immer erhalten!
submitdate: Datum aus dem Dublin Core, kann frei verwendet werden.
validfromdate: Datum aus dem Dublin Core, kann frei verwendet werden.
validtodate: Datum aus dem Dublin Core, kann frei verwendet werden.

Die servacls enthalten Access-Control-System-Conditions für die genutzten Permissions wie read, writedb oder deletedb. Dieses Element ist vor allem für den Import und Export relevant. Man kann mit einem CLI-Kommando Objekte mit ihren ACLs exportieren um sie zu sichern bzw. sie in ein anders System zu importieren. Wenn man die standardmässig aktivierte Vererbung bei den ACLs nutzt (indem man ACLs für den Dokumenttyp definiert), gibt es keine objektspezifischen ACLs.

Im servflags Teil können kurze Texte untergebracht werden. Hiermit können von der Anwendung Sachverhalte in textueller Form erfasst werden. Die Anzahl der servflag Elemente ist theoretisch unbegrenzt.

Im servmessages Teil können ebenfalls kurze Texte untergebracht werden. Im Gegensatz zu den servflags kann bei servmessages zusätzlich eine Datumsangabe erfasst werden. Hiermit können von der Anwendung Ereignisse in textueller Form protokolliert werden. Die Anzahl der servmessage Elemente ist theoretisch unbegrenzt.

Im servclasses Teil können beliebige Klassifikationswerte untergebracht werden. Hiermit können von der Anwendung Sachverhalte mit einem kontrolliertem Vokabular erfasst werden. Die Anzahl der servclass Elemente ist theoretisch unbegrenzt.

Der Abschnitt servstates kann dazu genutzt werden, den Status des MyCoRe-Objektes festzuhalten. Der Status muss dafür als Klassifikation hinterlegt sein. Die ID der Klassifikation kann dann über das Property MCR.Metadata.Service.State.Classification.ID (default ist state) angegeben werden. Welcher Status beim Erstellen eines Objektes standardmässig eingetragen wird, kann durch das Property MCR.Metadata.Service.State.Category.Default spezifiziert werden (default ist submitted). Ist keine Klassifikation vorhanden, wird <servstates /> nicht angelegt. Die State-Klassifikation kann heruntergeladen und dann importiert oder direkt über den folgenden CLI-Befehl geladen werden:

1

 load classification from url http://mycore.de/classifications/state.xml

Aufbau des XML-Knotens service:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


<service>
  <servdates class="MCRMetaISO8601Date">
    <servdate type="...">...</servdate>
    ...
  </servdates>
  <servacls class="MCRMetaAccessRule">
    <servacl permission="...">
    ...
    </servacl>
  </servacls>
  <servflags class="MCRMetaLangText">
    <servflag>...</servflag>
    ...
  </servflags>
  <servmessages class="MCRMetaDateLangText">
    <servmessag>...</servmessag>
    ...
  </servmessages>
  <servclasses class="MCRMetaClassification">
    <servclass>...</servclass>
    ...
  </servclasses>
  <servstates class="MCRMetaClassification">
    <servstate classid="..." categid="..." />
  </servstates>
</service>