Weiterführende Informationen zum Aufbau von MyCoRe-Anwendungen

In diesem Abschnitt wird der Syntax der einzelnen XML-Daten-Dateien und der MyCoRe-Standard-Datentypen näher beschrieben. Die Kenntnis des Syntax benötigen Sie um eigene Datensätze für Ihren Dokumenten-Server zu erstellen. Eine umfassende Beschreibung der zugehörigen Klassen finden Sie im Programmer Guide. In den folgenden Abschnitten wird lediglich auf die XML-Syntax der Daten eingegangen.

Die MCRObjectID

Die Identifikation eines jeden MyCoRe Objektes erfolgt grundsätzlich über eine eindeutige ID. Die ID kann per Hand vergeben oder auch automatisch via API generiert werden. Diese hat für alle Objekte einen einheitlichen Aufbau, dessen Inhalt für jedes Projekt und jeden Datentyp festzulegen ist:

ID = “projektkürzel_type_nummer”

Tabelle 8.1: Aufbau der MCRObjectID

Im MyCoRe-Projekt sind zwei MCRObjectID-Typnamen reserviert und dürfen nicht für anderweitige Objekte genutzt werden. Der Typ class steht für Klassifikationen, der Typ derivate wird für Multimediaobjekte verwendet.

Es sei noch einmal ausdrücklich darauf hingewiesen, das die MCRObjectID eine zentrale Rolle im ganzen MyCoRe-Projekt spielt. Über sie werden alle Daten identifiziert und referenziert. Es sind daher die vorgegebenen Regeln streng einzuhalten. Da es derzeit für den Datentyp zum anhängen nur eine type-Bezeichnung gibt, kann es beim Design eines Projektes hilfreich sein, sich für eine Gruppe von Projektkürzeln zu entscheiden, z. B. DOLAuthor_author_..., DOLDocument_document_... usw. So kann jedem Datenmodell eine dedizierte Derivate-Gruppe zugeordnet werden z. B. DOLAuthor_derivate_... oder DOLDocument_derivate_.... Diese Trennung ist nicht zwingend, hat sich aber bei der Verwaltung großer Datenmengen als günstig erwiesen. Manchmal ist es sogar sinnvoll, hierzu noch mehrere Projektkürzel für ein Datenmodell zu verwenden, je nach Umfang des Datenbestandes und der Sicherungs- und Reparatur-Strategien des Projektes.

Das Klassifikationen-Datenmodell

Wie bereits erwähnt dienen Klassifikationen der einheitlichen Gliederung bestimmter Fakten. Sie sorgen dafür, dass eine einheitliche Schreibweise für bestimmte Begriffe verwendet wird. Diese Einzelbegriffe werden als Kategorien bezeichnet. Innerhalb einer Kategorie kann der Begriff in verschiedenen Sprachen aufgezeichnet sein. Die eindeutige Zuordnung zu einer Kategorie erfolgt über einen Bezeichner. Dieser besteht aus der Klassifikations- und Kategorie-ID und muss eindeutig sein.

Klassifikationen werden im DocPortal als extra XML-Datei erstellt, in die Anwendung importiert und in Form einer Datenbank gespeichert. Dies ist für den Nutzer transparent und erfolgt mittels Schnittstellen. Der Zugriff auf die Daten erfolgt dann durch den oben genannten Bezeichner. Die Klassifikations-ID ist eine MCRObjectID mit dem Typ class. Die Kategorie-ID ist dagegen frei wählbar. Sie darf mehrstufig sein, jede Stufe spiegelt eine Hierarchieebene wieder. Die Stufen in der ID werden mit einem Punkt voneinander getrennt, ’Uni.URZ’. Das wiederum gestattet eine Abfrage nach allen untergeordneten Stufen bzw. Sub-Kategorien wie ’Uni.*’.

Im ID Attribut einer category ist der eindeutige Bezeichner anzugeben. Das darunter befindliche label Tag bietet die Möglichkeit, eine Kurzbezeichnung anzugeben. Mehrsprachige Ausführungen sind erlaubt. Dasselbe gilt für das Tag description. Beide Werte werden als Strings aufgefasst. Eine category kann wiederum category Tags beinhalten.

