Re: [InetBib] Bedeutung von XML (war bibliojobs ... VAB)

[Thomas Berger <ThB@xxxxxxxxx>]

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

Lieber Herr Umstaedter, liebe Liste,

> Es wird also bezüglich XML auf drei Probleme ankommen:
> 1.    Mit welcher DTD kann man RDA am besten ausschöpfen (Verhältnis zu 
> JATS NISO Z39.96-2012 
> http://www.niso.org/apps/group_public/download.php/8975/z39.96-2012.pdf 
> )?

Ganz gewiss mit keiner DTD, denn dieses SGML-Konzept kann nur
monolithische "Datenformate" formulieren. Derzeit scheint aber
eher RDF Orientierung bei der Formatentwicklung zu bieten.
D.h. man will moegliche Beschreibungen nicht durch Vorab-Festlegungen
auf bestimmte Vokabulare deckeln und die dafuer benoetigte
Flexibilitaet (v.a. bei Namespaces) koennen DTDs nicht leisten.
[Man entwickelt natuerlich "RDA"-Vokabulare, damit es ein Vokabular gibt,
das den herkoemmlichen Beschreibungen gerecht wird, wird sich aber
davor hueten, Festlegungen fuer die Beschreibungsbeduerfnisse der
Zukunft und denen anderer Communities zu treffen. MARC21 ist uebrigens
im Gegensatz zu MAB schon immer in der Lage gewesen, unterschiedliche
Vokabulare flexibel zu handhaben (im Sinne von "transportieren zu
koennen"): Dafuer muss in MARC nur durch die zentrale Registry ein
Code zugeteilt werden, der in den Daten analog einem Namespace-Praefix
die Notationen begleitet. In MAB hingegen musste jedes Mal das eigentliche
Datenformat um ein Feld oder mindestens einen zusaetzlichen Indikator-
Code fuer ein vorhandenes Feld erweitert werden]


> 2.    Wie leistungsfähig werden XML-Native-Datenbanken (oder auch Google) 
> diese DTD recherchieren können,

Was verstehen Sie unter "eine DTD recherchieren"? Es wird weniger
als bislang einen abgeschlossenen Kanon von "Feldern" geben (und
wie oben erwaehnt ist in MARC/AACR2-Land, wo die Entwicklung erfolgt,
die Semantik von "Feldern" ohnehin traditionell schwaecher ausgepraegt
als hier). Weder von Mensch noch Maschine wird man erwarten, dass
in und fuer einen Kontext A entstandene Beschreibungen in einem
Kontext B /vollstaendig/ verstanden werden. Man kann im Kontext A
Daten so gestalten, dass im Kontext B eine Chance besteht, dort
bekannte Konzepte zu identifizieren. Google koennte z.B. sehr
rasch lernen, "Verfasser" zu identifizieren und zu beurteilen, ob
das seinem (unterstellten) Konzept von "creator" nahe genug kommt,
um es auszuwerten.


> wenn wir in diesem Bereich endlich die Ebene der relationalen 
> Datenbanken überwunden haben.

Haben Bibliotheksdaten als semi-strukturierte Daten diese "Ebene" je wirklich
betreten? [Dann waere z.B. beobachtbar, dass eine zweite und dritte Schlagwort-
kette ihre Position tauschen, weil diese ohne Belang ist. In allen
mir bekannten Bibliothekarischen Formaten und Anwendungen ist jedoch
die vom Bearbeiter bei der Eingabe vorgegebene Reihenfolge gleicher
Elemente sakrosankt]

Auf der Agenda steht ja eher ein ehrlicher Umgang mit Heterogenitaet
in den Daten: Fuer ein und denselben Aufsatz wird es unterschiedlich
viele hinterlegte Verfasser geben, ohne dass das eine oder das
andere Katalogisat dadurch "falsch" wuerde. Und sowohl Namensansetzungen
als auch Normdaten-Identnummern werden niemals international
einheitlich sein. Es wird immer schwerer werden, durch Vergleich
zweier konkreter "Datensaetze" zu beurteilen, ob sie dasselbe
beschreiben und daher ist es wichtig in diesen "Datensaetzen"
Vorkehrungen zu treffen, die einen maschinellen Rekurs auf fuer
diese Aufgabenstellungen benoetigte Zusatzinformation ermoeglichen.

Dazu gehoert v.a., das was in "Bibliothekdaten" an "Daten" steckt,
viel deutlicher auszuzeichnen (z.B. steckt ja in Fussnoten oft
viel wertvolles, was derzeit aber wegen einleitender Wendungen,
Fuellpartikeln und Flektionen kaum konsistent verarbeitbar ist),
damit kaemen dann auch relationale Systeme etwas besser klar...


> 3. Wird es noch vor dieser XML-Nutzung eine Abzweigung der Entwicklung 
> z.B zu Turtle (Terse RDF Triple Language) geben.

Warum nennen Sie das "Abzweigung"? Mit RDA-Vokabularen und der
Beruecksichtigung von RDF befindet man sich konzeptionell auf
einer ganz anderen Ebene und man wird sie in dieser oder jener
Syntax voellig aequivalent ausdruecken koennen. Das ist nun
wirklich nichts neues, denn etwa das mittels ISO-2709 realisierte
MARC21 und MARCXML sind aus Sicht der Anwender und der damit
transportierten Daten dasselbe "Format" und unterscheiden sich
nur durch die Auszeichnungssyntax.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iJwEAQECAAYFAlBD7HEACgkQYhMlmJ6W47PPHAQAg/2DvXx7pmwMVAhLnFeQp0pH
AR6UKEHdstNf0qtrQ7tfb8UqHmVDVSK2zhGhAnxXFnXE1fn9YIjvposzRq4AMYTS
ypPmnz4ZCgtT8INghOLUTSmkXwKfcdCmZ7a1pFZhULqyQmXzbgBSnUJVH0WSQTPE
OXLB7Mk/miPK3u9mfUQ=
=c7G+
-----END PGP SIGNATURE-----

-- 
http://www.inetbib.de