[Allegro] anzeige von einem hfm-feld in apr geht nicht(?)

[Thomas Berger]

Am 02.12.2015 um 10:20 schrieb Bernhard Eversberg:

>> D.h. wir operieren zwar seit 60 Jahren oder so mit "records" in
>> immer derselben scheinbar einfachen Struktur (Felder,
>> Wiederholbarkeiten, Unterfelder, Wiederholbarkeiten davon,
>> Binnensyntax, ...) es fehlt aber immer noch an einer Sprache,
>> die "typischen" /Operationen/ auf solchen records auszudruecken.
> Und warum ist das wohl so? Ich weiß es auch nicht. Stoßen Sie
> doch endlich mal rein in diese gähnende Marktlücke, und
> entwickeln sowas, und damit selber vor und hinauf zu den
> Olympiern der Fachgemeinschaft.

Die Situation laesst sich verallgemeinern, es geht ja um
eine letztendlich immer Baum-artige Datenstruktur, wobei
die Felder (Unterfelder, ...) Namen haben, die aber nicht
unbedingt eindeutig sind, so dass auch die Position zu
beruecksichtigen ist, und zwar darf man nicht davon ausgehen,
dass alles sortiert ist, d.h. hinter $a und $b koennte im
gleichen Feld noch einmal $a und dann $b kommen: Position
gibt es dann sowohl relativ zum uebergeordneten Element
und als Zaehlung aller gleichnamigen Unterelemente im
uebergeordneten...

Dieselben Probleme hat man auch, wenn man die Saetze als
JSON oder XML umformatiert oder als RDF abstrahiert, die
Art und Weise dieser Umformatierung ist beileibe nicht
kanonisch (typischerweise immer ein springender Mix aus
Array und Hash: Ein Array von Feldern in vorgegebener
Reihenfolge, jedes Feld ein Hash mit Feldnummer / Label
als Wert fuer einen Key, und ein Array von Unterelementen
als Wert fuer einen anderen, ...) [MARC selber hat mit $8
einen eigenen Mechanismus fuer Querverweise im record, um
etwa zusamemengehoerende Felder, die aus technischen Gruenden
zerlegt werden, wieder zu klammern: Das geht nur mit
Binnensyntax und nur bis zur Feldebene, nicht feiner...]

Mit XPath kann man das Benoetigte ausdruecken (das ist zwar
primaer fuer XML aber insgesamt eine Navigationssyntax fuer
alles, was in einer DOM-Struktur vorliegt), aber:

1. Die konkrete Umwandlung eines abstrakten Datensatzes
  in eine DOM-Struktur laesst Freiheiten, die XPath-
  Ausdruecke sind dann jeweils andere

2. XPath liefert DOM-Fragmente zurueck (es koennten ja
   mehrere Felder getroffen worden sein), fuer MARC Specs
   u.ae. stellt man sich aber etwas viel einfachereres
   vor, moeglichst einen String, hilfsweise ein Array
   als Resultat.

3. XPath ist fuer Bibliothekare zu kompliziert: die Fiktion
  ist, dass Endbenutzer (wohl der Feld-Wald-und-Wiesen-
  Systembibliothekar) das schnell formulieren koennen ohne
  eine komplizierte Syntax zu lernen.

Wenn ich mich recht entsinne, ist aus Ueberlegungen wie bei
3. dann die allegro-Exportsprache entstanden ;-)

Ich halte die Sache daher fuer voellig verfahren: Wenn wir
wuessten, was die typischen Anforderungen sind, koennten
wir einen internationalen Standard zur kanonischen DOM-
ifizierung von "bib records" schaffen und mit XPath darauf
operieren. Fuer die weniger Bedarften koennte ein graphisches
Tool geschaffen werden, mit dem man sich das zusammenklicken
kann (vor ein paar Tagen war ich schwer beeindruckt von
< https://regex101.com/#pcre >: PCRE ist gewiss noch
schwerer zu lernen als XPath...).

Wir wissen es aber nicht, "records" sind irgendein semistrukturierter
Text und schon an der Frage, ob es sich bei Subfields um
Unterelemente oder um in Fliesstext eingesprengselte Markierungen
handelt, scheiden sich die Geister...

viele Gruesse
Thomas Berger