<?xml version="1.0" encoding="UTF-8" ?>
    <mycoreclass
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="MCRClassification.xsd"
      xmlns:xlink="http://www.w3.org/1999/xlink"
      ID="..." >
     <label xml:lang="..." text="..." description="..."/>
     ...
     <categories>
      <category ID="...">
         <label xml:lang="..." text="..." description="..."/>
         ...
         <category ID="...">
           <label xml:lang="..." text="..." description="..."/>
           ...
         </category>
         <category ID="...">
           <label xml:lang="..." text="..." description="..."/>
           ...
         </category>
       </category>
     </category>
   </categories>
</mycoreclass>

Das Metadatenmodell

Die zu speichernden Daten des Beispiels teilen sich in unserem Modell in Metadaten und digitale Objekte. Dies gilt auch für die vom Anwender entwickelten Applikationen. Digitale Objekte sind Gegenstand des Abschnitts ’IFS und Content Store’. Unter Metadaten verstehen wir in MyCoRe alle beschreibenden Daten des Objektes, die extern hinzugefügt, separat gespeichert und gesucht werden können. Dem gegenüber stehen Daten welche die digitalen Objekte selbst mitbringen. 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. Zum Verständnis der MyCoRe-Beispielanwendung sei hier auch auf den vorigen Abschnitt verwiesen. Die Metadaten werden komplett in XML erfasst und verarbeitet. Für die Grundstrukturen und Standardmetadatentypen werden seitens MyCoRe bereits XMLSchema-Dateien mitgeliefert.

XML-Syntax eines Metadatenobjektes

<?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!

Syntax 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 einen Aufbau wie für MCRMetaLinkID beschrieben.

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. Siehe auch Programmer Guide, Abschnitt Vererbung. Die Werte für xlink:title und xlink:label werden beim Laden der Daten automatisch ergänzt.

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 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 Datenobjekt vom Typ mycorederivate, wie es im nachfolgenden Abschnitt ’IFS und Content Store’ näher erläutert ist.

<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>

Syntax 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 (siehe dazu MyCoRe Programmer Guide).

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. Die mit der Vererbung verbundenen Mechanismen sind in dieser Dokumentation weiter hinten beschrieben.

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 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. Die Liste der aktuell unterstützten Sprach-Codes entnehmen Sie bitte der Java-Quelldatei

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). Diese Information ist für die Datenpräsentation sehr hilfreich.

<metadata xml:lang="...">
  <... class="MCRMeta..." heritabel="...">
   ...
  </...>
  ...
</metadata>

Für das MyCoRe-Beispiel mit einem Dublin Core 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.

MyCoRe Metadaten-Basistypen

In MyCoRe gibt es eine Reihe von vordefinierten XML-Datenstrukturen zur Abbildung bestimmter mehr oder minder komplexer Daten. Diese Strukturen bilden die MyCoRe-Datentypen, welche von der Dateneingabe bis hin zur Validierung und Datenpräsentation für einen einheitlichen Umgang mit den Daten sorgen. Dabei ist zwischen einfachen, recht atomaren Typen und anwendungsspezifischen komplexen Typen zu unterscheiden. Eine Auflistung finden Sie in nachfolgender Tabelle.

Tabelle 8.2: MyCoRe-Basisdatentypen

Syntax des Metadatentyps MCRMetaAccessRule

