2.6 Metadaten

Jedes Metadaten Feld, das im Goobi viewer verwendet werden soll, muss im Goobi viewer Indexer im Konfigurationselement fields konfiguriert sein. Hierfür wird das folgende Schema verwendet:

<fields>
    <PI>
        <list>
            <item>
                <xpath>
                    <list>
                        <item prefix="bibprefix_" suffix="_bibsuffix">mets:xmlData/mods:mods/mods:identifier [@type="ppn" or @type="PPN"]</item>
                        <item>lido:administrativeMetadata/lido:recordWrap/lido:recordID</item>
                    </list>
                </xpath>
                <getnode>first</getnode>
                <addToDefault>true</addToDefault>
                <addUntokenizedVersion>false</addUntokenizedVersion>
            </item>
        </list>
    </PI>
</fields>

Dabei trägt das oberste Element jeweils den Namen des Solr Feldes, in das das konfigurierte Metadatum geschrieben werden soll (hier: PI).

Feldkonfigurationen, deren Name nicht mit MD_ im anfängt, sind größtenteils Pflichtfelder für den Goobi viewer und dürfen nicht entfernt werden! Für die Konfiguration von Solr Metadatenfeldern werden Grundkenntnisse in XPath vorausgesetzt. Nähere Details hierzu finden sich beispielsweise unter der folgenden Adresse: http://de.wikipedia.org/wiki/XPATH

Änderungen in der Sektion <fields> werden ohne Neustart direkt übernommen.

item

Diese Elemente enthalten XPath Ausdrücke, unter denen das jeweilige Metadatum zu finden ist. Es werden alle angegeben Ausdrücke überprüft, so dass ein Metadatenfeld (falls für mehrere Werte zugelassen) mehrere Werte aus unterschiedlichen XPath Ausdrücken enthalten kann. Im obigen Beispiel ist jeweils ein Ausdruck für METS/MODS sowie für LIDO definiert, das heißt diese Feldkonfiguration ist für beide Formate gültig.

Die Attribute prefix und suffix können optional je ein statisches Prä- beziehungsweise Suffix, das an jeden über den jeweiligen XPath-Ausdruck gefundenen Wert angehängt wird.

Für METS Dokumente kann der Ausdruck entweder relativ zum Element formuliert werden, zum Beispiel:

mets.xml
<mets:mets>
    <mets:mdWrap MDTYPE=”MODS”>
    [...]
    </mets:mdWrap>
</mets:mets>
<item>mets:xmlData/mods:mods/mods:identifier[@type="ppn" or @type="PPN"]</item>

oder relativ zum obersten Element

mets.xml
<mets:mets>
    [...]
</mets:mets>
<xpath>mets:amdSec[@ID="AMD"]/mets:rightsMD[@ID="RIGHTS"]/mets:mdWrap[@MDTYPE='OTHER' and @MIMETYPE='text/xml' and @OTHERMDTYPE='DVRIGHTS']/mets:xmlData/dv:rights/dv:ownerContact</xpath>

Dabei muss die Variante nicht explizit angegeben werden - der Goobi viewer Indexer überprüft alle konfigurierten Ausdrücke relativ zu beiden Knoten.

Bei LIDO werden die XPath Ausdrücke bei allgemeinen Metadaten relativ zum obersten Element formuliert, zum Beispiel

lido.xml
<lido:lido>
    [...]
</lido:lido>
<item>lido:administrativeMetadata/lido:recordWrap/lido:recordID</item>

Metadaten von LIDO Events verwenden XPath Ausdrücke relativ zum jeweiligen Event-Element, zum Beispiel:

lido.xml
<lido:lido>
     <lido:eventWrap>
          <lido:eventSet>
               <lido:event>
                      ...
               </lido:event>
          </lido:eventSet>
     </lido:eventWrap>
</lido:lido>
<item>lido:eventDate/lido:date/lido:earliestDate</item>

Im Folgenden werden einige weitere Parameter für die Indexierung erläutert.

addSortField

