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.
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.
|
|
Die oben gezeigte Syntax stellt den Rahmen eines jeden Metadaten-Objektes dar. Diese Struktur ist immer gleich und muss so eingehalten werden.
xsi:noNamespaceSchemaLocation
ist das entsprechende XMLSchema-File des Metadatentyps anzugeben
(document.xsd)
ID
ist die eindeutige MCRObjectID.
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.
structure
, metadata
und service
zur Trennung von
Struktur-, Beschreibungs- und Wartungsdaten. Diese Tag-Namen sind reserviert und dürfen NICHT anderweitig
verwendet
werden!
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.
|
|
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).
|
|
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.
|
|
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.
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
createdate
modifydate
submitdate
validfromdate
validtodate
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:
|
|
Aufbau des XML-Knotens service:
|
|