AW: [datenformate] Nichtsortierzeichen bei Praefixen in Personennamen via RDF

Tue May 13 14:34:06 CEST 2014

Lieber Herr Berger,
liebe Liste,

das Thema der Nichtsortierzeichen steht irgendwie am Schnittpunkt zwischen Regelwerken, Normdaten, Datenformaten und Zeichensaetzen, auf eine Art, die es schwer macht, einfache Antworten zu geben.  Zudem ist auch hier auf den unterschiedlichen Ebenen so viel in Bewegung -- ich kann also nicht auf Anhieb alle Aspekte abdecken (ich muesste sonst eine extrem lange Nachricht verfassen, die dann - zu Recht - keiner liest).  Allerdings gebe ich auch zu, dass es kritische Stimmen zu den Nichtsortierzeichen gab und gibt - braucht man die denn wirklich noch, oder gibt es nicht bessere Loesungen, oder kann das Thema nicht mal abgeschlossen und von da an ignoriert werden?

Also, ich versuch's mal so:

Fuer mich gibt es einen (zumindest graduellen) Unterschied bei der Abbildung von Personen-Namen mit nichtsortierenden Bestandteilen einerseits, und von Titeln und aehnlichen Angaben.  In Pica gesprochen:  Es gibt bei Namen wie

028A $dAnnette$cvon$aDroste-Hülshoff

alle notwendigen Unterfelder, und die Abbildung in MARC

100 1# $aDroste-Hülshoff, Annette <NSB>von<NSE>$d1797-1848

behilft sich mit dem Trennzeichen Komma+Blank zwischen Nachname und Vorname, und sie behilft sich mit den Nichtsortierzeichen um den Praefix herum.  Eigene Unterfelder dafuer in MARC zu bekommen ist nicht moeglich, aber die notwendigen Elemente sind da.

Bei den Titeln wie
4000 Die @Judenbuche
=
021A $aDie @Judenbuche
=>
245 10 $a<NSB>Die<NSE> Judenbuche
gibt es weder auf Pica- noch auf MARC-Seite ein eigenes Unterfeld, lediglich durch den Klammeraffen werden zwei Teil-Unterfelder gebildet, die dann auch in MARC als Teil-Unterfelder angelegt sind.

Ueber die Vorzuege dieser Loesung gegenueber dem international ueblichen
245 14 $aDie Judenbuche
sind wir uns wohl einig, man kann auch bei einem der folgenden Unterfelder nichtsortierende Bestandteile kennzeichnen, und mitten in einem Unterfeld (also nicht nur am Anfang) damit arbeiten.  Kombinationen aus z.B. Personen-Name und Titel-mit-Artikel-am-Anfang sind damit also erst moeglich.

Bei Titelangaben gibt es in ONIX die Vorrichtung <TitlePrefix> = <b030>, und <TitleWithoutPrefix> = <b031> -- macht also zwei getrennte Elemente.

Und MODS hat ein Element "<nonSort>", das bei Titeln und bei Schlagwoertern paarig angewendet werden kann -- wie die Control Character, nur dass nicht zwischen Anfang und Ende unterschieden wird.