Falls true, wird zusätzlich zum konfigurierten Metadatenfeld ein zweites Feld geschrieben, das für die Sortierung von Suchtreffern verwendet werden kann. Dabei erhält das zweite Feld den Präfix SORT_ im Namen. Dies ist insbesondere bei Feldern nützlich, deren Name mit dem Präfix MD_ anfängt (MD_ wird dabei durch SORT_ ersetzt). Diese sind im Solr Schema stets so konfiguriert, dass sie mehrere Werte als Liste enthalten können - solche Felder können in Solr nicht für die Sortierung verwendet werden. Zu beachten ist, dass ein Sortierfeld nicht alle gefundenen Werte enthält, sondern nur den ersten (zum Beispiel den ersten Autor eines Werks). Standardwert ist false.

addSortFieldToTopstruct

Spezialeinstellung für Metadatenfelder aus LIDO-Events. Sollen Suchtreffer nach einem Metadatenfeld aus einem LIDO-Event sortiert werden können, wird durch die Einstellung true ein Sortierfeld aus diesem Metadatenfeld in das Dokument des Hauptelements geschrieben. Standardwert ist false.

addToDefault

Werte: true|false

Falls true, wird der Wert des konfigurierten Metadatenfeldes an das Feld DEFAULT angehängt. Letzteres enthält alle Tokens, nach denen im Goobi viewer gesucht werden kann. Soll ein bestimmtes Metadatum also suchbar sein, muss in der entsprechenden Feldkonfiguration diese Option aktiviert werden. Standardwert ist false.

addUntokenizedVersion

Werte: true|false

Metadatenfelder mit Präfix MD_ werden stets in einzelne Tokens (grob gesehen einzelne Wörter einer Zeichenkette) aufgespalten. Damit man ein Feld durchstöbern kann (siehe Stöbern), muss die gesamte Zeichenkette als ein Token vorliegen (andernfalls kann man zum Beispiel keine Haupttitel, sondern nur einzelne Wörter aus Haupttiteln durchstöbern). Hierfür kann zusätzlich zum Metadatenfeld eine Kopie angelegt werden, deren Wert als ein Token vorliegt (diese erhält den Suffix _UNTOKENIZED). Solche Felder können für die Stöbern-Funktion konfiguriert werden. Standardwert ist true.

groupEntity

Personen und Körperschaften können unter Umständen zusätzliche Metadaten enthalten, wie etwa Lebensdaten beziehungsweise externe Links. Diese Metadaten möchte man evtl. gruppiert anzeigen, um die Zusammengehörigkeit deutlich zu machen.

Hierfür gibt es eine Möglichkeit, zusammengehörende Metadaten, etwa von Personen und Körperschaften, in ein separates Solr Index-Dokument zu schreiben. Diese können dann seitens des Goobi viewers geparst und grafisch entsprechend aufbereitet werden.

Wenn dieses Konfigurationselement auf true gesetzt wird, wird für das betreffende Metadatenfeld die folgende MODS Struktur vorausgesetzt:

mods.xml
<mods:name type="personal" xlink:href=http://de.wikipedia.org/wiki/Eike_von_Repgow  valueURI="http://d-nb.info/gnd/118529501">

      <mods:namePart type=”family”>&lt;von Repgow&gt;</mods:namePart>
      <mods:namePart type=”given”>Eike</mods:namePart>
      <mods:namePart type="date">1180 - 1233</mods:namePart>

      <mods:role>
            <mods:roleTerm authority="marcrelator" type="code">aut</mods:roleTerm>
      </mods:role>

      <mods:displayForm>&lt;von Repgow&gt;, Eike</mods:displayForm>
</mods:name>

Die Konfiguration erfolgt im Konfigurationselement <groupEntity>. Dieses kann optional das Attribut type enthalten (zulässige Werte: PERSON, CORPORATION, LOCATION, SUBJECT, ORIGININFO, CITATION,OTHER) das im Goobi viewer unter bestimmten Umständen eine spezielle Behandlung des Metadatums auslösen kann (zum Beispiel die Anzeige eines Personen-Icons bei Suchtreffern, deren ein Personen-Metadatum zugrunde liegt).

