[Tustep-Liste] Frage zu Pattern Matching

Mi Mai 24 14:53:33 CEST 2017

Lieber Michael,

hab ganz herzlichen Dank für Deine ausführlichen Erläuterungen zu den Details, insb. zur Parameterart IX.
Die "sehr kreative" Lösung mit der Stringgruppe geht übrigens auf einen Tipp einer uns beiden bekannten Heidelberger Kollegin zurück. Ich hatte hier nur zunächst das Gefühl - um bei Deinem Mafia-Vergleich zu bleiben - mit dem Messer zur Schießerei zu kommen.... ;-)
Offenbar ist dieser Weg aber im vorliegenden Fall der sinnvollste, von daher werde ich die Anweisung in die Routine einbauen.

Herzliche Grüße in die Runde
von
Matthias Schneider

==================================================== 
|           Matthias Schneider, M.A. 
|__Kompetenzzentrum für elektronische Erschließungs- 
|     und Publikationsverfahren in den 
|     Geisteswissenschaften 
|__Trier Center for Digital Humanities 
|__Universität Trier 
|__DM 341 
|__Mail: schneiderm at uni-trier.de 
|__Homepage: 
|     http://www.kompetenzzentrum.uni-trier.de 
|     http://www.m-schneider.eu 
|__twitter: @ms91tru, @museumdighum
|__Telephon: 
|     + 49 651 201 2935 
====================================================

-----Ursprüngliche Nachricht-----
Von: tustep-liste-bounces at lists.uni-wuerzburg.de [mailto:tustep-liste-bounces at lists.uni-wuerzburg.de] Im Auftrag von Dr. Michael Trauth
Gesendet: Sonntag, 21. Mai 2017 03:51
An: tustep-liste at itug.de
Betreff: Re: [Tustep-Liste] Frage zu Pattern Matching

Diskussionsforum Tustep-Liste
Weitere Informationen: www.itug.de
------------------------------------------------------------

Lieber Matthias,

zu Deiner Frage:

> Gegeben sind Muster wie das folgende, das in meiner Datei in Datensatz 
> 0.11 steht:
> <belGrp><belDat font-
> name="Futura">#[2003]1723#[2002]</belDat>es
> <i>(ist)</i> durch unglück und nicht durch seinen betrieb verlohren 
> gangen <bibl><i>russ.
> land-recht 75.#[2003]</i></bibl></belGrp>
> 
> Der Text zwischen "</belDat>" und "<bibl>"
> soll als Zitat (<quote>...</quote>) getaggt werden, was an sich 
> trivial ist. Gerne möchte ich allerdings Blanks, die hinter 
> "</belDat>"
> und vor "<bibl>" stehen können (0, 1, ggf.
> auch mehrere Blanks), vom Tagging
> ausschließen.
> 
> Mein erster Versuch, der wie folgt aussah, lief ins Leere:
> a,(0.11,0.11),,|</beldat>{0-0} {|}*{|}{0-0} 
> <bibl>|{=1=}<quote>{=2=}</quote>{=3=}|
> 
> Lasse ich hingegen den zweiten Quantifizierer "{0-0}" weg, 
> funktioniert das testweise auf den Datensatz 0.11 beschränkte 
> Austauschen wie gewünscht. Allerdings würden dann bei Mehrfachblanks 
> alle bis auf das letzte in das neue <quote>-Tag integriert:
> a,(0.11,0.11),,|</beldat>{0-0} {|}*{|} 
> <bibl>|{=1=}<quote>{=2=}</quote>{=3=}|
> 
> Eine Ausweichmöglichkeit scheint darin zu bestehen, die Vorschrift für 
> "0 bis beliebig viele" Leerzeichen als Stringgruppe anzulegen.
> Dann werden bei mehrfache Blanks komplett aus dem Tagging 
> ausgeschlossen:
> s:mb=|{0-0} |
> 
> -->
> a,(0.11,0.11),,|</beldat>{S:mb}{|}*{|}{S:mb}<b
> ibl>|{=1=}<quote>{=2=}</quote>{=3=}|
> 
> Was sich mir bisher nicht erschließt, ist die Frage, warum mittels 
> Stringgruppeneinsatz funktioniert, was bei unmittelbarer Definition 
> nicht zu klappen scheint.

[MTr] In Deiner ersten Austauscheanweisung
	a,,,|</beldat>{0-0} {|}*{|}{0-0} <bibl>|{=1=}<quote>{=2=}</quote>{=3=}|
