[Allegro] Anmerkungen zu i5=__

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

>> in Verlautbarung 163 oder 164 wurde vor ca. 10 Jahren eine Erweiterung
>> des Schluesselersetzungsmechanismus eingefuehrt (und gleichzeitig mit
>> der Aussage, dass man nicht vorhabe, die Standardparameter darauf
>> umzustellen, zurueckgenommen),
> Die Aussage "zurückgenommen" ist unlogisch, denn die Erweiterungkann ja
> ohne weiteres dort, wo es gewünscht ist, in die eigenen Parameter übernommen
> werden.

"eingeschraenkt" waere praezsiser gewesen ("kassiert" meinte ich auch
gar nicht). Jedenfalls war diese Aussage nicht besonders motivierend,
das neue Feature einzusetzen, daher passiert das bei mir erst jetzt.
[Analoges passierte in denselben Verlautbarungen zu den Unicode-
Funktionalitaeten: Es wurden direkt zwei, miteinander nicht kompatible
"Methoden" eingefuehrt und bis heute gibt es keine Aussage dazu, welches
denn die zukuenftige, offizielle sein koennte]



>> 2.) Ich hatte einen boesen Crash von index.exe, in einem langen
>> Textfeld eines Datensatz kam das Steuerzeichen durch einen Erfassungs-
>> fehler einfach vor, und zwar einige hundert Zeichen vor Feldende:
>> Das gab dann einen Ueberlauf in den entsprechenden Datenstrukturen,
>> die nur fuer Dinge dimensioniert sind, die man auch wirklich im Index
>> nachschlagen kann. Abgesehen davon, dass das bei Gelegenheit zu
>> beheben ist, frage ich mich, ob es eine tatsaechliche Einschraenkung
>> der Brauchbarkeit des Mechanismus waere, wenn das Programm sicherheits-
>> halber davon ausgehen wuerde dass solche "freien" Ersetzungsschluessel
>> keine Spatien enthalten.
>>
> Davor würde ich keine Scheu empfinden, denn es grenzt ja geradezu an Anarchie,
> solche
> Dinge zu tun, wie es LC anscheinend macht mit Spatien in und am Ende von
> Schlüsseln.

Diese Festlegungen sind zwar nicht unbedingt aelter als Computer, aber
datieren vermutlich lange vor der Erfindung von Copy&Paste. Und es ist
ja nicht untypisch fuer die Bibliothekswelt, dass solche Festlegungen
niemals modifiziert werden, selbst wenn sie heutzutage erwiesen
problematisch sind und ihr seinerzeitiger Nutzen sich nur noch aus
historischer Spekulation erschliesst. Zu LCCNs habe ich in anderem
Zusammenhang vor einiger Zeit einmal die relevanten Fakten zusammen-
getragen:
< http://www.wikidata.org/wiki/Property_talk:P244#Some_more_pointers >


> Schließlich sind das rein interne Angaben, denen man durchaus ein paar sinnvolle
> Restriktionen auferlegen kann und sollte.

Eigentlich wird der Mechanismus attraktiv dadurch, dass man dadurch in der
eigenen Datenbank solche Fremd-Identifier ohne weitere Modifikation
(abgesehen vom Umschliessen mit den Steuerzeichen) nutzen kann.

In MAB-Titeldaten vor der GND-Einfuehrung war es z.B. ganz klar, Feld
102a enthielt die PND-Nummer in der Form 123456789, seit der GND-
Einfuehrung gibt es die PND nicht mehr, MAB wurde als Format nicht
angepasst, die Verbuende liefern uneinheitlich mal (alle? PICA-Verbuende
102a 123456789
und mal (Aleph-Verbuende?)
102a (DE-588)123456789
letztere ist die "MARC-Form" der GND-Nummer und wird die alleinige Form
sein, sobald die Titeldatenlieferungen auf MARC21 umgestellt sein werden.

Nun ist die offizielle GND-"Nummer" weiterhin "123456789", dazu muss man
aber stets "GND" dazu sagen oder denken, sonst ist die Nummer eine
beliebige Nummer ganz ohne Bedeutung. Wenn ich solche Nummern fuer
Datentransport nutze, muss sie in den Titeldaten in einem dedizierten Feld
mit der Bedeutung "GND" reisen, bzw. begleitet von einem parallelen
Unterfeld. Und wenn ich sie intern fuer Verknuepfungen nutze, muss ich
sie bei Datenhaltung und Indexierung so verfremden (etwa durch
voranstellen von "gnd"), dass sie innerhalb meiner Anwendung nicht mit
anderen, "wirklich internen" Verknuepfungsnummern kollidiert.

Zu "(DE-588)123456789" muss man hingegen nur "MARC21-Oekosystem" dazu sagen
oder denken, dann ist der Rest klar. Solche Nummern kann ich in
Titel- und Normdatensaetzen transportieren, ohne das System zu kennen,
dem sie entstammen, die Syntax der Benennung (vorangestellt in '(...)')
ist durch die Vorschriften des Datenformats geregelt und es wird zudem
eine Registry gefuehrt (fuer hiesiges: die ISIL-Registry mitgenutzt),
die die konkreten Kennungen verwaltet, auch das ist im Format festgelegt.
Ich kann damit also "intern" mittels fast beliebigen Identifier
verknuepfen und muss nur insoweit etwas "kennen", als ich irgendwie
regeln muss, die Verknuepfungsziele auch in der eigenen Datenbank zu
haben. Und wie ich intern vorgehe, wenn ein Feld mir qua wiederholtem
$0 mehrere Verknuepfungsmoeglichkeiten anbietet.

Zurueck zu LCCN: Hier kenne ich leider kein Beispiel offizieller LC- oder
WorldCat- Daten mit "Verknuepfungen" (fuer "Authorities" und "Bandauf-
fuehrungen" wird das bekanntermassen ohnehin nicht gemacht, aber bei
Aufsaetzen und Serienstuecken besteht eine minimale Moeglichkeit, dass das
vorkommt), wo also eingeleitet durch "(DLC)" eine als solche qualifizierte LCCN
transportiert wird. Daher kann ich auch nicht beurteilen, ob Spatien darin
vorkommen, oder ob die halboffizielle "URI-Form" dort zum Einsatz kommt...

viele Gruesse
Thomas Berger