config_indexer.xml
<MD_AUTHOR>
    <list>
        <item>
            <xpath>
                <list>
                    <item>mets:xmlData/mods:mods/mods:name[@type="personal"][mods:role/mods:roleTerm="aut"[@authority='marcrelator'][@type='code']]</item>
                </list>
            </xpath>
            <groupEntity type="PERSON" addAuthorityDataToDocstruct="false" addCoordsToDocstruct="false">
                <field name="MD_VALUE" addSortField="true">mods:displayForm</field>
                <field name="MD_LINK">@xlink:href</field>
                <field name="MD_CORPORATION">mods:namePart[not(@type)]</field>
                <field name="MD_LASTNAME" defaultValue="Doe">mods:namePart[@type="family"]</field>
                <field name="MD_FIRSTNAME" defaultValue="John" multivalued="false">mods:namePart[@type="given"]</field>
                <field name="MD_LIFEPERIOD">mods:namePart[@type="date"]</field>
                <field name="NORM_URI">@valueURI</field>
            </groupEntity>
        </item>
    </list>
</MD_AUTHOR>

Das optionale Attribut addAuthorityDataToDocstruct bewirkt bei der Einstellung true, dass bestimmte Normdatenwerte (aus externen Datenbanken) nicht im dazugehörigen Page-Doc, sondern in dem Strukturelement-Doc gespeichert werden, zu dem die jeweilige Seite gehört. Dadurch kann auf Wunsch vermieden werden, dass Normdatenwerte, die eingegebene Suchbegriffe enthalten, als Untertreffer dargestellt werden (optische Präferenz). Standardwerst ist false.

Ähnlich funktioniert das Attribut addCoordsToDocstruct. Damit werden optional suchbare Geokoordinaten wie zum Beispiel die WKT_* oder NORM_COORDS_* Felder in das zugehörige Strukturelement-Doc anstelle des Page-Docs geschrieben. Standardwert ist false.

Die einzelnen Metadatenfelder innerhalb des Index-Dokuments werden in <field>-Elementen konfiguriert. Das Attribut name beschreibt den gewünschten Namen des Indexfelds innerhalb des Dokuments, der Textwert des <field>-Elements beinhaltet den XPath-Ausdruck des jeweiligen Metadatums.

Das optionale Attribut addSortField bewirkt, dass für das Feld ein zusätzliches SORT_* Field generiert wird. Damit können ggf. mehrere Metadatenwerte innerhalb eines gruppierten Metadatums sortiert werden. Default ist false.

Mit dem optionalen Attribut multivalued=false kann bewirkt werden, dass nur der erste gefundene Wert des jeweiligen Feldes in den Index übernommen wird. Standardwert ist true.

Das optionale Attribut defaultValue kann verwendet werden, um einen Standardwert zu schreiben, falls der XPath-Ausdruck, zu dem das Attribut gehört, keinen Wert liefert. Damit der Standardwert nicht fälschlicherweise zusätzlich zum Wert aus dem XPath-Ausdruck geschrieben wird (etwa wenn ein LIDO-XPath-Ausdruck bei einer Indexierung von METS keinen Wert liefert), sollten für solche Konstellationen am Besten separate <item>-Elemente konfiguriert werden.

Die XPath Ausdrücke werden dabei relativ zum Element definiert, das durch den jeweiligen XPath-Ausdruck in einem <item>-Element gefunden wird. Im obigen Beispiel verstehen sich die XPath Ausdrücke in <field>-Elementen relativ zu <mods:name>.

Es sind beliebige Links möglich. Die Darstellungsart mit dem Wikipedia Symbol im obigen Beispiel wurde in messages.properties konfiguriert (siehe Metadaten Konfiguration). Aus technischen Gründen kann jedoch nur eine Darstellungsart pro Solr Feld konfiguriert werden.

