[Allegro] Sprachspezifische V14-Ersetzung - Vorueberlegung

[Thomas Berger]

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

Lieber Herr Eversberg,

> Multi-Normdaten : Sprachspezifische V14-Ersetzung
> -------------------------------------------------
> 
> Bisher ist es so:
> Wenn man Normdaten und die V14-Technik verwendet, hat ein Stammsatz
> eine Nummer oder Notation  nnn, die dann einen Indexeintrag der Form
> 
> nnn=|iKlartext
> 
> erzeugt. Im Datensatz schreibt man  _nnn  und erhält im Index
> und im Export dafür automatisch den Klartext eingesetzt.

Genau. Nur ist "Klartext" in den seltensten Faellen das benoetigte:
- - Schlagworte muessen z.B. mitteilen, von welchem Typ sie sind
- - Individualisierende Information zu Personen wird allmaehlich
  nicht mehr als Teil der Ansetzung aufgefasst, sondern in
  parallelen Feldern transportiert
- - Systematikdaten sind stark strukturiert (etwa zumindest in
  Notation und Ansetzung)
- - Alle moeglichen Ersetzungstexte wollen als Link aufbereitet
  sein, sie transportieren moeglichst noch ihre eigene Identnummer
  (damit etwa auch lange ZS-Titel korrekt mit ZDB verlinkt werden
  koennen) sowie Kennzeichen fuer Anfang und Ende der Ersetzung
  (damit der korrekte Teilstring als Link ausgelegt werden kann)
- - Hinter einem Verknuepfungskurzel verbergen sich mehrere "aequivalente"
  Normsaetze (vgl. die letztes Jahr umgestellten EVK-Saetze der SWD)

Fazit: Anspruchfvolle Anwendungen bekommen mit der v14-Methode
wenig geschenkt, oft empfiehlt sich zumindest ein Umstellen auf
i4=5, Konsequenz ist in jedem Fall, dass Kategorien, die tendenziell
Verknuepfungen enthalten, durch die Parameterdateien sorgfaeltig
nachgeparst und aufbereitet werden muessen. In diesem Zusammenhang
kann man (seit v21?) auch waehrend der Indexierung nachladen und
gezielt auf Einzelkategorien des Normsatzes zugreifen.


> Nun gibt es Anwendungen, wo man gerne eine oder mehrere alternative
> Oberflächen mit unterschiedlichen Sprachen anbieten würde. Hat man
> außerdem in den Stammsätzen jeweils zusätzlich noch Ansetzungen
> in den anderen Sprachen, ergibt sich der Wunsch, für  nnn  wahlweise
> diese anderen Ansetzungen eingefügt zu bekommen.
> Wie könnte das gehen?
> 
> Die am einfachsten programmierbare Lösung könnte so aussehen:
> 
> 1. Für die alternativen Ansetzungen jeweils eigene Schlüssel
>    erzeugen, die so aussehen:
>    nnnK=|iAlternativKlartext
>    wobei K ein Kennbuchstabe wäre, und zwar ein großer, damit
>    keine Kollision auftreten könnte: Es wäre ja möglich, daß
>    die Notation  nnnk  ebenfalls existiert! Sind die Notationen
>    Nummern und die Kennbuchstaben Buchstaben, besteht dieses
>    Risiko nicht, aber sonst schon.
> 
> 2. In den Exportparametern (für eine Anzeigeform oder Export) braucht
>    man einen neuen Befehl, nennen wir ihn
>    ik=K
>    Damit wird dann beim Export immer zuerst nach nnnK= gesucht, wenn
>    eine V14-Ersetzung zu machen ist. Wird damit nichts gefunden, so
>    wird auch noch  nnn=  gesucht. Damit gibt es keinen Zwang, in jedem
>    Stammsatz eine entsprechende Alternativform zu haben.
> 
>    Wenn  ik  in den Exportparametern nicht gesetzt wird, ist alles wie
>    bisher, d.h. alle "alten" Parameter funktionieren unverändert.


Mir scheint das hoechstens fuer Sacherschliessungssaetze relevant.
Die sind in der Demo-Anwendung fuers A-Schema aber nicht einmal
verknuepfbar. Typisch fuer die Praxis scheint mir in der Tat, dass
die Saetze je nach Sprache unterschiedlich vollstaendig uebersetzt
sind. Fraglich ist aber, ob es die eine "Standard-Sprache" gibt, auf
die man automatisch zurueckgeworfen werden moechte (vielleicht haette
man doch lieber die slowakische Alternative statt der deutschen, wenn
tschechische Ansetzungen nicht verfuegbar sind). Das mit den Code-
Buchstaben scheint mir auch zu kurz gedacht, bei 26 Grossbuchstaben
braucht es nur eine Handvoll alternativer Sprachen, schon geraet man
in mnemonische Konflikte beim Kuerzeln...

Also: Wenn es das Feature schon gaebe, koennte ich Punkte sammeln, indem
ich seine Abschaffung anregte ;-)

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

iD8DBQFFtMONhKFJT0F1FsoRAs/6AJwJMesHXp6R28LTsF86fLjUgXrG9ACfQF1v
ZBmy4NibODORPmGh5g2pauk=
=BLCK
-----END PGP SIGNATURE-----