Arbeiten mit Normierungsregeln
Um mit Normierungsregeln zu arbeiten, müssen Sie die folgende Rolle innehaben:
- Katalog-Administrator
- Katalog Manager
- Katalogisierer
Normalisierungsregeln werden verwendet, um Titelsatz-Metadaten auf unterschiedlichen Stufen zu ändern oder zu aktualisieren; beispielsweise wenn der Datensatz im Metadaten-Editor gespeichert, via Importprofil importiert, über eine externe Suchressource importiert oder im Menü „Datensatz erweitern“ im Metadaten-Editor bearbeitet wird. Die Normierungsregeln sind in einer bestimmten Syntax geschrieben, sodass Sie Regeln erstellen können, die sich auf bestimmte Änderungen an Datensätzen auswirken. Sie können beispielsweise Felder bearbeiten oder löschen, und Sie können dies auch konditionell tun, basierend auf einer anderen Bedingung, die im Titelsatz zutrifft oder nicht zutrifft.
Normalisierungsregeln können auf einzelne Datensätze im MD-Editor oder auf eine Gruppe von Datensätzen angewendet werden:
- Zum Anwenden von Normalisierungsregeln auf einen einzelnen Datensatz verwenden Sie die Option Datensatz erweitern (siehe den Abschnitt Menü- und Werkzeugleisten-Optionen des MD-Editors) oder Veränderungen übernehmen auf einen einzelnen Datensatz, wenn Sie die Normalisierungsregeln anzeigen (siehe Um das Ergebnis einer Regel als Vorschau anzusehen).
- Um Normalisierungsregeln auf eine Reihe von Datensätzen anzuwenden, müssen Sie mithilfe der Aufgaben MARC-Drool-Normalisierung oder DC-Drool-Normalisierung einen Prozess erstellen (siehe Arbeiten mit Normalisierungsprozessen) und die Normalisierungsregel spezifizieren, die Sie mit dem MD-Editor erstellen (siehe Um eine neue Normalisierungsregel-Datei zu erstellen). Sobald Sie den Prozess erstellt haben, können Sie einen Prozess ausführen, der diesen Prozess verwendet (siehe Manuelle Prozesse an definierten Sets ausführen). Darüber hinaus können Sie einen Prozess erstellen, der die Anwendung von Normalisierungsregeln beim Klicken auf Speichern im MD-Editor ermöglicht (siehe Arbeiten mit Normierungs-Prozessen).
Normierungsregeln werden einer spezifischen Programmierungs-Syntax folgend erstellt und nutzen das Bearbeitungsfenster, das im MD-Editor der Registerkarte Regeln bereitgestellt wird.
Registerkarte Regeln - Bearbeitungsfenster
Zusätzlich zum Erstellen Ihres eigenen Programms für Normalisierungsregeln können Sie auch vorhandene Regeln in das Bearbeitungsfenster kopieren/einfügen, oder voreingestellte Beispiele verwenden (Registerkarte Regeln), um Ihre Normalisierungsregeln zu entwickeln. Siehe Normalisierungsregeln – Syntax und Beispiele für weitere Informationen zur Syntax von Normalisierungsregeln, sowie Beispiele, die Sie in das Bearbeitungsfenster kopieren können.
Unter Verwendung der Vorschaufunktion im MD-Editor können Sie:
- Die Normierungsregeln und Metadatensätze nebeneinander ansehen
- Eine Vorschau des Ergebnisses einer Regel ansehen, wenn diese an einem Metadatensatz ausgeführt wird
- Zwischen der Regel und den Vorschau-Änderungen umschalten
- Regeln bearbeiten und sofort testen
- Einen kurzen Überblick über die Normalisierungsregeln finden Sie im Video Normalisierungsregeln (6:00 Min.).
- Ausführliche Informationen zu Normalisierungsregeln mit Beispielen finden Sie im Video Normalisierungsregeln (1 Std.).
Normierungsregeln erstellen
Dieser Abschnitt beschreibt, wie Sie eine Normalisierungsregel erstellen oder eine Regel aus der Gemeinschaftszone kopieren, mit vorab erstellten Regeln arbeiten und das Ergebnis einer Regel als Vorschau ansehen, wenn diese an einem einzelnen Metadatensatz ausgeführt wird. Weitere Informationen finden Sie im Bereich Normalisierungsregeln auf dieser Seite.
Beachten Sie, dass Normalisierungsregeln für IZ-Datensätze, die mit NZ-Datensätzen verknüpft sind, nur an lokalen Feldern angewendet werden können. Um Normalisierungsregeln an solchen Datensätzen anzuwenden, führen Sie die Normalisierungsregeln und Normalisierungsprozesse nur in der Netzwerk-Institution durch.
Für Mitglieder von Netzwerkzonen-Konsortien können Benutzer steuern, ob neue Regeln lokal oder in einer Netzwerkinstitution gespeichert werden sollen. Um diese Auswahl zu treffen, öffnen Sie den Bereich Datensätze oder Vorlagen und gehen Sie zu Neu > Optionen zur Positionierung. Beachten Sie, dass diese Auswahl pro Benutzer erfolgt.
- Öffnen Sie die Seite MD-Editor (Ressourcen > Katalogisierung > Metadaten-Editor öffnen), öffnen Sie dann den Bereich Regeln.
- Um eine Normalisierungsregel für einen MARC oder Dublin Core Datensatz zu erstellen, wählen Sie Neu > Normalisierung. Das Dialogfenster Eigenschaften der Normierungsregel (neue Regel) wird geöffnet.
Dialogfenster Normierungsregeln - Eigenschaften - Geben Sie einen Namen und eine Beschreibung für die Normalisierungsregel ein.
Das Wort „Regel“ darf nicht großgeschrieben werden, wenn es im Regelnamen verwendet wird. Bei Großschreibung funktioniert die Regel nicht.
Verwenden Sie keinen Backslash (\) im Regelnamen! In diesem Fall kann die Regel nicht für die Filtersatzfunktion verwendet werden. - Um eine Normalisierungsregel für einen MARC-Datensatz zu erstellen, wählen Sie Drool. Um eine Normalisierungsregel für einen DC-Datensatz (Dublin Core) zu erstellen, wählen Sie 'XSL'.
- Wählen Sie eine Zugangsoption, Privat oder Gemeinsam genutzt. Wenn Sie Privat auswählen, können nur Sie an der Regel arbeiten und die Regel kann nicht in einen Normalisierungsprozess eingebunden werden. Wenn Sie Geteilt auswählen, wird Ihre Regel unter Katalogisierern geteilt. In diesem Fall kann mehr als ein Benutzer zur selben Zeit die Regel ansehen und wenn zwei oder mehrere Personen die Regel zur Bearbeitung geöffnet haben, erscheint eine Warnmeldung, wenn einer von Ihnen versucht, Änderungen zu speichern. (Sie haben die Möglichkeit, Ihre Änderungen beizubehalten oder dem anderen Benutzer zu erlauben, Änderungen vorzunehmen oder zu speichern.)
- Wählen Sie Speichern. Das Bearbeitungsfenster des MD-Editors wird geöffnet.
Sie können eine bestehende Regel-Syntax einfügen (Bearbeiten > Neue Regel > {type of rule}) oder eine Regel definieren (für Details siehe Normalisierungsregeln -Syntax). - Wählen Sie Speichern. Die Regel wird der Liste der Regel-Dateien unter der Registerkarte Normierungsregeln hinzugefügt.
Um Normalisierungsregeln in der Gemeinschaftszone zu kopieren/beizutragen:
- Klicken Sie auf der Seite MD-Editor (Ressourcen> Katalogisierung >Metadaten-Editor öffnen) auf die Registerkarte Regeln und erweitern Sie den Ordner Normierung.
- Öffnen Sie zum Kopieren den Ordner Gemeinschaft. Machen Sie einen Rechtsklick auf die Regel, die Sie kopieren möchten und wählen Sie Duplizieren.
Das Dialogfenster Regel duplizieren wird angezeigt. Geben Sie Ihren Namen und Ihre Beschreibung an und geben Sie an, ob Sie als private Regel (nur für Sie verfügbar) oder als gemeinsame Regel (für alle Benutzer in Ihrer Institution verfügbar) speichern möchten.
Der Name und die Kontakt-E-Mail des Alma-Benutzers, der die Regel zu CZ beigetragen hat, werden im Dialog angezeigt. Sie können diesen Benutzer bei Fragen kontaktieren. - Um zu Ihrer CZ beizutragen, machen Sie einen Rechtsklick auf die gewünschte Regel und wählen Sie Zur GZ beitragen.
Das Dialogfenster Regel teilen wird angezeigt. Geben Sie einen beschreibenden Namen und eine Beschreibung ein und wählen Sie Speichern, um die Regel in CZ zu speichern.
Um mit einer bestehenden Normierungsregel zu arbeiten:
- Wählen Sie auf der Seite MD-Editor ( Ressourcen > Katalogisierung > Metadaten-Editor öffnen) die Registerkarte Regeln und erweitern Sie den Ordner Normalisierung, um die gespeicherten Regeln anzuzeigen.
- Klicken Sie auf die Regel, mit der Sie arbeiten wollen und wählen Sie eine der folgenden Optionen aus:
- Bearbeiten - Öffnet das Textfeld mit der Syntax der Regel(n), in dem Sie diese Syntax ändern können (Einzelheiten siehe Normalisierungsregeln - Syntax).
- Löschen – Klicken Sie auf Ja, um das Löschen der Regel-Datei zu bestätigen.
- Duplizieren – Dupliziert die ausgewählte Regel-Datei, wodurch Sie diese bearbeiten und als neue Regel speichern können, ohne die ursprüngliche Datei zu beeinträchtigen.
- Eigenschaften – Öffnet das Dialogfenster Normierungsregeln - Eigenschaften, wo Sie die Eigenschaften der Regel-Datei ändern können.
- So benennen Sie die Regel um: Duplizieren Sie die Regel, geben Sie dem Duplikat den gewünschten Namen und löschen Sie dann die alte Regel.
- Lokalisieren Sie den Titelsatz, mit dem Sie arbeiten wollen, (über die Bestandssuche oder in der Registerkarte Datensatz im MD-Editor) und öffnen Sie ihn im MD-Editor.
- Drücken Sie (F6) oder klicken Sie auf das Symbol Geteilter Editor.
- Wählen Sie die Registerkarte Regeln im linken Fensterbereich und erweitern Sie den Ordner Normalisierung.
- Wählen Sie mit der rechten Maustaste die Regel aus, die Sie in der Vorschau anzeigen oder testen möchten, im Ordner Privat oder Geteilt (nicht unter Gemeinschaft), und wählen Sie Bearbeiten.
Die Regel wird im rechten Fensterbereich des MD-Editors angezeigt.
- Klicken Sie auf Vorschau. Die Regel wird auf den Datensatz angewendet und das Ergebnis wird angezeigt.
Um Netzwerk-Datensätze zu ändern, muss die Normalisierung von der Netzwerk-Institution ausgeführt werden (nicht von einem Mitglied). Ein Institution kann keine Netzwerk-Datensätze ändern, daher wird die Normalisierung nur an den lokalen Feldern (den lokalen Erweiterungen der Mitglieder) angewendet. Wenn Sie eine Vorschau für einen Netzwerk-Datensatz ansehen, wird die folgende Nachricht angezeigt: Beachten Sie, dass die Regel nur an lokalen Feldern angewendet wird, wenn der Normalisierungsprozess ausgeführt wird.
- Klicken Sie auf Veränderungen übernehmen, um die Änderungen am Datensatz zu speichern, oder klicken Sie auf Zurück zu den Normalisierungsregeln, um sie weiter zu bearbeiten.
- Wenn Sie Ihre abschließenden Änderungen an der Normalisierungsregel vorgenommen haben, klicken Sie auf Speichern unt testen mit dem externen Datensatz, um die endgültige Version Ihrer Normalisierungsregel zu speichern. Für Details siehe Testen von Normalisierungsregeln für externe Datenquellen.
Normalisierungsregeln für Dublin Core- und MODS-Datensätze
Im Metadaten-Editor gibt es folgende Arten von Regeln, die mit Dublin Core und MODS verknüpft sind:
- XSL-Indikationsregeln
- XSL Normierungsregeln
Die XSL-Normalisierungsregel unterstützt nicht discovery:local.
Dublin Core-und MODS-Normalisierungsregeln können nicht in einem regulären Normierungsregel-Format geschrieben werden, sondern nur als XSL. Das bedeutet, dass Sie die XSL direkt im Metadaten-Editor verfassen (wie oben erläutert). Oder Sie können sie in Notepad (oder einer anderen externen Anwendung Ihrer Wahl) verfassen und anschließend in den Metadaten-Editor kopieren.
Sie können die folgenden Beispiele für XSL-Normalisierungsregeln für Dublin Core in der Gemeinschaftszone im Metadaten-Editor anzeigen:
- EXL – Ändern des dc:language-Wertes en in Englisch
- EXL – Allgemeine Regel zum Ersetzen der Zeichenfolge im Dublin Core-Datensatz
- EXL_Add_field_accessRights
Um XSL für Dublin Core und MODS zu schreiben:
- Schreiben Sie die XSL in einer externen Anwendung Ihrer Wahl.
- Öffnen Sie den Abschnitt Metadaten-Editor > Regeln.
- Kopieren Sie die XSL, fügen Sie diese in den Metadaten-Editor ein und speichern Sie die Regel.
Normalisierungsregeln für Primo VE und Esploro
Zusätzlich zu den Alma-Normalisierungsregeln können Sie Normalisierungsregeln für Primo VE und Esploro erstellen. Um diese Regeln zu erstellen, klicken Sie auf Neu und wählen Sie dann:
-
Normalisierung (Discovery) – Diese Option erscheint nur, wenn Primo-VE im System definiert ist. Wählen Sie diese Option, wenn Sie DC- oder XML-Normalisierungsregeln für Titelsätze erstellen, die in Primo VE geladen und nicht in Alma verwaltet werden. Informationen zur Syntax dieser Regeln finden Sie unter Normalisierungsregeln - Syntax für DC- and XML-Formate.
-
Normalisierung (Recherche) – Diese Option erscheint nur, wenn Esploro im System definiert ist. Für Details siehe: Verwalten von Posten-Normalisierungsregeln (Esploro).
Normalisierungsregeln - Syntax
Regel kann eine oder mehrere weitere Regeln enthalten. Jede Regel enthält eine Bedienung und eine oder mehrere Aktionen, die auf Datensätze angewendet werden. Aktionen werden auf einen Datensatz angewendet, wenn dieser der Bedingung entspricht. Jede Aktion kann an einem einzelnen Feld innerhalb eines Datensatzes ausgeführt werden. Aktionen werden in der Reihenfolge ausgeführt, in der sie innerhalb der Regel erscheinen.
Wenn Sie eine Regel definieren, die mehrere Regeln enthält, müssen Sie den Faktor für die Priorität (oder Salinz) verwenden. Die in der Regel mit der höheren Priorität festgelegten Aktionen werden zuerst durchgeführt. Beispielsweise wird die Aktion in einer Regel mit Priorität 2 unten vor der Aktion in einer Regel mit Priorität 1 durchgeführt. Beispiele dafür, wie welche Priorität (oder Salienz) in Normalisierungsregeln verwendet werden kann, finden Sie unter Beispiele - Alma-Normalisierungsregeln. Beachten Sie, dass die Priorität (oder Saline) nur erforderlich ist, wenn die Felder in den Regeln dieselben sind. Andernfalls werden, wenn jede Regel in einer Datei unterschiedliche Felder behandelt, von oben bis unten mehrere Regeln angewendet.
Erfahren Sie mehr über die Erstellung von Normierungsregeln im Video Normierungsregeln (5:42 Min.).
Sie erfahren, wie Sie Normalisierungsregeln erstellen, die bestimmte Felder aus Datensätzen löschen oder die Inhalte dieser Felder ändern, im Video Normalisierungsroutine - Syntax für das Löschen oder Ändern des Inhalts (9:57 min).
Wenn
(<conditions on MARC record>) dann
Aktion
Ende
(<conditions on MARC record>) dann
Aktion
Ende
<conditions on MARC record> enthält eine oder mehrere boolesche Klauseln, die auf den Datensatz anwendbar sind. Wenn <conditions on MARC record> RICHTIG ergibt, wird die Regel auf den Datensatz angewendet; andernfalls wird die Regel nicht angewendet und der Datensatz wird nicht verarbeitet.
- “Wenn” muss das einzige Wort in der ersten Zeile sein. Die Bedingung muss in eine separate Zeile gesetzt werden.
- Sie können nur in der Bedingung „Wenn“ mehrere Bedingungen für den gesamten Datensatz verwenden. Jede Regel darf nur eine Aktion haben (nach der „Dann“-Zeile). Wenn Sie nach der „Dann“-Zeile mehrere Aktionen verwenden möchten, teilen Sie dies in mehrere Regeln mit jeweils einer einzigen Aktion auf.
- Es ist zwar zulässig, mehrere Boole'sche Operator in die Regeln einzubeziehen, wenn jedoch eine große Anzahl Boole'scher Operator ausgewählt ist, wird die Leistung voraussichtlich langsamer. Daher sollte jede Regel maximal 200 Boole'sche Operator enthalten.
- Wenn nicht angegeben, funktioniert die Bedingung auf Datensatzebene. Wenn Sie möchten, dass die Bedingung für jedes MARC21-Feld separat funktioniert, sollte die Bedingung pro Feld angegeben werden. Wenn beispielsweise mehrere MARC21-Felder mit demselben Feldcode vorhanden sind.
Beachten Sie, dass Sie bei Verwendung von Backslashes möglicherweise keine ungerade Anzahl von Backslashes verwenden dürfen, z. B. \z oder \\\z. Die Verwendung eines einzelnen Backslashes wird jedoch in den folgenden Escape-Sequenzen unterstützt:
- \b
- \t
- \n
- \f
- \r
- \"
- \'
- \\
Im Allgemeinen sollten Sie für Escape-Sequenzen einen doppelten Backslash (\\) verwenden.
Die Verwendung einer ungeraden Anzahl von Backslashes führt zu folgendem Fehler: "Ungültige Escape-Sequenz (gültige sind \b \t \n \f \r \" \' \\ )"
Im Folgenden sind einige Beispiele für Korrekturen aufgeführt, die an den Regeln vorgenommen werden können, wenn dieser Fehler auftritt, der das Verhalten der vorhandenen Regel beibehält:
-
\\\ mit \\ ersetzen
-
\. mit . ersetzen
-
\ mit \\ ersetzen
-
\( mit ( ersetzen
-
replacing \) with )
-
\\\| mit \\| ersetzen
Datensatz-Elemente
Bedingungen und Aktionen werden auf Datensatz-Elemente angewendet, wie etwa der MARC-Satz, Felder (eines oder mehrere), Indikatoren, Unterfelder (eines oder mehrere) und Feld-/Unterfeld-Inhalte.
Um eine Bedingung zu testen oder eine Aktion auf ein Datensatz-Element anzuwenden, muss das Element der folgenden Syntax entsprechen:
| Bezeichnung | Bedeutung |
|---|---|
| "<tag>", "<new tag>" | Stellt einen Feldcode dar, beispielsweise 001, 245, etc. |
| "<oldCode>", "<newCode>" | Stellt einen Unterfeld-Code dar, beispielsweise a, b, c. |
| "<element>" für ein Datenfeld | Die möglichen Werte für das Datenfeld sind folgende:
|
| "<element>" für ein Kontrollfeld | Die möglichen Werte für ein Kontrollfeld sind folgende:
|
| "<element>" für ein festes Positionsfeld |
Im Folgenden sind die möglichen Werte für ein UNIMARC/CNMARC 1XX-Feld mit fester Position aufgeführt:
Nur relevant für UNIMARC/CNMARC 1XX Felder. |
| CONDITION auf Datensatz-Ebene | Die folgenden Optionen sind mögliche Konditionen: Wichtige Informationen erhalten Sie im nächsten Abschnitt (Bedingungen).
Im Folgenden sind die möglichen Bedingungsoptionen aufgeführt, die nur für UNIMARC/CNMARC 1XX-Felder relevant sind:
|
Bedingung
Bedingungen können auf der gesamten Regel-Ebene definiert werden (WHEN), oder auf einer bestimmten Aktions-Ebene (IF). Dieselbe Bedingung verhält sich unterschiedlich, abhängig davon, auf welcher Ebene sie definiert wird.
- WENN-Klausel – Eine Bedingung, die vom gesamten Datensatz erfüllt werden muss, um festzulegen, ob der Datensatz für die Anwendung der Regel in Frage kommt
- WENN (innerhalb einer Aktion) - Eine Bedingung, die auf ein einzelnes Feld anwendbar ist, um festzulegen, ob die bestimmte Aktion für dieses Feld ausgeführt wird
Bedingungen können sein:
-
containsScript – Verwenden Sie diese Bedingung, um eine bestimmte Sprache zu erkennen. Die Bedingung containsScript verwendet die folgende feste Liste von Sprachen, die Sie überprüfen können: Arabisch, Armenisch, Bengalisch, Bopomofo, Blindenschrift, Buhid, Kanadische Ureinwohner, Cherokesisch, Kyrillisch, Devanagari, Äthiopisch, Georgisch, Griechisch, Gujaratisch, Gurmukhi, Han, Hangul, Hanunoo, Hebräisch, Hiragana, Übernommen, Kannada, Katakana, Khmer, Laotisch, Latein, Limbu, Malayalam, Mongolisch, Myanmar, Ogham, Oriya, Runen, Singhalesisch; Syrisch, Tagalog, Tagbanwa, TaiLe, Tamil, Telugu, Thaana, Thailändisch, Tibetisch und Yi. Siehe das folgende Syntaxbeispiel:rule "Is CJK in Authority"
when
containsScript "Han" "1**"
then
set indication."true"
end -
existiert <element> – Zumindest eine Entsprechung wurde gefunden
- existiert <element> – Ist für Datenfelder anwendbar. Bei Verwendung in einer WENN-Klausel müssen sowohl das Aktionselement als auch das durch die Bedingung getestete Element im selben (Daten-)Feld sein.
- Kontrollfeld existiert <element> – Ist für Kontrollfelder anwendbar. Bei Verwendung in einer WENN-Klausel müssen sowohl das Aktionselement als auch das durch die Bedingung getestete Element im selben (Kontroll-)Feld sein.
-
existiert mehr als einmal <element> – Mehrere Übereinstimmungen wurden gefunden. Gilt für Datenfelder. Bei Verwendung in einer WENN-Klausel müssen sowohl das Aktionselement als auch das durch die Bedingung getestete Element im selben (Daten-)Feld sein.
-
existiert nicht <element> – Es wurde keine Entsprechung gefunden
- existiert nicht <element> – Ist für Datenfelder anwendbar. Bei Verwendung in einer WENN-Klausel müssen sowohl das Aktionselement als auch das durch die Bedingung getestete Element im selben (Daten-)Feld sein.
- Kontrollfeld existiert nicht <element> – Ist für Kontrollfelder anwendbar. Bei Verwendung in einer WENN-Klausel müssen sowohl das Aktionselement als auch das durch die Bedingung getestete Element im selben (Kontroll-)Feld sein.
-
recordHasDuplicateSubfields (für Anzeigeregeln; siehe Arbeiten mit Anzeigeregeln) – Gibt richtig aus, wenn für den aktuellen Datensatz duplizierte Unterfelder (Unterfeld und seine Inhalte) nach den Feldern, Unterfeldern und der Zeichenfolge der zu ignorierenden Zeichen (charsToIgnore) gefunden wurden, die als Parameter im folgenden Format durchlaufen wurden:recordHasDuplicateSubfields "<tag>" "<code>" "<charsToIgnore>"Messing können mehrere Feldcodes (Felder) angegeben werden, getrennt durch Kommas. Es können mehrere Codes (Unterfelder) angegeben werden, ohne Leerzeichen zur Trennung. Es können ein oder mehrere Zeichen (alphanumerisch oder Interpunktion) ohne Leerzeichen zur Trennung als Zeichen festgelegt werden, die am Ende des Inhalts in den Unterfeldern, die nach Duplikation bewertet werden, ignoriert werden sollen. Für weitere Informationen siehe Beispiel 6.Für die Datensätze, die die Bedingung recordHasDuplicateSubfields erfüllen (als richtig ausgegeben werden), wird ein Set der Datensätze erstellt.
Jede IF-Klausel kann eines der folgenden Formate haben:
- Anwendbar, wenn eine bestimmte Bedingung nicht richtig ist, zum Beispiel: addControlField "{element}" if(not exists "{condition}")
- Anwendbar, wenn eine bestimmte Bedingung richtig ist, zum Beispiel: addControlField "{element}" if(exists "{condition}")
- Bedingungslos anwendbar, zum Beispiel: addControlField "{element}"
Der Boole’sche ODER Operator kann in Konsequenz-Aussagen mit Verwendung des Pipe (|) Symbols verwendet werden, zum Beispiel: removeField "866" wenn (nicht existiert "866.8.0|99") Wenn das Pipe-Symbol Teil des Wertes ist, verwenden Sie vier Backslashes (\\\\) , um ihm zu entgehen, zum Beispiel: removeField "866" wenn (existiert "866.8.0\\\\|99")
Es gibt ein bekanntes Problem, bei dem das "|" nicht enthalten ist. Dies wird in den nachfolgenden Versionen behoben.
Liste der Aktionen
Die folgende Tabelle bietet eine Liste mit verfügbaren Aktionen.
| Aktion | Format/Beispiel | Anmerkung |
|---|---|---|
| Felder und Unterfelder durch andere Felder und Unterfelder ersetzen |
changeControlField "<tag>" to "<new tag>"
Beispiel: changeControlField "007" to "008"
|
Ändert die Feldcode-Kennung eines Kontrollfeldes; ändert keine Inhalte. |
|
changeField "<tag>" to "<new tag>"
Beispiel: changeField "245" to "246"
|
Ändert die Feldcode-Kennung; ändert keine Indikatoren oder Unterfelder. | |
|
changeSubField "<tag>.<code>" to "<new code>"
changeSubFieldOnlyFirst "<tag>.<code>" to "<new code>"
changeSubFieldExceptFirst "<tag>.<code>" to "<new code>"
Beispiel: changeSubField "035.b" to "a"
|
Ändert die Unterfelder (oder nur das erste Unterfeld oder alle mit Ausnahme des ersten Unterfeldes) "<code>" zum Unterfeld "<new code>" im Feld"<tag>". | |
|
changeFirstIndicator "<tag>" to "<value>"
changeSecondIndicator "<tag>" to "<value>"
Beispiel: changeFirstIndicator "245" to "3"
|
Stellt den Wert des festgelegten Indikators in Feldcode <tag> ein. | |
|
combineFields "<tag>" mit Ausnahme "<comma-separated subfield list>"
Beispiel: combineFields "852" excluding "a,b"
|
Kombinieren Sie alle Felder mit der spezifizierten Nummer. Alle Unterfelder aus der zweiten und den folgenden Zeilen in die erste Zeile kopieren, unter Ausschluss von genannten Unterfeldern; nur die ersten Vorkommen von ausgeschlossenen Unterfeldern werden kopiert, und nur wenn sie nicht bereits in der ersten Zeile existieren. | |
| Felder und Unterfelder hinzufügen |
addField "<tag>.<code>.<value>"
HinzufügenFeld "<tag>.{<ind1>,<ind2>}.<code>. <Wert>"
Biespiel: addField "999.a.RESTRICTED"
|
Fügt das Feld dem MARC-Satz hinzu. Stellt den Wert des Unterfeldes auf den angezeigten Wert ein. |
|
addControlField "<tag>.<value>"
Biespiel: addControlField "008.820305s1991####nyu###########001#0#eng##"
|
Fügt das Kontrollfeld dem MARC-Satz hinzu. | |
|
HinzufügenUnterfeld "<tag>.<code>.<value>"
HinzufügenUnterfeld "<tag>.{<ind1>,<ind2>}.<code>.<value>"
Biespiel: addSubField "245.h.[Journal]"
|
Fügt das Unterfeld <code> mit dem Wert <value> dem Feld <tag> hinzu. Wenn das Feld nicht existiert, geschieht nichts. | |
|
HinzufügenSystemNummer "<element>" von "<tag>" mit Präfix "<prefix tag>"
Biespiel: addSystemNumber "035.a" from "001" prefixed by "003"
|
Gleicht das Datenfeld <element> den Inhalten des zweiten Kontrollfeldes <prefix tag> in Klammern an, gefolgt von den Inhalten des ersten Kontrollfeldes <tag>.
Wenn beispielsweise 001 den Wert 9945110100121 und 003 den Wert DAV hat, ergibt die Bedingung im Beispiel links 035 mit dem Wert ‡(DAV)9945110100121.
|
|
| Felder kopieren |
copyField "<tag>" to "<new tag>"
copyField "<tag>.<code>" to "<new tag>.<new code>"
copyField "<tag>" to "<new tag>.{<ind1>,<ind2>}"
Beispiel: copyField "971.a" to "100.u"
|
Kopiert das Feld zu einem anderen Feld. In der ersten Version sind die Unterfelder nicht festgelegt (<code> und <new code>) und das neue Feld enthält dieselben Unterfelder wie das alte Feld. Wenn in der zweiten Version nur <new code > nicht festgelegt ist, ist das neue Unterfeld dasselbe wie das durch <code> festgelegte.
copyField erstellt ein eigenes Feld, anstatt es zu einem vorhandenen Feld hinzuzufügen. Sie können das neue Feld mit allen vorhandenen Feldern kombinieren (siehe combineFields).
|
| Felder und Unterfelder entfernen |
EntfernenKontrollfeld "<tag>"
Beispiel: removeControlField "009"
|
Entfernt alle Ereignisse des Kontrollfeldes.
Beachten Sie: Wenn Sie das Kontrollfeld 008 entfernen, wird es von Alma sofort neu erstellt, wenn Sie es nicht neu erstellen. Regel "remove 008"
when (TRUE) then removeControlField "008" addControlField "008.######s2013####xx######r#####000#0#eng#d" end |
|
EntfernenFeld "<tag>"
Beispiel: removeField "880"
|
Entfernt alle Ereignisse des Feldes <tag>. | |
|
EntfernenUnterfeld "<tag>.<code>"
Beispiel: removeSubField "245.h"
|
Entfernt alle Ereignisse des Unterfeldes <code>vom angezeigten Feld. | |
| Text in Feldern oder Unterfeldern ersetzen |
ErsetzenKontrollinhalte "<tag>.{<position>,<length>}. <value>" with "<new value>"
Beispiel: replaceControlContents "LDR.{7,1}.s" with "m"
|
Ersetzt <value> mit "<new value>" in der Startposition <position> auf <position>+<length> des Kontrollfeldes <tag>. Ersetzt nur den Text, der mit <value> übereinstimmt. |
|
replaceContents "<tag>.<code>.<value>" with "<new value>"
replaceContentsOnlyFirst "<tag>.<code>.<value>" with "<new value>"
replaceContentsExceptFirst "<tag>.<code>.<value>" with "<new value>"
Beispiel: replaceContents "245.h.[Journal]" with "[Book]"
|
Ersetzt die übereinstimmenden Zeichenfolgen (oder nur die erste auftretende, übereinstimmende Zeichenfolge im ersten übereinstimmenden Unterfeld oder alle Zeichenfolgen in allen übereinstimmenden Unterfeldern mit Ausnahme des ersten übereinstimmenden Unterfeldes) <value> im Unterfeld <code> des Feldes "<tag>" mit "<Neuer Wert>". Die Zeichenfolge oder der Teil der Zeichenfolge, der nicht mit <value> übereinstimmt, wird nicht geändert. | |
|
ErsetzenUnterfeldInhalte "<tag>.<code>" mit "<tag>.<code>"
Beispiel: replaceSubFieldContents "245.b" with "100.a"
|
Ersetzt die Inhalte des Unterfeldes durch die Inhalte eines anderen Unterfeldes. | |
|
replaceFixedContents "<tag>.{<1_ind>,<2_ind>}.<code>.{<position>,<length>}.<value>" with "<new value>" Beispiel: replaceFixedContents "100.{1,2}.a.{0,8}.20150226" with "20220724" |
Ersetzt <value> durch <new value> in UNIMARC und CNMARC 1XX Feldern mit fester Position. Nur relevant für UNIMARC/CNMARC 1XX Felder. |
|
| Text in Unterfeldern hinzufügen
|
PräfixFür "<tag>.<code>" mit "<value>"
Biespiel: prefix "035.b" with "(OCoLC)"
|
Fügt ein Präfix an den Wert des Unterfeldes "<code>" im Feld "<tag>" hinzu.
Der neue Wert wird <value> sein, gefolgt vom alten Wert.
|
|
prefixSubField "<tag>.<code>" with "<source tag>.<source code>"
Biespiel: prefixSubField "910.a" with "906.a"
|
Fügt den Wert des Unterfeldes "<source code>" im Feld "<source tag>" als Präfix zum Unterfeld "<code>" im Feld "<tag>" hinzu.
Der neue Wert wird der Wert des Unterfeldes "<source code>" im "<source tag>" sein, gefolgt vom alten Wert.
|
|
|
SuffixFür "<tag>.<code>" mit "<value>"
Biespiel: suffix "035.b" with "(OCoLC)"
|
Fügt dem Wert von Unterfeld "<code>" ein Suffix im Feld "<tag>" hinzu.
Der neue Wert wird der alte Wert sein, gefolgt von <value>.
|
|
|
suffixSubField "<tag>.<code>" with "<source tag>.<source code>"
Beispiel: suffixSubField "910.a" with "907.c"
|
Fügt den Wert des Unterfeldes "<source code>" im Feld "<source tag>" als Suffix zum Unterfeld "<code>" im Feld "<tag>" hinzu.
Der neue Wert wird der alte Wert sein, gefolgt vom Wert des Unterfeldes "<source code>" im Feld "<source tag>".
|
|
| Verwalten von Agentur-Informationen in Titelsätzen und Normdatensätzen
Diese Syntax kann zum Beispiel in Normalisierungsregeln, die in der Aufgabenliste der Metadaten-Konfiguration für MARC 21-Titeldaten ausgewählt wurden, verwendet werden, um Titeldaten in der Netzwerkzone beim Speichern zu normalisieren.
Diese Funktion ist in Arbeit. Bitte kontaktieren Sie den Ex Libris Support, um diese Syntax zu aktivieren.
|
addCreatingAgency "<tag>.<code>"
Beispiel: addCreatingAgency "040.a"
|
Fügt den ISIL-Code der erstellenden Agentur zum Unterfeld in "<code>" im Feld "<tag>" hinzu. |
|
addModifyingAgency "<tag>.<code>"
Beispiel: addModifyingAgency "040.d"
|
Fügt den ISIL-Code der Modifizierungs-Agentur zum Unterfeld in "<code>" im Feld "<tag>" hinzu. Wenn bereits eine Modifizierungs-Agentur in "<tag>.<code>" vorhanden ist, wird ein weiterer Agentur-ISIL-Code hinzugefügt. | |
|
replaceModifyingAgency "<tag>.<code>"
Beispiel: replaceModifyingAgency "040.d"
|
Fügt den ISIL-Code der Modifizierungs-Agentur zum Unterfeld in "<code>" im Feld "<tag>" hinzu. Sollten bereits Modifizierungs-Agenturen in "<tag>.<code>" existieren, werden alle ersetzt. | |
| Teilen Unterfelder |
splitSubField "<tag>.{ind1,ind2}.<code>.<delimiter>" to "<tag>.{<ind1>,<ind2>}.<code>" addSeq "<code>"
Beispiel 1: splitSubField "866.a.;" to "555.{0,0}.a" addSeq "8"
Beispiel 2: splitSubField "555.a. – " to "859.{0,0}.a" addSeq "8"
Beispiel 3: splitSubField "859.a.\\\\."
Beispiel 4: splitSubField "999.a.;" to "555.a" addSeq "8"
|
Dieser Feldcode ist ein Pflichtfeld.
Die Indikatoren sind optional.
Das die Teilung auf Unterfeld-Ebene erfolgt, ist der Code ein Pflichtfeld.
Der Begrenzer kann eine beliebige Zeichenfolge sein. Wenn der Begrenzer nicht existiert, wird das gesamte Unterfeld als mit dem ersten (und einzigen) Vorkommen kopiert und die Sequenz wird hinzugefügt.
Die Komponente bis ist optional. Wenn sie festgelegt wird, werden mehrere Vorkommen mit dem Feldcode bis erstellt, jeweils mit den Daten bis zum Begrenzer. Siehe die Beispiele 1 und 2. Wenn die Komponente bis nicht festgelegt wird, wird das Unterfeld auf die zusätzlichen, selben Unterfelder im selben Feld aufgeteilt, wie im Beispiel 3 dargestellt.
Die Komponente addSeq ist optional. Sie ist nicht relevant, wenn die Komponente bis nicht festgelegt ist. Wenn addSeq festgelegt wird, wird das Unterfeld mit einer Sequenz hinzugefügt, wie in Beispiel 1; und wenn das Unterfeld im Originalfeld bereits existiert, wird eine Sequenz (mit einem vorangestellten Punkt) zu diesem Feld hinzugefügt, wie in Beispiel 2.
|
|
correctDuplicateSubfields "<tag>" "<code>" Beispiel: Entfernt duplizierte Unterfelder x, y und z aus den Feldern 610 und 630. |
Korrigiert duplizierte Unterfelder (beispielsweise Unterfelder mit demselben Code UND demselben Wert), indem das erste Ereignis beibehalten und die anderen entsprechend den als Parameter übergebenen Feldern und Unterfeldern aus dem aktuellen Datensatz entfernt werden. Sie können recordHasDuplicateSubfields verwenden, um den Satz zu erstellen, den Sie für Ihre Normalisierungsregel angeben, die correctDuplicateSubfields verwendet. Für weitere Informationen siehe Beispiel 6. Für die Deduplizierung von Unterfeldern mit unterschiedlichen Werten siehe:
|
|
|
moveSubfieldsToEndOfField "<tag>" "<code>" Beispiel: Verschiebt Unterfelder 9 und 2 an das Ende des Feldes 650. |
Verschiebt das erste Vorkommen jedes Unterfelds an das Ende des Felds und entfernt alle anderen Vorkommen des gleichen Unterfelds. Wenn mehr als ein Unterfeld angegeben wird, werden diese am Ende in derselben Reihenfolge wie in der Regel angegeben angezeigt. In diesem Beispiel wird das Unterfeld 9 am Ende gefolgt von Unterfeld 2 eingefügt. Beachten Sie, dass die if-Anweisung von der Aktion moveSubfieldsToEndOfField nicht unterstützt wird. |
|
|
Doppelte Felder für den aktuellen Datensatz korrigieren |
correctDuplicateFields "{fields}" Beispiel: correctDuplicateFields "610,630,650" |
Diese Aktion verwendet einen Parameter, Felder, der durch Kommata getrennte Feldwerte enthält, z. B. 610.630.650. Diese Aktion korrigiert doppelte Felder für den aktuellen Datensatz entsprechend den Feldern, die als Parameter übergeben wurden. |
|
Doppelte Felder finden (Anzeigeregeln; siehe Arbeiten mit Anzeigeregeln) |
recordHasDuplicateFields "{fields}" Beispiel: recordHasDuplicateFields "610,630,650" |
Diese Aktion verwendet einen Parameter, Felder, der durch Kommata getrennte Feldwerte enthält, z. B. 610.630.650. Diese Aktion kann entweder richtig oder falsch sein. Es wird Richtig zurückgegeben, wenn für den aktuellen Datensatz gemäß den als Parameter übergebenen Feldern doppelte Felder gefunden wurden. |
Platzhalter und Sonderzeichen
Während die Verwendung regulärer Ausdrücke in den Alma-Normalisierungsregeln derzeit nicht vollständig unterstützt wird, können einige reguläre Ausdrücke verwendet werden – Beispiele hierfür finden Sie unter Alma-Beispiele - Normierungsregel.
Das Unterfeld-Trennzeichen ($$) darf nicht in der Regel vorkommen, auch nicht im Regelnamen.
Ein Rautenzeichen (#) am Beginn einer Zeile zeigt an, dass der Rest der Zeile ein Kommentar ist und bei der Verarbeitung der Regel ignoriert wird.
Das Sternchen (*) wird verwendet, um eine Zeichenfolge abzugleichen, einschließlich einer Zeichenfolge mit der Länge Null. Beispiel: "<tag>.<*>.<value>" ist auf alle Unterfelder im Feldcode <tag> anwendbar, die den Wert <value> haben. * ist "gierig" und stimmt mit so vielen Zeichen wie möglich in der Satzfolge überein. Zum Beispiel: wenn Sie eine Zeichenfolge "a b c b d b e" haben, stimmt das Muster "b*b" mit "b c b d b" überein, nicht nur mit "b c b".
Leere Indikatoren (jedoch nicht Felder oder Unterfelder) werden mit Bindestrich angezeigt (-). Beispiel: "<tag> {-,<ind2>}" liefert alle Felder, in welchen der MARC-Feldcode <tag> ist, der erste Indikator nicht definiert, und der zweite Indikator <ind2> ist.
Wenn der Text eines Unterfeldes einen Punkt als letztes Zeichen enthält, verwenden Sie vier Backslashes, um mit dem Punkt übereinzustimmen. Beispiel:
rule "Replace '1 v.' to 'Leaves' in $a (unconditional)"
when
(TRUE)
then
replaceContents "300.a.1 v\\\\." mit "Leaves"
Ende
when
(TRUE)
then
replaceContents "300.a.1 v\\\\." mit "Leaves"
Ende
Doppelte Anführungszeichen können (nur) in Bedingungen verwendet werden. Um doppelte Anführungszeichen als Teil einer Bedingung zu verwenden, verwenden Sie einfache Anführungszeichen (') anstelle von doppelten Anführungszeichen ("), um den Text in der Regel zu umschließen. Auf diese Art können Sie doppelte Anführungszeichen innerhalb des Textes auch nach einem doppelten Backslash (\\) verwenden.
Regel "populate 008 7-10 2016"
wenn
(existiert '245.{*, }.c.\"')
dann
replaceControlContents "008.{7,4}" mit "2016"
Ende
wenn
(existiert '245.{*, }.c.\"')
dann
replaceControlContents "008.{7,4}" mit "2016"
Ende
Hebräische Daten können (nur) in Bedingungen verwendet werden. (Im Hebräischen wird von rechts nach links gelesen, sodass die doppelten Backslashes im folgenden Beispiel tatsächlich vor den doppelten Anführungszeichen stehen.)
rule "populate 008 7-10 2016"
when
((exists '260.{*, }.c.תשע\\"ו') OR (exists '264.{*, }.c.תשע\\"ו'))
then
replaceControlContents "008.{7,4}" with "2016"
end
when
((exists '260.{*, }.c.תשע\\"ו') OR (exists '264.{*, }.c.תשע\\"ו'))
then
replaceControlContents "008.{7,4}" with "2016"
end
- Platzhalter können nicht als erstes Zeichen einer Bedingung oder eines Wertes verwendet werden.
- Um einen liberalen Backslash zu verwenden (\), schützen Sie ihn durch einen weiteren Backslash: \\.
- Verwenden Sie vier Backslashes (\\\\), um einen Punkt zu schützen, wenn dieser das letzte Zeichen in der Zeichenfolge ist. Wenn dem Punkt unmittelbar ein anderes Zeichen folgt, sind keine vier Backlashes erforderlich (wie in addField "907.a.F.L.T\\\\."). Allerdings ist es die beste Vorgehensweise, die vier Backlashes immer in der Normalisierungsregel zu verwenden, um die gewünschten Ergebnisse so einheitlich wie möglich zu gestalten. Siehe die nachfolgenden Beispiele.
- Wie oben erwähnt, wenn ein doppeltes Anführungszeichen (nur) in einer Bedingung verwendet wird, die mit einfachen Anführungszeichen geschützt wird, oder wenn ein einfaches Anführungszeichen in einer Bedingung verwendet wird, die mit einfachen Anführungszeichen geschützt wird, müssen Sie das doppelte bzw. einfache Anführungszeichen weiters mit einem doppelten Backslash schützen.
- Wenn das Pipe-Symbol Teil der Bedingung ist, verwenden Sie vier Backslashes (\\\\) , um es zu schützen, zum Beispiel: EntfernenFeld "866" wenn (existiert "866.8.0\\\\|99"). Dies ist nur erforderlich, wenn in der Bedingung ein Pipe-Symbol verwendet wird.
Beispiel: Verwenden des Punktes in einer Normalisierungsregel mit ErsetzenInhalte
Beispiel eines Datensatzes mit Punkten:
245 00 $$a Feminist literary theory. : $$b a reader / $$c bearbeitet von Mary Eagleton.
246 0# $$a F.L.T.
Normalisierungsregel für das Datensatz-Beispiel oben:
Regel "die Punkte in 245 und 246 Unterfeld a entfernen (und die Punkte mit nichts ersetzen); den Punkten vier Backslashes voranstellen"
wenn
(RICHTIG)
dann
InhalteErsetzen "245.a.\\\\." mit ""
InhalteErsetzen "246.a.\\\\." with ""
Ende
wenn
(RICHTIG)
dann
InhalteErsetzen "245.a.\\\\." mit ""
InhalteErsetzen "246.a.\\\\." with ""
Ende
Siehe die Abbildung unten für die Vorher-Nachher-Beispiele.
Vorher-Nachher-Beispiele
Beispiel: Verwenden des Punktes in einer Normalisierungsregel mit HinzufügenFeld
Nachfolgend sehen Sie ein Beispiel eines Datensatzes, in dem Punkte hinzugefügt werden müssen:
906 $$a Architecture.
907 $$a F.L.T.
Unten sehen Sie die Normalisierungsregel für das Datensatz-Beispiel oben, unter Verwendung der besten Vorgehensweise, immer Slashes hinzuzufügen:
Regel "Feld 906 mit Text Architektur und Punkt am Ende hinzufügen und auch Feld 907 mit F.L.T. hinzufügen"
Salienz 100
wenn
RICHTIG
dann
Hinzufügen "906.a.Architecture\\\\."
FeldHinzufügen "907.a.F\\\\.L\\\\.T\\\\."
Ende
Salienz 100
wenn
RICHTIG
dann
Hinzufügen "906.a.Architecture\\\\."
FeldHinzufügen "907.a.F\\\\.L\\\\.T\\\\."
Ende
Siehe die Abbildung unten für die Vorher-Nachher-Beispiele des Datensatzes.
Vorher-Nachher-Beispiele
Beispiel - Normierungsregel
Für eine Liste mit mehr als 100 Beispielen für Normalisierungsregeln und andere Dokumente siehe Beispiele für Alma-Normalisierungsregeln.