[datenformate] Nichtsortierzeichen bei Praefixen in Personennamen via RDF

Bernhard Eversberg ev at biblio.tu-bs.de
Thu May 15 09:41:10 CEST 2014


Am 14.05.2014 16:52, schrieb Jakob Voß:
>
> Ich kann und will keine Beweise liefern
Das ist schade, denn es geht ja doch um weitreichende und viel Aufwand
verursachende Entwicklungen und Entscheidungen, und da wär's halt
hilfreich, man könnte sich auf halbwegs schon erprobtem,
aussichtsreichem Grund bewegen.

> sondern nur aus meiner Erfahrung berichten:
Vorweg: Es klingt alles moderat und vernünftig, was Sie da äußern, und
die meisten Entwickler werden es sicher gern unterschreiben.
Ein paar Worte will ich mir dennoch nicht versagen:

>
> * dass alle Techniken zur Kodierung von Daten ihre Vor- und Nachteile
> haben, die je nach Anwendungsfall zu bewerten sind
>
Schon wahr, wir sind aber auf praktikable, ökonomische Lösungen mit
Augenmaß angewiesen, die sich einheitlich anwenden lassen und nicht
fallweise mal so und mal anders.

> * dass konzeptuelle Fragen (z.B. was ist ein Nichtsortierzeichen?) viel
> schwieriger sind als Fragen der konkreten Kodierung
>
Die Sache mit den Nichtsortierzeichen ist *nicht* schwierig, man kann
sie allerdings schwierig *reden*. (Das gelingt, wie in vielen anderen
Fällen, besonders gut dem Kollegen Berger. Aber gut, gründliche
theoretische Auslotung ist auch wichtig.) Schauen Sie sich an, was
das RDA-Expertengremium alles diskutiert und entscheidet oder an
Arbeitsgruppen delegiert, da kriegen Sie einen Eindruck, was schwierig
ist:
   http://www.rda-jsc.org/workingnew.html
Die Kodierung der Nichtsortierzeichen ist nicht schwierig, und hier
*kann* man aus Erfahrung reden. Es sei denn, man ist auf XML bzw. RDF
und eine damit verbundene reine Lehre fixiert.

> * dass ich mit zeitgemäßen Techniken, die auch außerhalb des
> Bibliothekswesens etabliert sind, schneller und motivierter zu
> Ergebnissen komme
>
Schön, und Motivation und Etablierung sind selbstredend wichtig, doch
sind dies keine wirklich an der Sache orientierten Kriterien, und auch
nicht an Effizienz und Eleganz. Und es geht nicht um irgendwelche
Ergebnisse, sondern um gute und praktikable.

> * dass es zweitrangig ist, ob Technik A besser als Technik B ist, wenn
> Technik B dafür besser von aktuellen Umgebungen (Programmiersprachen,
> Betriebssystemen, Uniabsolventen...) unterstützt wird
>
Hm, dem kann ich nicht uneingeschränkt zustimmen. Wenn Technik A
klar bessere Eigenschaften für das Problem hat als Technik B, dann ist
Technik A zu nehmen, wenn es um weitreichende oder ökonomisch
schwerwiegende Fragen geht.
Ferner *könnte* man aus diesem Statement auch heraushören:
"Ich mach das, was ich nun mal gelernt habe, damit kann man fast
alles gut lösen und das ist immerhin mainstream".
Klar, es bleibt einem Entwickler oftmals angesichts des Zeitdrucks
nichts anderes übrig, und zumal wenn man kooperieren muß mit
anderen und deren Akzeptanz braucht. Optimale Lösungen brauchen aber
manchmal unorthodxes Vorgehen und mehr Freiraum, und Mut zu dessen
Nutzung. Der große Wurf, m.a.W., gelingt bekanntlich meistens denen,
die nicht immer schnurgerade auf den ausgetretenen Pfaden wandeln.
Und im Mainstream, auch das ist bekannt, schwimmen viele tote
Fische und gelangt man schließlich raus ins offene Meer, wo die
Haie lauern.

> was aus meinen Erfahrungen für andere folgt bleibt jeder/jedem selbst
> überlassen.
>
Eine konziliant klingende salvatorische Klausel, mit der man in
freundlicher Form wenig anderes sagt als
"Macht was ihr wollt, ist mir wurscht, ich seh das so und basta".

Schönen Gruß
B.Eversberg



More information about the datenformate mailing list