[mab-list] MABXML

Thomas Berger ThB at gymel.com
Tue Sep 16 11:01:29 CEST 2003


Lieber Herr Eversberg,

> > XML und Namespaces bieten natuerlich die Moeglichkeit,
> > Namensansetzungen subzustrukturieren, etwa fiktiv als
> > <feld nr="100" ind=" ">
> >   <pnd:person xmlns:pnd="http://www.ddb.de/pnd" pnd:namenstyp="modern">
> >      <nachname>Mueller</nachname>, <vorname>Peter</vorname>
> >   </pnd:person>
> > </feld>
> >
> > [nein Herr Eversberg, das will niemand so speichern, wozu
> > haben wir denn - noch - Verknuepfungen]
> >
> Himmel, ich dachte schon... Und wollte gerade den Zeigefinger heben! Aber wieso
> aendern Verknuepfungen da was dran? Irgendwo muss man ja speichern, und wenn's
> nur im Normsatz ist.

Im Normsatz wird alles moegliche ausdifferenziert, das im Titelsatz
dann nicht mehr - oder verkuerzt - enthalten ist. Ihr PICA-Beispiel
zeigt allerdings, dass hier in der Titelaufnahme staerker zerlegt
wird als im Normsatz. Hm.

 
> Erstens aber ist ja dies nur ein erster Ansatz. Namen koennen noch mehr
> Bestandteile haben. Die Kat.-Richtlinie des GBV zeigt das: in jedem Namensfeld
> gilt diese Interpunktion: (das ¬ ist ein vorgeschriebenes Blank)
> 
> Vornamen
> @..." Persönlicher Name
> /... Präfix (nicht in der Ordnungsgruppe des
> Familiennamens anzusetzen)
> @ Familienname
> ¬<...> Ordnungshilfe
> ¬[...] Funktionsbezeichnung
> 
> Bei schlichten Namen also "Vorname at Nachname", intern sihet das aber so aus:
> (etwas verkuerzt, siehe http://www.gbv.de/du/katricht/3000.pdf )
> 
> 028A $a Eintragselement (Nachname) $5 Vorname als Eintragselement $c Präfix $d
> Vornamen $e Namenszusätze vor den Vornamen $l Ordnungshilfe $h Lebensdaten $f
> Ergänzungen hinter dem Namen $p weitere identifizierende Angaben / Körperschaft,
>  bei der die Person beschäftigt ist $B Funktionsbezeichnung
> 
> Zu einem eingegebenen bzw. angezeigten  Thomas at Berger gehoert also als interne
> Darstellung: $aBerger$dThomas
> 
> Das Beispiel, und was Berger anschliessend auseindanderdifferenziert hinsichtlich
> der Interpunktion, zeigt ja beeindruckend-bedrueckend deutlich, dass es schon
> recht unuebersichtlich werden kann, wenn man sich auf XML einlaesst und wirklich
> alles abbilden will, was wir momentan haben.

Ich fand den PICA-Ansatz "Johann Wolfgang/von at Goethe" immer recht
interessant, weil hier ja aus der Ansetzung (lt. Regelwerk invertiert)
eine Vorzugs-Vorlageform (Name normiert aber nichtinvertiert)
konstruiert
und mit Markup "@/¬<[*%#" versehen wird. Interessant vor allem deshalb,
weil das artifizielle ", " der Invertierung entfaellt, aber dennoch
korrekte
Sortierung gewaehrleistet werden kann. Durch eine Vergiss-Transformation
wird aus dieser Angabe also sofort "Johann Wolfgang von Goethe", d.h.
korrekte (in unserem kulturellen Kontext) Praesentation ist in der
Erfassung bereits angelegt.

Ueberrascht bin ich allerdings, dass die interne Speicherung in PICA+
dann
nicht "$d Johann Wolfgang $c von $a Goethe" zu sein scheint, sondern
"$a Goethe $c von $d Johann Wolfgang", d.h. die komplizierte Syntax mit
8 unterschiedlichen Steuerzeichen ist nur eine adhoc-Syntax und
Erfassungs-
"Hilfe" fuer die Belegung von 10 verschiedenen Unterfeldern (das scheint
mir nun nicht mehr besonders elegant)

 
> M.E. waere dies alles auch ein Anlass, die ISBDs und die darauf bezogenen
> Katalogregeln mal kritisch zu durchleuchten und zu hinterfragen, denn die
> Komplikationen resultieren zu einem guten Teil daraus. Das jedoch waere ein
> internationaler Prozess auf IFLA-Ebene, dort sehe ich bisher keine Anzeichen fuer
> eine Bewegung in welche Richtung auch immer.
> Worauf's ankommt, ist der Zugriff, und das Interesse des Nutzers fuer Feinheiten
> von Praesentationsformen wird demgegenueber um Groessenordnungen geringer sein.
> Deshalb rechtfertigt sich m.E. kein beliebig hoher Aufwand in diesem Bereich,
> weder beim Eingeben noch beim Speichern noch beim Umwandeln. Eigentlich ein
> Schlamassel, das Ganze.

Ich denke, das ist der Grund, warum die Datenformate stellenweise nicht
so stark differenzieren wie die ISBDs. Umgekehrt ist es aber so, dass
die ISBDs ja ziemlich durchdacht sind: ISBD-Interpunktion wird nur an
Stellen eingefuegt, wo Katalogisierer separate Ermittlungen anstellen
muessen (ISBN und Preis, verschiedensprachige Verfasserangaben zu
verschiedensprachigen Paralleltiteln) oder dient der vereinheitlichenden
Transkription der Vorlage (etwa Abtrennung der diversen "Zusaetze zum
Sachtitel", anhand der Vorlage an Zeilenumbruechen und oder
Interpunktion
ermittelbar). Alles ist Fliesstext (mit Markup) und nahe beieinander
findbare Informationen der Vorlage werden auch nahe beieinander erfasst.
Erfassen nach ISBD mit der geforderten Interpunktion tut - so behaupte
ich zumindest - einem Katalogisierer nicht so weh wie das Bedienen eines
aehnlich ausdifferenzierten, jedoch verflachten und damit auseinander-
gerissenen Datenformats, wie es MARC oder MAB darstellen.

Hochinteressant faende ich, wenn es irgendwo Ansaetze zu einem ISBD-XML
gaebe, also ein XML-Markup des Fliesstextes einer ISBD-Aufnahme, das
dann (ohne den Umweg AACR und MARC bzw. RAK und MAB) die den ISBD
unterliegenden
Katalogisierungskonzepte explizit machen wuerde (ich hatte ja behauptet,
dass
es sich um eine komplizierte Baumstruktur handelt, die "unsere"
Datenformate
prinzipiell nicht abbilden koennen). 

viele Gruesse
Thomas Berger

----------------------------------------------------------------------
Zum Austragen aus dieser Liste senden Sie bitte eine Mail an
majordomo at ddb.de mit unsubscribe mab-list im Textfeld.



More information about the datenformate mailing list