[Allegro] Umgang mit Mehrfachkennung (Mehrfachkategorien)

[Bernhard Eversberg]

Am 02.07.2013 16:55, schrieb Sibylle Koczian:
> Lieber Herr Eversberg, liebe Liste,
>
> Am 02.07.2013 11:43, schrieb Bernhard Eversberg:
>> Erknobeln Sie derweil, sich Zeit lassend, ein neues, konkretes, ganz
>> andersartiges Konstrukt für Ihre beschriebene, andersartige
>> Anforderung, dann können wir reden.
>> Übrigens wären var ~kk und var ~k aus unserer unmaßgeblichen, weil
>> durch zu wenig Bedenkenqualm unvernebelten Sicht die einfachsten
>> Konstrukte für die Ihnen vorschwebenden (in mehr als 10 Jahren noch nie
>> formulierten) Aufgaben.
>>
>
> Ich bin verwirrt. Ist denn nicht das von H. Berger als nützlich in die
> Debatte geworfene Konstrukt "nächstes Mehrfachfeld"

Wozu eigentlich wäre das nützlich?

>
> Ich bin nicht sicher, ob der Bedarf beim Standardschema vielleicht
> gering ist oder nicht besteht, weil dort doch viele
> Wiederholungskategorien verschiedene Bedeutungen für die einzelnen
> Fortsetzungszeichen kennen.
Das ist das eine, das andere die Tatsache, daß bei den ganz normalen
Bibliotheksanwendunden, wie sie typisch sind für die A-Anwender,
generell kein Bedarf für extremere Mehrfachbelegungen besteht und
außerdem auch oft die simplere Wiederholung innerhalb von Feldern mit
Trennzeichen ; oder Strg+t genutzt wird.
Es sind die etwas individuelleren Projekte abseits der gewöhnlichen
Katalogisierung, die gelegentlich einen exorbitanten Bedarf entwickeln
für Feldwiederholungen. Dafür sollte man sich vielleicht in Zukunft
den Namen BIBFRAME merken in Kombination mit Linked Data und RDF
Triples. Da wäre z.B. jedes einem Objekt zugeordnete Schlagwort ein
getrennt gespeichertes Triple, welches aussagen würde: Objekt 123 hat
das Schlagwort XYZ, und mehr nicht. Ein Triplestore kann zu jedem Objekt
beliebig viele solche Statements enthalten, aber Mehrfachkennungen
gibt es da gar nicht. Wie ja auch im echten MARC21 die wiederholbaren
Felder keine Mehrfachkennung besitzen! Dies ist mit allegro ja auch
so nicht abbildbar.


B.E.