Das Unterfeld MD_VALUE enthält den „Hauptwert“ des Metadatums (Etwa den Namen von Personen, Körperschaften und Schlagwörtern. Es ist zwingend erforderlich, damit das gruppierte Metadatum auch in den Index übernommen wird.

Fehlt das Konfigurationselement, wird eine einfache Zeichenkette mit dem Namen der Person beziehungsweise Körperschaft in mods:displayForm erwartet.

Wenn type="CITATION" konfiguriert ist, kann noch ein url-Attribut konfiguriert werden, um Feldinhalte aus einer externen Quelle einzuholen. In dem unteren Beispiel wird dabei der Wert aus MD_VALUE anstelle des Platzhalters in der URL eingesetzt und so der Datensatz eingeholt. Über die XPath-Ausdrücke der weiteren Unterfelder werden Werte aus dem Primo-Dokument eingeholt.

<groupEntity type="CITATION"
    url="https://example.com/primo_library/libweb/webservices/rest/primo-explore/v1/pnxs/xml/L/ALEPH_EXMPL01${MD_VALUE}?vid=BIBNET\&amp;inst=BIBNET\&amp;showPnx=true">
    <field name="MD_VALUE">lido:objectID[@lido:source="my authoritah"]</field>
    <field name="MD_CITATION_RECORDID">pnx:control/pnx:recordid</field>
    <field name="MD_CITATION_TITLE">pnx:display/pnx:title</field>
    <field name="MD_CITATION_CONTRIBUTOR">pnx:display/pnx:contributor</field>
    <field name="MD_CITATION_PUBLISHER">pnx:display/pnx:publisher</field>
</groupEntity>

Mehrstufige gruppierte Metadaten

Es kann vorkommen, dass ein gruppiertes Metadatum weitere gruppierte Metadaten beinahltet (etwa ein Event mit untergeordneten Event-Aktoren). In dem Fall kann ein <groupEntity> Block weitere <groupEntity> Blöcke beinhalten (theoretisch beliebig Tief). Siehe Beispiel uten.

<MD_EVENT>
    <list>
        <item>
            <xpath>mets:xmlData/mods:mods/mods:extension/intranda:event</xpath>
            <addToDefault>true</addToDefault>
            <groupEntity type="EVENT">
                <field name="MD_VALUE">intranda:type</field>
                <field name="EVENTTYPE">intranda:type</field>
                <field name="MD_MATERIAL">intranda:material</field>
                <field name="MD_DISPLAYDATE">intranda:eventDate/intranda:displayDate</field>
                <field name="MD_EARLIESTDATE">intranda:eventDate/intranda:earliestDate</field>
                <field name="MD_DESCRIPTION">intranda:description/intranda:descriptiveNoteValue</field>
                <groupEntity name="MD_ARTIST" type="PERSON" xpath="intranda:actor[intranda:role='Künstler/-in']">
                    <field name="MD_VALUE">intranda:name</field>
                    <field name="MD_NAME">intranda:name</field>
                    <field name="MD_ROLE">intranda:role</field>
                    <field name="MD_DISPLAYNAME">intranda:displayName</field>
                    <field name="MD_STARTDATE">intranda:startDate</field>
                    <field name="MD_ENDDATE">intranda:endDate</field>
                    <field name="MD_URI_GETTY">@getty</field>
                    <field name="MD_URI_SIKART">@sikart</field>
                    <field name="NORM_URI">@gnd</field>
                </groupEntity>
                <groupEntity name="MD_DESIGNER" type="PERSON" xpath="intranda:actor[intranda:role='Design']">
                    <field name="MD_VALUE">intranda:name</field>
                    <field name="MD_NAME">intranda:name</field>
                    <field name="MD_ROLE">intranda:role</field>
                    <field name="MD_DISPLAYNAME">intranda:displayName</field>
                    <field name="MD_STARTDATE">intranda:startDate</field>
                    <field name="MD_ENDDATE">intranda:endDate</field>
                    <field name="MD_URI_GETTY">@getty</field>
                    <field name="MD_URI_SIKART">@sikart</field>
                    <field name="NORM_URI">@gnd</field>
                </groupEntity>
            </groupEntity>
        </item>
    </list>
</MD_EVENT>

getnode

Ist der Wert auf first gesetzt, wird nach dem ersten gefundenen Wert für den aktuellen XPath Ausdruck abgebrochen. Zu beachten ist, dass für ein Solr Feld mehrere XPath-Ausdrücke definiert werden können, für die ebenfalls Werte existieren können.

getchildren

Ist der Wert auf all gesetzt, werden Werte für dieses Metadatum von allen unmittelbar untergeordneten Strukturelementen mit übernommen.

getparents

Ist der Wert auf first gesetzt, werden Werte für dieses Metadatum auch vom unmittelbar übergeordneten Strukturelement mit übernommen. Bei all werden Werte für dieses Metadatum aus allen übergeordneten Strukturelementen bis hin zum obersten übernommen.

lowercase

Ist diese Option auf true gesetzt, werden alle Großbuchtstaben in der Zeichenkette durch Kleinbuchstaben ersetzt. Standardwert ist false.

Beispiel:

"Buch Druck" ==> "buch druck"

onefield

Falls true, werden alle gefundenen Werte in das Solr Feld als eine Zeichenkette geschrieben. Die Werte werden dabei durch die Zeichenkette "; " separiert. Bei false wird für jeden Wert eine neue Zeichenkette geschrieben. Im letzteren Fall muss das betreffende Feld im Solr Schema so konfiguriert sein, dass Listen aus mehreren Werten erlaubt sind. Standardwert ist false.

Mit dem optionalen Attribut separator kann der Standard-Separator "; " durch einen selbst definierten ersetzt werden:

<onefield separator="#SPACE#">true</onefield>

onetoken / splittingCharacter

Werte (onetoken): true|false
Werte (splittingCharacter): beliebige Zeichenkette

Wenn das Konfigurationselement onetoken auf true gesetzt ist, werden die Werte so aufgearbeitet, dass Solr diese nicht in mehrere Tokens aufteilen kann. Konkret bedeutet das, dass nicht alphanumerische Zeichen entfernt werden. Standardwert ist false.

Beispiel:

"Buch Druck, Hallo Welt" ==> "BuchDruckHalloWelt"

Ist für dieses Feld zusätzlich eine beliebige Zeichenkette im Element splittingCharacter konfiguriert, werden alle Vorkommnisse dieser Zeichenkette durch einen Punkt (.) ersetzt.

Beispiel:

<splittingCharacter>#<splittingCharacter>
"Buch#Druck, Hallo Welt"==> "Buch.DruckHalloWelt"

Diese Konfigurationselemente existieren speziell für die Behandlung von Kollektionsnamen im Goobi viewer (Feld DC) und bringen keinen Mehrwert bei anderen Metadatenfeldern.

normalizeYear

Dieses Konfigurationselement ist für Metadatenfelder bestimmt, die Datumsangaben beziehungsweise Jahreszahlen enthalten. Wird dieses Element auf ‘true’ gesetzt, versucht der Goobi viewer Indexer, aus dem Wert dieses Feldes eine normalisierte Jahreszahl (nach dem Muster yyyy) zu extrahieren. Zur Zeit werden reine Jahreszahlen sowie Datumsangaben nach den Mustern dd.MM.yyyy und yyyy-MM-dd erkannt. Alle erkannten Jahreszahlen werden in das Feld YEAR , YEARMONTH und YEARMONTHDAY geschrieben. Zusätzlich wird aus diesen Jahreszahlen noch das jeweilige Jahrhundert berechnet und in das Feld CENTURY geschrieben.

Beide Felder können zum Beispiel für die Facettierung von Suchtreffern verwendet werden. Da es sich um Felder mit mehreren möglichen Werten pro Feld handelt, können sie allerdings nicht für die Suchtreffersortierung verwendet werden. Standardwert ist false.

Optional kann das Attribut <normalizeYear minYearDigits="n"> konfiguriert werden. Der Wert n gibt dabei an, ab wie vielen Ziffern frei stehende Zahlen in einer Zeichenkette als Jahreszahlen interpretiert werden sollen. Mindestwert ist 1. Standardwert ist 3.

replace

Dieses Konfigurationselement ersetzt einzelne ASCII Zeichen beziehungsweise Zeichenketten durch eine andere Zeichenkette. Ein zu ersetztes Zeichen wird im Attribut char als ASCII Zahlencode angegeben. Alternativ kann im Attribut string eine Zeichenkette angegeben werden oder im Attribut regex ein Regulärer Ausdruck. Die Zeichenkette, die stattdessen geschrieben werden soll, wird innerhalb des Elements angegeben.

Beispiel 1:

config_indexer.xml
<replace char="10">&lt;br /&gt;</replace>

Im obigen Beispiel wird ein ASCII-Zeichen für den Zeilenumbruch (10) durch die HTML-Zeichenkette für den Zeilenumbruch ersetzt.

Eine Liste an ASCII Zeichen kann zum Beispiel auf https://ascii.cl/ nachgeschlagen werden.

Beispiel 2:

config_indexer.xml
<replace string="¬"></replace>

In diesem Beispiel wird das Nichtsortierzeichen ‘¬’ durch nichts ersetzt (das heißt entfernt).

Beispiel 3:

config_indexer.xml
<replace regex="(.*)\[(.*) (.*)\]">$1[$3 $2]</replace>

In diesem Beispiel werden drei Gruppen gebildet und die zweite und dritte innerhalb der eckigen Klammern vertauscht, zum Beispiel würde aus "Der heilige Stuhl [Max Mustermann]" ein "Der heilige Stuhl [Mustermann Max]" werden.

Für Leerzeichen wird der Platzhalter #SPACE# unterstützt.

Wenn ein Value in mehrere Values aufgeteilt werden soll, kann dafür der {SPLIT} Platzhalter verwendet werden:

config_indexer.xml
<replace regex="^international$">LUX_YES{SPLIT}LUX_NO</replace>

nonSortCharacters

Alternativ zum Ersetzen von Nichtsortierzeichen (siehe Kapitel 3.8.12) kann mit diesem Konfigurationselement die Erkennung von Nichtsortier-Teilen für Metadaten- sowie Sortierfelder konfiguriert werden. Dabei werden für angezeigte Metadatenfelder die Nichtsortierzeichen herausgefiltert, für Sortierfelder wird der gesamte Teil der Zeichenkette, der durch die Nichtsortierzeichen diskriminiert ist, entfernt.

Ist der für die Sortierung des nicht relevanten Teils beidseitig von Nichtsortierzeichen umschlossen, zum Beispiel « und », muss « im Attribut prefix, » im Attribut suffix konfiguriert werden.

Beispiel 1:

mods.xml
<mods:name>
    <mods:displayForm>«von» Goethe, Johann Wolfgang</mods:displayForm>
<mods:name>
config_indexer.xml
<nonSortCharacters prefix="«" suffix="»" />

Ergebnis

<MD_TITLE>von Goethe, Johann Wolfgang</MD_TITLE>
<SORT_TITLE>Goethe, Johann Wolfgang<SORT_TITLE>

Wird der nicht für die Sortierung relevante Teil nur auf einer Seite vom Rest der Zeichenkette getrennt, muss dieses Zeichen nur als prefix (nicht relevanter Teil am Anfang der Zeichenkette) beziehungsweise suffix (nicht relevanter Teil am Ende der Zeichenkette) konfiguriert werden.

Beispiel 2:

mods.xml
<mods:name>
    <mods:displayForm>von¬ Goethe, Johann Wolfgang</mods:displayForm>
<mods:name>
config_indexer.xml
<nonSortCharacters suffix="\u00AC" />

Ergebnis:

<MD_TITLE>von Goethe, Johann Wolfgang</MD_TITLE>
<SORT_TITLE>Goethe, Johann Wolfgang<SORT_TITLE>

addToChildren

Ist diese Parameter auf true gesetzt, werden die Werte dieses Metadatums an untergeordnete Strukturtyp-Dokumente vererbt. Dies ist zum Beispiel für Lizenztypen wichtig, die eine Solr-Bedingungsquery verwenden. Die in der Query verwendeten Feldnamen müssen in der Regel diesen Parameter aktiviert haben. Das Feld DC muss diesen Parameter immer aktiviert haben. Standardwert ist false.

addToPages

Ist diese Parameter auf true gesetzt, werden die Werte dieses Metadatums an die der jeweiligen Strukturhierarchie zugewiesene Seitendokumenten vererbt. Dies ist zum Beispiel für Lizenztypen wichtig, die eine Solr-Bedingungsquery verwenden. Die in der Query verwendeten Feldnamen müssen in der Regel diesen Parameter aktiviert haben. Und auch Metadatenfelder, die in der erweiterten Suche mit Volltexten kombiniert werden sollen. in den SeitendokumentenDas Feld DC muss diesen Parameter immer aktiviert haben. Standardwert ist false.

normalizeValue

config_indexer.xml
<normalizeValue convertRoman="false" length="5" filler="0" position="FRONT" regex="foo([0-9]+).*$" />

Insbesondere für Sortierfelder ist es manchmal notwendig, etwa enthaltene Zahlenwerte zu normalisieren, um korrekte Sortierung zu erhalten.

Beispiel: "foo1138bar" und "foo123bar". "123" ist als Zahl kleiner, als "1138", durch die String-Sortierung wird der Wert allerdings hinter "1138" einsortiert, da "11" vor "12" kommt.

Durch die Anwendung der oben beschriebenen Konfiguration wird der Zahlenwert auf fünf Stellen aufgefüllt: "foo00123bar" wird nach der Normalisierung vor "foo01138bar" einsortiert.

Es können pro Feld mehrere <normalizeValue> Elemente konfiguriert werden, die sukszessive auf den Metadatenwert angewandt werden.

addToParents

Ist dieser Parameter auf true gesetzt; werden alle in Unterelementen gefundenen Metadatenwerte ins Hauptelement verschoben (sowohl bei einfachen als auch bei gruppierten Metadaten). Der Standardwert ist false.

Das Attribute keepOnChildren bewirkt, dass hoch vererbte Metadaten nicht nur im obersten Element landen, sondern in der ganzen Hierarchie verbleiben. Default ist false.

geoJSONSource

Hiermit können Geokoordinaten von Punkten und Polygonen aus GML oder mods:coordinates anstatt im Ursprungsformat als geoJSON geschrieben werden.

Folgende Werte werden derzeit unterstützt:

  • gml:Point (Punkte im Format "lon lat")

  • gml:Point:4326 (Punkte im Format "lat lon")

  • gml:Polygon (Punkte im Format "lon lat")

  • gml:Polygon:4326 (Punkte im Format "lat lon")

  • mods:coordindates/point

Optional kann das Attribut addSearchField="true" definiert werden. In diesem Fall wird zusätzlich das Feld WKT_COORDS geschrieben, welches die Koordinaten des Punktes beziehungsweise des Polygons über Solr suchbar im Format WKT enthält.

config_indexer.xml
<MD_GEOJSON_POLYGON>
    <list>
        <item>
            <xpath>denkxweb:geoReference/denkxweb:surface/gml:MultiSurface[@srsName="http://www.opengis.net/def/crs/epsg/0/4326"]/gml:surfaceMember/gml:Polygon/gml:exterior/gml:LinearRing/gml:posList</xpath>
            <geoJSONSource addSearchField="true">gml:Polygon:4326</geoJSONSource>
        </item>
    </list>
</MD_GEOJSON_POLYGON>

interpolateYears

Mit dem Schalter <interpolateYears /> kann angegeben werden, ob Jahreszahlen im Feld YEAR interpoliert werden sollen. Das ist insbesondere dann nützlich, wenn bei einer Facettierung nach Jahr auch Datensätze gefunden werden sollen, für die kein konkretes Jahr, sondern ein Zeitraum erfasst wurde. Ein Zeitraum kann zum Beispiel als 1400-1499 oder 1400/1499 erfasst werden. Der Standardwert ist false.

Der Schalter ist mit Vorsicht zu genießen. Stammt ein Objekt zum Beispiel aus der Kreidezeit und ist diese hinterlegt, dann können sehr viele Werte geschrieben werden bei dem dann der Nutzen der Zusatzinformation nicht mehr gegeben ist.

allowDuplicateValues

In der Regel werden doppelte Metadaten (Feld + Wert identisch) nur einmal geschrieben. Der Schalter <allowDuplicateValues> (wenn true) erlaubt, dass diese Regel für bestimmte Felder ausgesetzt wird und mehrere identische Metadatenfelder geschrieben werden dürfen. Standardwert ist false.

addExistenceBoolean

Mit diesem Schalter kann automatisch ein Boolean-Feld generiert werden, dass das Vorhandensein des jeweiligen Metadatenfeldes beschreibt. Steht dieser Schalter bei der Feldkonfiguration von MD_TITLE auf true, wird bei gefundenem Wert für MD TITLE ein Feld BOOL_TITLE=true in den Index geschrieben. Wird kein Wert für MD_TITLE gefunden, wird BOOL_TITLE=false im Index stehen. Dieses Boolean-Feld kann verwendet werden, um etwa Objekte nach Vorhandensein eines Metadatenfeldes zu filtern.

Last updated