Was die pure Abtrennung von Artikeln angeht -- da kann ich mir eine Loesung vorstellen, die markiert, in welcher Sprache der Titel oder allgemeiner das Element vorliegt -- dann kann man je Sprache mit recht hoher Sicherheit erkennen, was ein Artikel ist, und was nicht ("an" englisch vs. "an" deutsch"; etc.).  Damit entfiele die Notwendigkeit, ueberhaupt innerhalb des Titels, oder durch Auseinandernehmen des Titels, etwas per Format zu kennzeichnen, was anderweitig stoeren wuerde (egal ob als Control Character, oder "<nonSort>").

Die dumm sortierte Liste von Titeln:

A capella and more
A Christmas Carol
An Bord der Santa Clara
An Encounter in the Abyss
De anima
De Jammerlabbe
Des combats et des hommes
Des Sommers letzte Rose
Die another day
Die Trojaner
En Bourgogne
En Maietag
I am what I am
I Villani
Les and Larry Elgart and their orchestras
Les Papillons
Los geht's!
Los tiempos oscuros
O kolonializme
O Tannenbaum
To kill a Mockingbird
To mega therion
Un incontro pericoloso
Un wieder gieht e Jahr ze End

liesse sich damit recht zuverlaessig intelligent sortieren zu (erstes sortierendes Wort hier fett und unterstrichen):

A capella and more
An Bord der Santa Clara
A Christmas Carol
De anima
Des combats et des hommes
Die another day
En Bourgogne
An Encounter in the Abyss
I am what I am
Un incontro pericoloso
De Jammerlabbe
O kolonializme
Les and Larry Elgart and their orchestras
Los geht's!
En Maietag
To mega therion
O Tannenbaum
Les Papillons
Des Sommers letzte Rose
Los tiempos oscuros
To kill a Mockingbird
Die Trojaner
Un wieder gieht e Jahr ze End
I Villani

---

Zu RAK und RDA bin ich fuerchte ich nicht der Berufenste, da schreiben Sie ja schon das, was im Wesentlichen zu bedenken ist.

Auch zur Handhabung im Linked Data Service und in der GND kann ich nicht so viel sagen, ich habe aber Kollegen hier im Haus kontaktiert, die das abdecken, so dass wir uns ggf. noch mal melden.

Viele Gruesse

Reinhold Heuvelmann

--

Reinhold Heuvelmann
Deutsche Nationalbibliothek
Arbeitsstelle Datenformate
Adickesallee 1
D-60322 Frankfurt am Main
Telefon: +49 (0) 69 1525-1709
Telefax: +49 (0) 69 1525-1799
mailto:r.heuvelmann at dnb.de
http://www.dnb.de

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek ***

-----Ursprüngliche Nachricht-----
Von: datenformate-bounces at lists.dnb.de [mailto:datenformate-bounces at lists.dnb.de] Im Auftrag von Thomas Berger
Gesendet: Montag, 12. Mai 2014 17:09
An: Mailingliste Datenformate (frueher mab-list)
Betreff: Re: [datenformate] Nichtsortierzeichen bei Praefixen in Personennamen via RDF

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Heuvelmann,

> Nur damit klar ist, dass wir von demselben Sachverhalt sprechen:
>
> Aus Pica3
> 100 Droste-Hülshoff, Annette$cvon
>
> bzw. Pica+
> 028A $dAnnette$cvon$aDroste-Hülshoff
>
> wird in MARC 21
> 100 1# $aDroste-Hülshoff, Annette <NSB>von<NSE>$d1797-1848
> (die beiden verschiedenen Sonderzeichen habe ich hier mal mit NonSortBegin =
> NSB und NonSortEnd = NSE ausgedrueckt, in MARCXML muss Unicode benutzt werden,
> da weisen Sie ja auf die Codierungen U+0098 und U+009C schon hin).
>
> und im Linked Data Service der Deutschen Nationalbibliothek
> <gndo:preferredNameForThePerson>Droste-Hülshoff, Annette von</gndo:preferredNameForThePerson>
> <gndo:preferredNameEntityForThePerson rdf:parseType="Resource">
>       <gndo:forename>Annette</gndo:forename>
>       <gndo:prefix>von</gndo:prefix>
>       <gndo:surname>Droste-Hülshoff</gndo:surname>
> </gndo:preferredNameEntityForThePerson>
> (abrufbar, wie Sie auch sagen, unter
> http://d-nb.info/gnd/118527533
> oder direkt unter
> http://d-nb.info/gnd/118527533/about/rdf

soweit genau was ich meinte.

> Ich sehe also im LDS zusaetzlich zu
> gndo:preferredNameForThePerson
> auch noch eine sehr schoen granulare Darstellung
> gndo:preferredNameEntityForThePerson

das ist Ansichtssache: preferredNameEntityForThePerson gibt zwar denselben
Sachverhalt irgendwie noch einmal wieder, aber:

- - die praseentierte Reihenfolge gndo:forename gndo:prefix gndo:surname
  ist m.W. nicht Bestandteil von RDF und somit als "zufaellig"
  zu behandeln

- - der Bezug zur "invertierten" Form der Ansetzung ist i.A.
  komplex (uebliches Beispiel hierfuer Mao Zedong,
  < http://d-nb.info/gnd/118577425/about/rdf >), d.h. wenn ich
  gndo:forename und gndo:surname habe, weiss ich nicht, ob
  ich eine invertierte Ansetzung mit oder eine "natuerliche"
  ohne Komma zu bauen habe (und man sieht im Vergleich mit
  <gndo:prefix>d'</gndo:prefix> auch noch ein analoges Problem
  mit dem nicht immer zu setzenden Spatium, wenn man eine
  Lexikon-Lemma-artige nichtinvertierte Form bauen moechte: Das
  geht auch nicht so einfach... "Sauber" waere m.E. nur eine
  Loesung mit XML- statt Text-Datentyp und Mixed Content, das
  ist gerade in LD-Kreisen aber nicht wirklich beliebt ;-)

- - Inhaltlich ist es ohnehin fragwuerdig, die Konzepte Vorname/Nachname
  bzw. Persoenlicher Name/Familienname ueberdecken fuer sich genommen
  eben nie den gesamten Namensraum der persoenlichen Namen...

- - Bei gndo:variantNameForThePerson bzw. gndo:variantNameEntityForThePerson
  tut sich zudem die Schwierigkeit auf, dass "zusammengehoerige" Paare
  nicht als solche gekennzeichnet sind

Was also bleibt, und das hatte ich in der Tat uebersehen, weiss aber nicht,
ob ich die Muehe gerne auf mich nehme:

* Falls gndo:preferredNameEntityForThePerson ein Element gndo:prefix
  enthaelt, muss untersucht werden, ob das als Zeichenkette mit dem
  Ende von gndo:preferredNameForThePerson uebereinstimmt: in diesem
  Fall ist dieses Ende mit Nichtsortierzeichen auszustatten um zur
  "echten" Ansetzung zu gelangen.

> Wie es sich mit RDA verhaelt, das kann ich nicht beantworten; ich vermute
> aber, dass die Praefixe auch dort ein gueltiges Element sind, das es zu
> handhaben gilt.

Sie sind zwar irgendeine Form von Adelspraedikat, gelten aber nicht als
Fall von Adelstiteln und vergleichbarem fuer X00 $c. D.h. in allen Regelwerken
werden m.W. zwar Praefixe den Vornamen nachgestellt, allerdings ohne
zusaetzliche Auszeichnung. Die Nichtsortierzeichengeschichte hat allerdings
auch eher mit "Filing Rules" zu tun, die waren Bestandteil der RAK, jedoch
nicht von AACR2 und m.W. halten sich die RDA dementsprechend auch bedeckt. (Im
Umkehrschluss: Wenn eine Sonderbehandlung von Praefixen relevant fuer die ALA-
oder LC Filing Rules waeren, dann wuerden diese in MARC21 deutlicher
ausgezeichnet?)

Meiner Meinung nach spiegelt die RAK-Loesung mit Streichung der Sortier-
Relevanz von Praefixen Be- und Empfindlichkeiten, die Anfang des 20. Jhds.
hochaktuell und wichtig waren (staendig wurde jemand standeserhoben, einige
unterschieden subtil zwischen "v." und "von", ...), sowohl Index- als auch
Volltextsuchen werden dadurch aber eher erschwert. Persoenlich koennte ich
daher auch prima damit leben, wenn die Nichtsortierzeichen um die
nachgestellten Praefixe in Zukunft einfach verschwinden wuerden - fragt sich
nur, welche Instanz momentan ueberhaupt dafuer zustaendig ist, das zu regeln...

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iJwEAQECAAYFAlNw5BEACgkQYhMlmJ6W47O4dQP9EewmmR0LGyDbpKmgRmyDR1NI
HrnTK9MUrHFEYmrx+WNp54uyGIm6INnadVtzO1JUaL/l2Sp2uSaAvM96C0ZEa6+b
ahCvlJzG6etX1php5tA+Nb9NVkPwVmphHuJTKySwqaH1gZPcHFaR7fyKAwzbbDI4
JIGvHWNxbvHAWiULAS8=
=YYWL
-----END PGP SIGNATURE-----
_______________________________________________
datenformate mailing list
datenformate at lists.dnb.de<mailto:datenformate at lists.dnb.de>
http://lists.dnb.de/mailman/listinfo/datenformate