verwendest Du '{0-0} ' = ein Blank, das beliebig oft vorkommen oder auch fehlen kann, und sofort danach läßt Du '*' folgen, womit 'beliebig viele beliebige Zeichen' gemeint sind. Das Programm versucht in der Defaulteinstellung von jedem Element der Such-Zflg so früh wie möglich zum nächsten variablen Element überzugehen - und weil das Blank (das vorkommen oder auch fehlen kann) *auch* in dem folgenden Element '*'
enthalten ist, liest es über ein oder mehrere evtl.
hinter </beldat> stehende Blanks hinweg und geht gleich zu '*' über.

Das ist ziemlich wichtig und kommt als Fall in der täglichen Tustep-Praxis nicht oft vor, deshalb frage ich hier erst einmal nach Art der Mafia-Paten: Capisce?
Denn erst dann wirst Du die kurzen, aber luziden Ausführungen des Handbuchs 2017 zur Parameterart IX auf S.708 oben zur Angabe '{n--m}' verstehen.

Damit läßt sich die erste Hürde Deiner Anweisung noch leicht beheben, denn Du kannst das Programm dazu zwingen(!), die hinter </belDat> stehenden eventuell vorhandenen Blanks als eigenes Element zu lesen:
	a,,,|</beldat>{0--0} {|}*{|} <bibl>|{=1=}<quote>{=2=}</quote>{=3=}|
Mit dieser kleinen Änderung - dem zusätzlich eingefügten Bindestrich - funktioniert Deine Anweisung wie gewünscht.

ABER ich habe getrickst, denn das fakultative zweite Blank (vor <bibl>) habe ich zum festen Blank gemacht. Dieser Trick funktioniert, *obwohl* das Blank vor <bibl> ja auch in der Definition von '*' mit enthalten ist: An diesem Blank geht das Programm aber nur deswegen nicht zum nächsten Element der Such-Zflg über, weil das Element starr = nicht variabel ist. Wenn statt dessen ein variables Element (ein fakultatives oder beliebig(!) viele Blanks) da stünde, also
	a,,,|</beldat>{0--0} {|}*{|}{0} <bibl>|{=1=}<quote>{=2=}</quote>{=3=}|
oder
	a,,,|</beldat>{0--0} {|}*{|}{0-0} <bibl>|{=1=}<quote>{=2=}</quote>{=3=}|
oder
	a,,,|</beldat>{0--0} {|}*{|}{0--0} <bibl>|{=1=}<quote>{=2=}</quote>{=3=}|
dann funktioniert das Austauschen nicht mehr. Warum? In Deinem Beispiel stößt das Programm beim Bestimmen von '*'
auf das erste Blank zwischen 'es' und '<i>ist'. Das Programm freut sich, weil dieses Blank ebenfalls dem variabel definierten 'beliebig viele Blanks' entspricht, es geht deshalb von der Definition von '*' zu diesem '{0-0} ' über (hört also mit der Definition von '*'
auf), verzweifelt aber am danach fehlenden '<bibl>'
und bricht ab mit der Suche nach einer Übereinstimmung mit der Such-Zflg.

Das dürfte auch die Antwort auf Deine abschließende Frage sein, warum die von Dir gefundene (sehr kreative) Lösung mit der Definition einer Stringgruppe mb funktioniert:
	S:mb=|{0-0 |
	a,,,|</beldat>{S:mb}{|}*{|}{S:mb}<bibl>|{=1=}<quote>{=2=}</quote>{=3=}|
In *dieser* Anweisung ist das Element {S:mb} nämlich ein *starres*, kein variables. Wenn Du es mit einer Häufigkeitsbedingung innerhalb der a-Anweisung garniert hättest, hätte es ebenfalls *nicht* funktioniert.

NB: Deine Lösung gefällt mir wirklich sehr gut.

Es bleibt die Frage, ob man den Programmautor dazu bewegen könnte, hier noch ein wenig nachzubessern, damit eine variable Zahl von Blanks vor <bibl> ebenfalls noch richtig verstanden wird. - Ohne ihm vorgreifen zu
wollen: Ich hätte einige Bedenken, an der bisherigen Funktionsweise herumzudoktern, denn es besteht die Gefahr, daß in vielen uralten gut funktionierenden Programmroutinen sich einige wenige Austauscheanweisungen plötzlich anders verhalten als bisher. Und so ein Risiko wird doch wohl keiner gerne in Kauf nehmen wollen... Oder?

Viele Grüße reihum von

Michael Trauth

------------------------------------------------------------
Tustep-Liste at itug.de
https://lists.uni-wuerzburg.de/mailman/listinfo/tustep-liste