Es gibt zwei Arten von Klassifikationsmapping, die im Folgenden erläutert werden.
Wenn Metadaten z.B. über die OAI-Schnittstelle an externe Services ausgeliefert werden sollen,
werden häufige andere Klassifikationseinträge benötigt.
Um Mehrfacheingaben zu vermeiden, bietet MyCoRe mit dem Klassifikationsmapping die Möglichkeit,
dass nur eine primäre Klassifikation erfasst werden muss.
MyCoRe ergänzt dann die äquivalenten Einträge der anderen Klassifikationen automatisch.
Für einen DINI-konformen Betrieb der OAI-Schnittstelle müssen verschiedene Sets unterstützt werden. Sets werden im OAI-PMH Standard verwendet, um Dokumente zu gruppieren. Sie ermöglichen selektives Harvesting und entsprechen konzeptionell den Klassifikationen in MyCoRe. Deshalb wurden zunächst Klassifikationen für die Sets erstellt, die für das DINI-Zertifikat zu implementieren sind. Sie stehen auf mycore.de/classifications als ddc.xml, diniPublType.xml und diniVersion.xml zur Verfügung und müssen in die eigene Anwendung übernommen werden.
Sollen Dokumente im xMetaDissPlus-Format ausgeliefert werden, sind weitere Klassifikationen zu verwenden: dctermsDCMIType.xml und XMetaDissPlusThesisLevel.xml
Im einfachsten Fall lassen sich diese Klassifikationen direkt in einem MyCoRe-Datenmodell verwenden. Allerdings werden die meisten MyCoRe-Anwendungen eigene Klassifikationen besitzen, z.B eine detaillierte DDC oder detailliertere Klassifikation für Dokumententypen. Für solche Fälle wurde das Klassifikationsmapping implementiert.
Es gibt Fälle, wo das klassische Klassifikationsmapping nicht ausreicht. Für ein erweitertes Mapping wird deswegen seit LTS 2023.06 das xPath-Mapping angeboten. Auch dieses alternative Mapping kann dazu benutzt werden, Fremdklassifikationen einer vorhanden Klassifikation zuzuordnen und doppelte Eingaben zu vermeiden. Dadurch, dass Zuordnungen in den Fremdklassifikationen durch xPath-Ausdrücke festgelegt werden, ist das Mapping flexibler in seiner Definition.
Die Definition des Mappings erfolgt, indem die Klassifikationseinträge um ein Label mit dem künstlichen
Sprach-Attribut
x-mapping
erweitert werden.
Als Wert wird Klassifikations-ID und Kategorie-ID getrennt durch einen Doppelpunkt dort
eingetragen.
Mehre Werte können durch Leerzeichen getrennt werden. z.B.:
|
|
Die Definition des Mappings erfolgt, indem die Klassifikationseinträge in der Zielklassifikation
um ein Label mit dem künstlichen Sprach-Attribut
x-mapping-xpath
erweitert werden.
Als Wert wird ein xPath-Ausdruck eingetragen. z.B.:
|
|
Es gibt weiterhin eine Variante des xPath-Mappings, das Sprach-Attribut x-mapping-xpathfb
.
Diese wird als Fallback-Mechanismus genutzt, falls keiner der xPath-Ausdrücke einer Klassifikation zutrifft.
Das heißt, der xPath, der für dieses Sprachattribut hinterlegt ist, wird nur dann ausgewertet, wenn keiner
der anderen xPaths der Klassifikation einen Treffer erzielt. z.B.:
|
|
In diesem Beispiel würde ein Klassifikations-Mapping auf eine Online-Resource dann passieren, wenn keiner der anderen xPaths der Klassifikation eine Übereinstimmung hat.
Damit nicht alle Klassifikationen nach dem Sprach-Attribut x-mapping-xpath
durchsucht werden müssen, werden die
Klassifikationen,
die solche Attribute enthalten, in einer Property angegeben:
|
|
Falls diese für eine Klassifikation nicht gesetzt ist, werden mögliche xPath-Mappings ignoriert. Das ist nützlich, falls man vorhandene Klassifikationen mit xPath-Mappings nachnutzen will, ohne die Funktionalität zu benötigen.
Da xPath-Ausdrücke recht lang sein und sich wiederholen können, gibt es für das xPath-Mapping einen Pattern-Mechanismus. Damit können wiederkehrende xPath-Ausdrücke in Properties abgelegt und mit Platzhalter versehen werden, z.B.:
|
|
Diese Pattern können dann in Klassifikationen genutzt werden, um die Formulierung von xPaths abzukürzen:
|
|
Aus der Konfiguration in diesem Beispiel würde sich folgender xPath ergeben:
mods:genre[substring-after(@valueURI,'#')='article'] and not(mods:relatedItem[@type='host'])
.
Die allgemeine Syntax lautet:
{pattern:<Name der Property>(<Komma-separierte Liste der
einzusetzenden Werte>)}
im jeweiligen xPath und
MCR.Category.XPathMapping.Pattern.<pattern name>=<XPath with optional
placeholders>
in den Properties.
Das Datenmodell wird um ein Datenfeld mappings/mapping ergänzt werden. Dieses Feld wird dann beim Einfügen oder Aktualisieren der Dokumente automatisch befüllt.
|
|
Das Mapping wird per EventHandler aktiviert und sollte möglichst früh aufgerufen werden, zumindest noch vor dem Start der Indexierung.
|
|
Wird das MODS-Datenmodell genutzt, muss kein zusätzlichen Datenfeld ergänzt werden. In diesem Fall werden die
generierten Einträge als zusätzliche mods:classification
Elemente abgespeichert.
Für dieses Verhalten wurde ein weiterer Eventhandler implementiert:
|
|
Im resultierenden MODS wird der Eintrag durch das Attribut generator
eindeutig identifizierbar. Dieses enthält immer das Suffix -mycore und setzt sich weiterhin aus:
Siehe dazu nachfolgende Beispiele:
|
|
|
|