Vb. XML
Thomas Berger
ThB at gymel.com
Do Apr 1 12:46:37 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lieber Herr Eversberg, liebe Liste,
|>Ich denke, es ist ein bibliothekarischer Irrtum, ueberhaupt nur an
|>etwas wie "allgemein akzeptiertes Schema fuer Katalogdaten" zu denken.
|>Der Irrtum kommt daher, dass wir des oefteren denken, es gaebe
|>"allgemein akzeptierte Regeln fuer Katalogisierung".
|>
|>...
|
| ... und was dann noch alles folgt, laesst einen schon kalte Fuesse
kriegen.
| Was SOLL man also tun, und WIE?
| MABXML hat offenbar so viele Macken, dass man lieber die Finger davon
laesst?
Meine Aussage ist: MABXML ist (noch) nicht in der Lage, *alle*
Macken und selbstgebauten Fettnaepfchen von MAB auszubuegeln.
Die Arbeit an MABXML hat gezeigt, wie schlecht MAB wirklich ist,
vorher dachte man eher, MAB ist so etwas wie MARC light mit einigen
Sonderwegen.
| MARCXML ist besser, aber fuer unsere speziellen Anforderungen auch
nicht das
| Gelbe vom Ei?
| Also doch selber was machen, einen eigenen Standard setzen?
Das waren die traditionellen Alternativen: Entweder die eigenen
Daten in ein existierendes Format pressen mit all den offensichtlichen
Verlusten, oder einen eigenen Standard setzen (bzw. dazwischen liegt:
In den ueblichen Gremien so viel Druck machen, dass die Standards
in Richtung der eigenen Beduerfnisse modifiziert werden).
Mit XML (nicht mit SGML, da sind die DTD's im Weg) oder aehnlich
"extensiblen" Mechanismen sollte es moeglich werden, die eigenen
Daten in voller Schoenheit zu transportieren, ohne auf den Vorteil
verzichten zu muessen der sich daraus ergibt, dass die "schwierigen"
95% davon durch verbreitete Standards abgedeckt werden. D.h.
MAB fuer die formale Beschreibung plus meine supertolle, zu nichts
kompatible fachsystematische Erschliessung muessen beim Transport
koexistieren koennen, ohne dass Sender und/oder Empfaenger da aus
(format-)technischen Gruenden aussteigen, und auch ohne dass zuerst
irgend ein Gremium mir einen Indikator fuer ein vermutlich noch
nicht einmal sonderlich taugliches Datenfeld zubilligt.
| Aber egal was man macht, man wird bald wieder was aendern muessen! Und
wer sich
| drauf eingelassen hat, Daten von mit zu uebernehmen, muss die
Aenderung dann auch
| wieder nachziehen. Was wuerde sich also wirklich bessern?
im Vergleich wozu? MAB-Aenderungen soll es auch schon einmal
gegeben haben, Erweiterungen des A-Formats sowieso. Auch hier
koennte "extensibel" den Vorteil haben, reibungsloser Daten der
"falschen" MAB- oder MARC-Version verarbeiten zu koennen, also
nicht nur Abwaerts- sondern auch Aufwaertskompatibilitaet zu
haben.
viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAa/MMENVh3bB0lwMRAmtpAJ92u3rp5lS339RpU+SoqfQKKftDKwCfQiTH
tqAFQhsidfmwhQ0GexM+qZ0=
=6ZHU
-----END PGP SIGNATURE-----
Mehr Informationen über die Mailingliste Allegro