[Allegro] Teilfeldzeichen ändern

[Thomas Berger]

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

Lieber Herr Eversberg,

>> Was fehlt ist ein gezieltes Belegen von Unterfeldern in der Importsprache
> Was genau schwebt Ihnen da vor? Einen festen Wert einsetzen oder einen
> aus dem Fremdtext extrahierten Wert in ein schon vorhandenes oder nicht
> vorhandenes Feld als Unterfeld einsetzen?

Wo Sie so fragen: beides:

#31g$u

beschickt gezielt Unterfeld u von #31g. (ueber guenstiges Verhalten im
Fall von Wiederholungskategorien muss man sich noch Gedanken machen)

sowie evtl. ein eingaengigerer Extraktionsbefehl fuer Unterfelder aus
Fremddaten. Das bisherige
b "▼x"
e "▼"
ist nicht wirklich unelegant, es fehlt aber eine Test-Moeglichkeit analog
C 0 "830"   (ist Feld 830 enthalten) speziell auf den Fall, dass ein Feld
830 mit einem bestimmten Unterfeld enthalten ist:
C 0 "830.*▼g"
wird wohl nicht funktionieren, und wenn, den Test nicht unbedingt am
Feldende stoppen?


>> und eine Syntax fuer Suchbefehle: "normale" wie von SRCH und Fernglas,
> Beim Import?

Bei Volltextsuchen.


>> sowie m.W. auch fuer die Suche mit regulaeren Ausdruecken. Es fehlt
>> uebrigens
>> auch ein gezieltes Extrahieren von Unterfeldern in der ak-Syntax der
>> Exportsprache, ak=33."\▼s" ist ja nicht ganz dassselbe, weil man im
>> Verarbeitugnscode dann jeweils noch staendig e"▼" spendieren muss.
> So tragisch ist das ja nun nicht. Ein solches Extrahieren dürfte recht
> selten nötig sein, und dann kann man mit dieser Ineleganz leben.


Es gibt Formate (MARC21, UNIMARC), in denen sich *alles* in Unterfeldern
tummelt.



>> Jedenfalls: Besonders im Hinblick auf die MARC21-Einfuehrung (zu
>> erwarten sind
>> ja die eine oder andere allegro-Datenbank in reinem MARC $U.CFG) sollte
>> verstaerkt darauf geachtet werden, dass Unterfelder weitestgehend wie
>> komplette
>> Kategorien funktionieren.
>>
> Soll das heißen, daß Unterfelder wiederum eigene Unterfelder enthalten
> können sollten? Oder was ist mit "funktionieren" gemeint?

Adressierung ist gemeint.

[<rant>
Die fehlende Schachtelbarkeit ist ein strukturelles Defizit aller dieser
"bibliothekarischen" Datenformate, das wird z.B. in MODS als XML-Format
ueberwunden, alle anderen Formate sind starr:

1. Wir haben Datensaetze
2. Im Datensatz sind Datenfelder mit verschiedenen Nummern
3. Felder sind wiederholbar mit gleicher Nummer
4. Jede Feldwiederholung enthaelt Unterfelder mit verschiedenen Codes
5. Unterfelder sind wiederholbar mit gleichem Code

damit haben wir (guenstig gerechnet) 5 Freiheitsgrade / Dimensionen und
darunter sind dann noch weitere Freiheitsgrade, die nicht mehr vom Datenformat
vorgesehen sind, sondern von der konkreten Anwendung
6. "interne" Wiederholbarkeiten durch " ; " oder ein dediziertes
   Trennzeichen wie "¶"
7. "interne" Strukturierung durch ISBD-Interpunktion u.ae.

Verknuepfungen (so ueberhaupt definiert) sind meist auf Feldebene definiert
(im Gegensatz zu allegro's v14-Ersetzungen auf Zeichenebene innerhalb des
Felds/Unterfelds), d.h. ein komplettes Feld wird durch etwas herbeigeholtes
ersetzt (z.B. MARC 100 mit den strukturierten Angaben zur Ansetzung von
Personen oder MARC 77x mit Titelverknuepfungen). Im zweiten Fall sieht man
schon recht schoen, wie eine komplette Titelaufnahme mit all ihren Feldern
auf "ein Feld mit Unterfeldern" transformiert werden muss. Wenn nun etwa die
Fundstelle eines Aufsatzes selbst wieder einen Gesamttitel hat, muss nun
in dieser zweiten Stufe der Indirektheit alles noch einmal auf ein einziges
Unterfeld (mit ISBD-Interpunktion) zusammengequetscht werden. Das ist
historisch gesehen auch ganz "normal", weil ja auch fuer die Karteikarten
solche Reduktionsregeln galten und wir im Extremfall RAK ja sowieso drei
verschiedene Ansetzungsregeln fuer den Sachtitel haben, je nachdem in welchem
Display-Kontext er notiert wird. Format- und Verarbeitungstechnisch sind diese
Umstaende aber Sackgassen (deren finsteres Ende schon laengst erreicht ist),
und zudem werden Regelwerke und Datenformate dadurch ganz furchtbar mit
inhaltlichen Pleonasmen aufgeblaeht.
</rant>]

viele Gruesse
Thomas Berger




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSw5QmGITJZieluOzAQJvUQP6A9XQLS/Y5Gj82u9DNj63yXJhgRDui/Ab
BRuR/ZyQnJFuAua08jc9sTgzypL+HrwNj6Tk1XCNJDgkfDOqk6Du+G0M1uAMe/FI
IveTHgs3fe5o3XxqGTOXa0w9Mu7d5APVnY1HF5re9UYn4YKyDNPSRQmnEAqeZJeq
9dznlMr5sEU=
=Tf6G
-----END PGP SIGNATURE-----