Der Basistyp MCRMetaAccessRule ist für den Import/Export von Access Control Lists (ACL's) gedacht. Der Metadatentyp stellt einen Container für die entsprechenden Access-Conditions dar und wird nur im MCRService-Teil verwendet.

<servacls class="MCRMetaAccessRule">
  <servacl permission="...">
    <condition format="xml">
     ...
    </condition>
  </servacl>
</servacls>

<servacls class="MCRMetaAccessRule">
  <servacl permission="read">
    <condition format="xml">
      <boolean operator="and">
        <!-- USER OR GROUP -->
      <boolean operator="or" />
        <!-- DATE -->
      <boolean operator="and" />
        <!-- IP -->
      <boolean operator="or" />
        <!-- -->
      </boolean>
    </condition>
  </servacl>
</servacls>

Syntax des Metadatentyps MCRMetaAddress

Der Basistyp MCRMetaAddress beinhaltet eine Liste von postalischen Anschriften in der Ausprägung eines XML-Abschnittes. Dabei wird berücksichtigt, dass die Anschrift in verschiedenen Sprachen und in international gängigen Formen gespeichert werden soll. Die einzelnen Subtags sind dabei selbsterklärend. Die Angaben zu type und xml:lang sind optional, ebenso die unter subtag liegenden Tags, jedoch muss mindestens eines ausgefüllt sein. Alle Werte werden als Text betrachtet.

Syntax des Metadatentyps MCRMetaAddress:

<tag class="MCRMetaAddress">
  <subtag type="..." xml:lang="...">
    <country>...</country>
    <state>...</state&gt;
    <zipcode>...</zipcode>
    <city>...</city>
    <street>...</street>
    <number>...</number>
  </subtab>
  ...
</tag>

Beispiel des Metadatentyps MCRMetaAddress:

<addresses class="MCRMetaAddress">
  <address type="Work" xml:lang="de">
    <country>Deutschland</country>
    <state>Sachsen</state>
    <zipcode>04109</zipcode>
    <city>Leipzig</city>
    <street>Augustuspaltz</street>
    <number>10/11</number>
  </address>
  ...
</addresses>

Syntax des Metadatentyps MCRMetaBoolean

Der Basistyp MCRMetaBoolean beinhaltet eine Liste von Wahrheitswerten mit zugehörigen type Attributen. Folgende Werte sind zulässig:

• für true - ’true’, ’yes’, ’wahr’ und ’ja’
• für false - ’false’, ’no’, ’falsch’ und ’nein’

Syntax des Metadatentyps MCRMetaBoolean:

<tag class="MCRMetaBoolean">
  <subtag type="..." xml:lang="..." >
  ... 
  </subtab>
  ... 
</tag>

Beispiel des Metadatentyps MCRMetaBoolean:

<publishes class="MCRMetaBoolean">
  <publish type="Ausgabe_1" xml:lang="de">ja</publish>
  <publish type="Ausgabe_2" xml:lang="de">nein</publish>
  ...
</publishes>

Syntax des Metadaten-Basistyps MCRMetaClassification

Der Basistyp MCRMetaClassification dient der Einbindung von Klassifikationen und deren Kategorien in die Metadaten. Beide Identifizierer zusammen beschreiben einen Kategorieeintrag vollständig. Dabei ist für die categid eine, ggf. mehrstufige, Kategorie-ID einzutragen. Die classid muss vom Typ MCRObjectID sein. Bitte beachten Sie die Hinweise zur Gestaltung der Kategorie-IDs im vorigen Kapitel!

Syntax des Metadaten-Basistyps MCRMetaClassification:

<tag class="MCRMetaClassification">
  <subtag classid="..." categid="..."/>
  ... 
</tag>

Beispiel des Metadaten-Basistyps MCRMetaClassification:

<origins class="MCRMetaClassification" heritable="false">
  <origin classid="MyCoReDemoDC_class_1" categid="Unis.Leipzig.URZ"/>
  ...
</origins>

Syntax des Metadaten-Basistyps MCRMetaHistoryDate

Der Basistyps MCRMetaHistoryDate ist speziell kreiert, um Datumsangaben für historische Projekte speichern und suchen zu können. Dabei wird sowohl ein verbaler Text wie eine konkrete Datumskonvertierung mit dem dazugehörigen Kalender gespeichert. Das Datum wird im Format des angegebenen Kalenders abgelegt, auch für die Zeit vor Einführung des selben. Zur Implementierung des Datentyps wurde die frei verfügbare ICU-Library der Firma IBM genutzt. Sie bietet eine Reihe von Kalendern an, die so für diesen Datentyp nun verfügbar sind. Alle Datumsangaben werden zur internen Verarbeitung in MyCoRe in eine Julian Day Number, also eine fortlaufende Tageszahl, umgerechnet. Diese wird neben einer Lesbaren Form in dem Datentyp MCRMetaHistoryDate gespeichert.

Somit ist eine scharfe Datumssuche mit Hilfe der Integer-Daten möglich. Die Eingabe der Daten erfolgt nach den Regeln:

• Im text-Feld steht ein beliebiger String gemäß den Projektvorgaben
• Die Felder von und bis enthalten gregorianische Datumsangaben.
• Ist für von und/oder bis nichts angegeben, werden Standardwerte genommen. Das sind 1..1.4713 BC und 31.12.3999 AD.
• Die Felder ivon bzw. ibis enthalten die korrespondierenden Werte zu von bzw. bis.
• Das calendar-Feld kann die Werte gregorian oder islamic enthalten.
• Mögliche Notationen für die Datumsangaben sind 01.01.1999 / -01.12.200 / 1035 / 133 BC.

Syntax des Metadaten-Basistyps MCRMetaHistoryDate:

<tag class="MCRMetaHistoryDate" heritable="...">
  <subtag type="..." xml:lang="...">
    <text>...</text>
    <von>...</von>
    <ivon>...</ivon>
    <bis>...</bis>
    <ibis>...</ibis>
    <calendar>...</calendar>
  </subtab>
  ...
</tag>

Beispiel des Metadaten-Basistyps MCRMetaHistoryDate:

<date class="MCRMetaHistoryDate" heritable="...">
  <dates type="written" xml:lang="de">
    <text>4. Jh. v. Chr.</text>
    <von>BC01.01.399</von>
    <ivon>1575694</ivon>
    <bis>BC31.12.300</bis>
    <ibis>1830997</ibis>
    <calendar>gregorian</calendar>
  </dates>
</date>

Syntax des Metadatentyps MCRMetaInstitutionName

Der Basistyp MCRMetaInstitutionName beinhaltet eine Liste der Namen einer Firma oder Einrichtung oder eines Bereiches der selben. Dabei soll berücksichtigt werden, dass die Name in verschiedenen Sprachen und in international gängigen Formen gespeichert werden sollen. Über das Attribut type ist eine zusätzliche Differenzierung der verschiedenen Namen möglich.

• name beinhaltet den vollständigen Namen (Pflicht)
• nickname das Pseudonym (z. B. UBL) (optional)
• property den rechtlichen Stand, GmbH (optional

Syntax des Metadaten-Basistyps MCRMetaInstitutionName:

<tag class="MCRMetaInstitutionName" heritable="...">
  <subtag xml:lang="...">
    <fullname>...</fullname>
    <nickname>...</nickname>
    <property>...</property>
  </subtab>
  ...
</tag>

Beispiel des Metadaten-Basistyps MCRMetaInstitutionName:

<insts class="MCRMetaInstitutionName" heritable="...">
  <inst xml:lang="de">
    <fullname>Obelix &amp; Co. KG</fullname>
    <nickname>O. &amp;. Co.</nickname>
    <property>KG</property>
  </inst>
</insts>

Syntax des Metadatentyps MCRMetaISBN

Dieser Metadatentyp ist ganz speziell zur Speicherung einer ISBN gedacht. Er gestattet nur eine Kardinalität.

Syntax des Metadaten-Basistyps MCRMetaISBN:

<tag class="MCRMetaISBN" heritable="..."> 
  <subtag>ISBN</subtag>
</tag>

Syntax des Metadaten-Basistyps MCRMetaISBN:

<isbns class="MCRMetaISBN" heritable="..." >
  <isbn>1-234-56567-4</isbn>
</isbn>

Syntax des Metadatentyps MCRMetaISO8601Date

Dieser Metadatentyp ist wie MCRMetaDate für das Speichern von Zeitangaben gedacht. Er bietet jedoch eine höhere zeitliche Auflösung, bis in den Millisekundenbereich. Unterstützt werden alle Formate der Informationsseite des W3C (http://www.w3.org/TR/NOTE-datetime). Sie enthält nähere Informationen zu den Formaten und zur ISO-Norm:ISO 8601 : 1998 (E)

Wie MCRMetaDate unterstützt MCRMetaISO8601Date die Verwendung des type-Attributs, auf Grund seiner Sprachunabhängigkeit in der Formatierung der Datumsangabe fehlt die Unterstützung für das lang-Attribut. Das Verwenden von MCRMetaISO8601Date ermöglicht eine Syntaxprüfung der Datumsangabe bereits auf XMLSchema-Ebene, durch den dort definierten Datentyp xsd:duration, auf dem der MyCoRe-Datentyp abgebildet wird.

Optional kann ein format-Attribut verwendet werden. Dies erzwingt für das Datum das angegebene Format. So ist bei der Formatangabe „YYYY“ das Datum „2006-01“ ungültig. Ohne die Formatangabe hingegen ist das gleiche Datum gültig, weil es dem unterstützen Format „YYYY-MM“ entspricht.

Syntax des Metadaten-Basistyps MCRMetaISO8601Date:

<tag class="MCRMetaISO8601Date" heritable="...">
  <subtag type="..." format="...">YYYY-MM-DDThh:mm:ss.sTZD</subtag>
</tag>

Beispiel des Metadaten-Basistyps MCRMetaISO8601Date:

<dates class="MCRMetaISO8601Date" heritable="false">
  <date type="sample">2006-01-16T13:20:30.85+01:00</date>
</dates>

Syntax des Metadatentyps MCRMetaLangText

Der Basistyp MCRMetaLangText dient der Speicherung einer Liste von Textabschnitten mit zugehöriger Sprachangabe. Über das form Attribut kann noch spezifizier werden, in welcher Form der Text geschrieben ist.

XML-Syntax des Metadaten-Basistyps MCRMetaLangText:

<tag class="MCRMetaLangText" heritable="...">
  <subtag type="..." xml:lang="..." form="...">
    ...
  </subtab>
  ...
</tag>

Beispiel des Metadaten-Basistyps MCRMetaLangText:

<titles class="MCRMetaLangText" heritable="true">
  <title type="maintitle" xml:lang="de" form="plain">
    Mein Leben als MyCoRe-Entwickler
  </title>
</titles>

Syntax der Metadatentypen MCRMetaLink und MCRMetaLinkID

Der Basistyp MCRMetaLink wurde geschaffen, um eine Verknüpfung verschiedener MyCoRe-Objekte untereinander zu realisieren. Außerdem können hier genauso Verweise auf beliebige externe Referenzen abgelegt werden. Der Typ MCRMetaLink ist eine Implementation des W3C XLink Standards (siehe ’XLM Linking Language (XLink) Version 1.0’). Auf dieser Basis enthält der MyCoRe-Metadatentyp zwei Arten von Links - eine Referenz und einen bidirektionalen Link. Bei beiden werden jedoch in MCRMetaLink nicht alle Möglichkeiten der XLink Spezifikation ausgeschöpft, da dies für die in MyCoRe benötigten Funktionalitäten nicht erforderlich ist.

Im Referenztyp ist das Attribut xlink:type=’locator’ immer anzugeben. Die eigentliche Referenz wird im xlink:href Attribut notiert. Dabei kann die Referenz eine URL oder eine MCRObjectID sein. Daneben können noch weitere Informationen im xlink:label angegeben werden, die Rolle einer verlinkten Person. Der Referenztyp kommt im DocPortal bei der Verlinkung von Dokumenten und Personen zum Einsatz. Um den Update-Aufwand in Grenzen zu halten, wurde die genannte Verbindung als Referenz konzipiert. Somit weiß das referenzierte Objekt in der Beispielanwendung nichts über den Verweis.

Alternativ dazu besteht die Möglichkeit eines bidirektionalen Links. Dieser wird sowohl in der Link-Quelle wie auch im Link-Ziel eingetragen. Der Typ ist in diesem Fall xlink:type=’arc’. Weiterhin sind die Attribute xlink:from und xlink:to erforderlich. Optional kann noch ein Titel in xlink:title mitgegeben werden.

Der Basistyp MCRMetaLinkID entspricht im Aufbau dem MCRMetaLink. Der einzige Unterschied ist, dass die Attribute xlink:href, xlink:from und xlink:to nur mit MCRObjectIDs belegt werden dürfen.

XML-Syntax des Metadaten-Basistyps MCRMetaLink:

<tag class="MCRMetaLink" heritable="...">
  <subtag xlink:type="locator" xlink:href="..." xlink:label="..." xlink:title="..."/>
  <subtag xlink:type="arc" xlink:from="..." xlink:to="..." xlink:title="..."/>
  ...
</tag>

Beispiel des Metadaten-Basistyps MCRMetaLink:

<urls class="MCRMetaLink" heritable="false">
  <url xlink:type="locator" xlink:href="http://www.zoje.de" xlink:label="ZOJE"
       xlink:title="Eine externe URL"/>
  <url xlink:type="arc" xlink:from="mcr_object_id_1" xlink:to="mcr_object_id_2"
       xlink:title="Link zwischen Objekten"/>
</urls>

Syntax des Metadatentyps MCRMetaNBN

Diese Metadatentyp ist ganz speziell zur Speicherung einer NBN gedacht. Er gestattet nur eine Kardinalität.

Syntax des Metadaten-Basistyps MCRMetaNBN:

<tag class="MCRMetaNBN" heritable="...">
  <subtag>NBN</subtag>
</tag>

Beispiel des Metadaten-Basistyps MCRMetaNBN:

<nbns class="MCRMetaNBN" heritable="...">
  <nbn>urn:nbn:1-2334</nbn>
</nbns>

Syntax des Metadatentyps MCRMetaNumber

Der Basistyp MCRMetaNumber ermöglicht das Speichern und Suchen von Zahlenwerten. Die Zahlendarstellung kann je nach Sprache, d. h. im Deutschen mit Komma und im Englischen mit Punkt, angegeben werden. Weiterhin sind die zusätzlichen Attribute dimension und measurement möglich. Beide Attribute sind optional, ebenso wie das Default-Attribut type.

XML-Syntax des Metadaten-Basistyps MCRMetaNumber:

<tag class="MCRMetaNumber" heritable="...">
  <subtag xml:lang="..." dimension="..." mesurement="...">
    ...
  </subtag>
  ...
</tag>

Beispiel des Metadaten-Basistyps MCRMetaNumber:

<masse class="MCRMetaNumber" heritable="false">
   <mass xml:lang="de" dimension="Breite" mesurement="cm">12,1</mass>
   <mass xml:lang="en" type="neu" dimension="width" mesurement="ft">12.2</mass>
   ...
</masse>

Syntax des Metadatentyps MCRDerivateLink

Der Basistyp MCRDerivateLink ermöglicht

XML-Syntax des Metadaten-Basistyps MCRDerivateLink:

<tag class="MCRDerivateLink" heritable="...">
  <subtag xlink:type="..." xlink:href="..." xlink:title="...">
    ...
  </subtag>
  ...
</tag>

Beispiel des Metadaten-Basistyps MCRDerivateLink:

<def.derivateLink class="MCRMetaDerivateLink" heritable="false" notinherit="true">
  <derivateLink inherited="0" xlink:type="locator" xlink:href="HisBest_derivate_00000376/RN_0004_0001r.tif" xlink:title="HisBest_derivate_00000376/RN_0004_0001r.tif"/>
</def.derivateLink>

Subselect: <subselect id="sub.derivate" type="servlet" href="servlets/MCRDerivateLinkServlet" i18n="editor.search.choose.derivate" />

Syntax des Metadatentyps MCRMetaPersonName

Der Basistyp MCRMetaPerson beinhaltet eine Liste von Namen für natürliche Personen. Dabei wird berücksichtigt, dass die Namen in verschiedenen Sprachen und international gängigen Formen auftreten können. Das Attribut type dient der Differenzierung der verschiedenen Namen einer Person, Geburtsname, Synonym, Kosename usw. firstname repräsentiert den/die Vornamen, callname den Rufnamen, surname den Familiennamen, academic den akademischen Titel und peerage den Adelstitel und prefix Namenszusätze wie 'von', 'de' usw. fullname enthält nochmal den automatisch zusammengesetzten Namen.

XML-Syntax des Metadaten-Basistyps MCRMetaPersonName:

<tag class="MCRMetaPersonName" heritable="...">
  <subtag type="..." xml:lang="..">
    <firstname>...</firstname>
    <callname>...</callname>
    <surname>...<surname>
    <fullname>...</fullname>
    <academic>...</academic>
    <peerage>...</peerage>
    <prefix>...</prefix>
  </subtag>
  ...
</tag>

Beispiel des Metadaten-Basistyps MCRMetaPersonName:

<tag class="MCRMetaPersonName" heritable="true">
  <subtag type="geburtsname" xml:lang="de">
    <firstname>Lisa Marie</firstname>
    <callname>Lisa</callname>
    <surname>Schnell<surname>
    <fullname>Schnelle, Lisa</fullname>
  </subtag>
  <subtag type="familienname" xml:lang="de">
    <firstname>Lisa Marie</firstname>
    <callname>Lisa</callname>
    <surname>Schmidt<surname>
    <fullname>Dr. phil. Freifrau von Schnelle, Lisa</fullname>
    <academic>Dr. phil.</academic>
    <peerage>Freifrau</peerage>
    <prefix>von</prefix>
  </subtag>
  ...
</tag>

Syntax des Metadatentyps MCRMetaXML

Der Basistyp MCRMetaXML wurde zusätzlich als Container für einen beliebigen XML-Baum in das Projekt integriert. Dieser wird in den Textknoten des Subtags gestellt und kann dort theoretisch beliebig groß sein. Achten Sie aber darauf, dass entsprechend viel Speicherplatz in dem XML-SQL-Store vorgesehen wird.

XML-Syntax des Metadaten-Basistyps MCRMetaXML:

<tag class="MCRMetaXML" heritable="...">
  <subtag type="..." >
   ...
  </subtag>
  ...
</tag>
   

Beispiel für die Definition dieses Datentyps in der Datamodel-Datei:

<-- beliebiges XML-Objekt --> 
<element name="teixmls" minOccurs="0" maxOccurs="1">
  <mcrmetaxml name="teixml" class="MCRMetaXML" minOccurs="1" maxOccurs="1"/>
</element>

und ein Beispiel mit Metadaten zum Metadaten-Basistyp MCRMetaXML:

<teixmls class="MCRMetaXML"> 
  <teixml inherited="0">
    <TEI> 
      <teiHeader> 
        <title>
          Text Encoding Initiative, ein Dokumentenformat
          zur Kodierung und den Austausch von Texten
        </title> 
      </teiHeader> 
    </TEI> 
  </teixml> 
</teixmls>

Syntax 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 Flags 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. Eine genaue Beschreibung ist dem Kapitel über ACL's des MyCoRe Programmer Guide zu entnehmen.

Im servflags Teil können kurze Texte untergebracht werden. Die Anzahl der servflag Elemente ist theoretisch unbegrenzt.

Syntax des XML-Knotens service:

<service>
  <servdates class="MCRMetaISO8601Date">
    <servdate type="...">...</servdate>
    ...
  </servdates>
  <servacls class="MCRMetaAccessRule">
    <servacl permission="...">
    ...
    </servacl>
  </servacls>
  <servflags class="MCRMetaLangText">
    <servflag>...</servflag>
    ...
  </servflags>
</service>

Das Speichermodell für die Multimediadaten (IFS)

Im bisherigen Verlauf dieses Kapitels wurden nur die beschreibenden Daten des multimedialen Objektes erläutert. Dieser Abschnitt beschäftigt sich damit, wie die eigentlichen Objekte dem Gesamtsystem hinzugefügt werden können. Im MyCoRe Projekt wurde zur Ablage der digitalen Objekte das Konzept des IFS entwickelt. Hier ist es möglich, über spezielle Konfigurationen festzulegen, in welchen Speicher (Store) die einzelnen Dateien gespeichert werden sollen.

Das Laden von Objekten erfolgt mittels einer Metadaten-Datei, welche alle Informationen über die zu speichernde(n) Datei(en) und ihre Beziehung(en) zu den Metadaten enthält. Die zu speichernden multimedialen Objekte werden im Weiteren als Derivate, also Abkömmlinge, bezeichnet, da ein Objekt in mehreren Formen, Grafikformaten, auftreten kann. Die Struktur der XML-Datei für Derivate ist fest vorgegeben, alle Felder, die nutzerseitig geändert werden können, sind unten beschrieben.

Syntax des Derivate-Datenmodells:

<?xml version="1.0" cncoding="ISO-8859-1" ?>
  <mycorederivate
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="....xsd"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    ID="..."
    label="..."
  >    
    <derivate>
      <linkmetas class="MCRMetaLinkID">
        <linkmeta xlink:type="locator" xlink:href="..." />
      </linkmetas>
      <internals class="MCRMetaIFS">
        <internal sourcepath="..." maindoc="..."/>
      </internals>
    </derivate>
    <service>
      ...
    </service>
  </mycorederivate>

• Für xsi:noNamespaceSchemaLocation ist die entsprechende XML Schema-Datei anzugeben (Derivate.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.
• Die Referenz in linkmeta ist die MCRObjectID des Metadatensatzes, an den das/die Objekte angehängt werden sollen.
• Das Attribut sourcepath enthält die Pfadangabe zu einer Datei oder zu einem Verzeichnis, welches als Quelle dienen soll. Aus diesen Dateien kann nun eine Datei ausgewählt werden, welche den Einstiegspunkt bei HTML-Seiten darstellen soll. Bei einzelnen Bildern ist hier noch einmal der Dateiname anzugeben. Ist nichts angegeben, so wird versucht Dateien wie index.html usw. zu finden.