Changes between Version 22 and Version 23 of workflow

Timestamp:

May 25, 2010, 2:37:28 PM (15 years ago)

Author:

Wolfgang Schmidle

Comment:

--

workflow

@@ -437 +437 @@
 Hier gibt es einen Einschnitt im workflow: Der schemakonforme xml-Text wird bearbeitet. Es ist dann nicht mehr möglich, einfach zum raw text zurückzukehren und alle Bearbeitungsschritte noch einmal zu machen. Dies fällt, wie schon in Schritt 2 gesagt, idealerweise mit dem Beginn des scholarly workflow zusammen.
 
-Die Nummern dieser Skripte in diesem Schritt skönnen sich noch ändern. Legt die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) eine Verarbeitungsreihenfolge nahe?
+Die Nummern dieser Skripte in diesem Schritt können sich noch ändern. Legt die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) eine Verarbeitungsreihenfolge nahe?
 
 
 ==== 5.01 <reg> ====
 
-Das Skript [source:trunk/schema/scripts/workflow/Filter_5_01_insert_reg.pl Filter_5_01_insert_reg] regularisiert den Text. Für eine ausführlichere Diskussion von <reg> siehe [wiki:regularisierung hier].
-
-Wie beim <s>-Skript kann man hier einige Parameter wählen. Details stehen noch nicht fest.
+Das Skript [source:trunk/schema/scripts/workflow/Filter_5_01_insert_reg.pl Filter_5_01_insert_reg] regularisiert den Text. Für eine ausführlichere Diskussion von <reg> siehe [wiki:regularisierung hier]. Wie beim <s>-Skript kann man hier einige Parameter wählen. Details stehen noch nicht fest.
 
 Kein Zeichen, das normalisiert werden soll, darf hinterher noch im Text (außerhalb von {{{<reg>}}}) sein, zum Beispiel kein Zeichen mit Tilde (mit Ausnahmen in manchen Sprachen). Für !Latein/Benedetti:
@@ -452 +450 @@
   * combining acute, insbesondere q́ 
   * medievalist characters: ꝑ ꝓ ꝗ ꝗ̃ ꝙ ꝰ  ́ ꝯ (geeignete Fonts sind Andron, Junicode und Palemonas, die man [http://www.mufi.info/fonts/ hier] bekommt)
-  * weitere: ę ĺ
+  * weitere: ę ĺ (das zweite Zeichen ist aus Alvarus)
   * Apostroph: in den Abschnitten in Benedetti mit {{{xml:lang="it"}}} bzw. {{{xml:lang="ita"}}} ist {{{'}}} dagegen erlaubt
 
@@ -464 +462 @@
 ==== 5.02 <var> ====
 
-Das Skript [source:trunk/schema/scripts/workflow/Filter_5_02_insert_var.pl Filter_5_02_insert_var] fügt <var> um Variablen ein. Ein Ziel ist, den Inhalt vor der morphologischen Analyse zu verbergen.
-
-Eventuell hat dieses Skript ebenfalls Parameter, nämlich wie Variablen im Text aussehen.
-
-Entferne {{{<emph>}}} in Variablen.
+Das Skript [source:trunk/schema/scripts/workflow/Filter_5_02_insert_var.pl Filter_5_02_insert_var] fügt <var> um Variablen ein. Ein Ziel ist, den Inhalt vor der morphologischen Analyse zu verbergen. Eventuell hat dieses Skript ebenfalls Parameter, nämlich wie Variablen im Text aussehen (zum Beispiel {{{AB}}} versus {{{.a.b.}}}). 
+
+{{{<emph>}}} in Variablen wird wie bei running heads entfernt: Ob der Setzer ein K in upright shape oder in italics gewählt hat, ist egal.
 
 Für das Skript gibt es einen [source:trunk/schema/scripts/script-tests/var-testparcours.txt testparcours]. 
@@ -475 +471 @@
 ==== 5.03 <num> ====
 
-Das Skript [source:trunk/schema/scripts/workflow/Filter_5_03_insert_num.pl Filter_5_03_insert_num] fügt <num> um Zahlen ein, die nicht in der in modernen westlichen Texten üblichen Weise geschrieben sind. Deshalb werden zum Beispiel wohl auch chinesische Zahlen in chinesischen Texten markiert. Ein Ziel ist wieder, den Inhalt vor der morphologischen Analyse zu verbergen.
-
-(Verwende das Skript {{{Filter_roman_numbers.pl}}}: <num value="..."> für römische Zahlen. Es gibt auch ein Skript, um chinesische Seitenzahlen in westliche Zahlen umzuwandeln.)
+Das Skript [source:trunk/schema/scripts/workflow/Filter_5_03_insert_num.pl Filter_5_03_insert_num] fügt <num> um Zahlen ein, die nicht in der in modernen westlichen Texten üblichen Weise geschrieben sind. Ein Ziel ist wieder, den Inhalt vor der morphologischen Analyse zu verbergen.
+
+(Verwende das Skript {{{Filter_roman_numbers.pl}}}: <num value="..."> für römische Zahlen.)
 
 
 ==== 5.04 Formeln ====
 
-Das Skript [source:trunk/schema/scripts/workflow/Filter_5_04_formulae.pl Filter_5_04_formulae] soll korrektes MathML (oder zumindest korrektes TeX) erzeugen. Inwieweit das realistisch ist, weiß ich noch nicht.
+Das Skript [source:trunk/schema/scripts/workflow/Filter_5_04_formulae.pl Filter_5_04_formulae] soll korrektes MathML erzeugen (oder zumindest korrektes TeX, das dann umgewandelt werden kann). Inwieweit das realistisch ist, weiß ich noch nicht.
 
 
@@ -489 +485 @@
 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_05_insert_foreign.pl Filter_5_05_insert_foreign] soll fremdsprachliche Textstellen markieren. 
 
-Füge {{{<foreign xml:lang="el">}}} zumindest für griechischen Text (erkennbar an den verwendeten Zeichen) ein. Durch eine minimale linguistische Analyse des Textes kann man sicher auch weitere fremdsprachliche Textstücke korrekt erkennen.
+Füge {{{<foreign xml:lang="el">}}} zumindest für griechischen Text (erkennbar an den verwendeten Zeichen) ein. Durch eine minimale linguistische Analyse des Textes kann man wohl auch weitere fremdsprachliche Textstücke korrekt erkennen.
 
 
 ==== 5.06 div-Attribute ====
 
-Das Skript [source:trunk/schema/scripts/workflow/Filter_5_06_number_divs.pl Filter_5_06_number_divs] numeriert die Attribute {{{<div level="..." n="...">}}} korrekt durch. (Das Skript ist ein Wrapper für das xslt-Skript {{{number-divs.xsl}}}, das die eigentliche Arbeit macht.)
+Das Skript [source:trunk/schema/scripts/workflow/Filter_5_06_number_divs.pl Filter_5_06_number_divs] numeriert die Attribute {{{<div level="." n=".">}}} korrekt durch. (Das Skript ist ein Wrapper für das xslt-Skript {{{number-divs.xsl}}}, das die eigentliche Arbeit macht.)
 
 Es muss möglich sein, bereits im raw text korrektes XML zu verwenden, ohne dass die Skripte darüber stolpern. Beispielsweise muss man <div type="body"> einfügen können (beachte: dann sollte auch der type in <text> geändert werden). Braucht man dazu ein tool, oder geht das so? Was ist die Verbindung zum <div>-Skript? Braucht man ein tool zur manuellen Nachbearbeitung der automatisch erstellten <div>?
@@ -501 +497 @@
 ==== 5.07 GIS ====
 
-Füge GIS-Elemente in ausgewählte Texte ein: {{{<person>}}}, {{{<place>}}}, {{{<time>}}}, {{{<event>}}}. Für eine ausführlichere Diskussion siehe [wiki:"2010-04-15 GIS meeting" hier].
+Füge GIS-Elemente in ausgewählte Texte ein, also in etwa {{{<person>}}}, {{{<place>}}}, {{{<time>}}}, {{{<event>}}}. Für eine ausführlichere Diskussion siehe [wiki:"2010-04-15 GIS meeting" hier].
 
 
@@ -525 +521 @@
 
 Einige Standard-Aufgaben des scholarly workflow, die teilweise bereits im Schema angelegt sind:
-  * IDs einfügen (es könnte ein Modul geben, in dem das {{{id}}}-Attribut gefordet wird, und das mit der Zwiebelstruktur in diesem Stadium in Aktion tritt. Dann müssen wir nicht in den usage guide schreiben: Es ist zwar formal optional, aber es sollte verwendet werden.)
+  * IDs einfügen (es könnte ein Modul geben, in dem das {{{id}}}-Attribut gefordert wird, und das mit der Zwiebelstruktur in diesem Stadium in Aktion tritt. Dann müssen wir nicht in den usage guide schreiben: Es ist zwar formal optional, aber es sollte verwendet werden.)
   * ersetze {{{<wrong/>}}} durch {{{<sic/>}}} oder entferne es; löse {{{<unsure/>}}} auf
   * weitere {{{<reg>}}}, Korrekturen von bestehenden {{{<reg>}}}
@@ -538 +534 @@
 
 
-=== Reste ===
+=== Anmerkungen ===
 
 Das Grundgerüst für alle Filter ist 
@@ -556 +552 @@
   * beachte die in {{{echo-chinese-text}}} definierten Attribute
   * lateinische Zeichen können durch ihre full-width-Version ersetzt sein, zum Beispiel „?“ durch „？“
-  * verarbeite character variants automatisiert
-  * verarbeite character variants im scholarly workflow so gut wie möglich. Beispielsweise würde \国 durch die Unicode-Zeichenfolge ⿴口玉 angenähert werden.
   * Wort- und Satzgrenzen markieren (bzw. andersrum: invisible spaces innerhalb von Wörtern entfernen)
-
-Wie der automatisierte Workflow für chinesische Texte aussehen wird, ist noch nicht völlig klar. Wenn zum Beispiel im Text <獘V> getippt wurde, kann man das automatisiert nur zu <reg norm="獘" type="V">獘</reg> mit vorläufigem Typ "V" machen, wo also das getippte Zeichen einfach wiederholt wird. Die Variante im Text kann dann nur eine studentische Hilfskraft anhand der von !ZhongYi erstellten Excel-Tabellen "herstellen". Ziel ist eine Zeichenfolge, die das Zeichen im Text beschreibt. Hier: ⿱敝大. Und dann:
+  * Nach der Definition in Schritt 5.03 müsste man chinesische Zahlen in chinesischen Texten mit <num> markieren. Ist das tatsächlich sinnvoll? Es gibt jedenfalls ein älteres Skript für Euclid 1966, um beide Schreibweisen in westliche Zahlen umzuwandeln:
+{{{
+<num value="301">三〇一</num>
+<num value="23">二十三</num>
+}}}
+
+Wie der automatisierte Workflow für Zeichenvarianten aussehen wird, ist noch nicht völlig klar. Wenn zum Beispiel im Text <獘V> getippt wurde, kann man das automatisiert nur zu <reg norm="獘" type="V">獘</reg> mit vorläufigem Typ "V" machen, wo also das getippte Zeichen einfach wiederholt wird. Die Variante im Text kann dann nur eine studentische Hilfskraft anhand der von !ZhongYi erstellten Excel-Tabellen "herstellen". Ziel ist eine Zeichenfolge, die das Zeichen im Text beschreibt. Hier: ⿱敝大. Und dann:
 {{{
 <reg norm="獘" type="simple"><image xlink:href="symbols/chinese/⿱敝大.svg"/></reg>
@@ -572 +571 @@
 Das Herunterkochen von 兾 (V,,2,,) zu 冀 (S) sollte dann "von alleine" passieren. Allgemein: Was ist das Ziel, wenn die Chinesen eine Zeichenvariante (ohne < V>) getippt haben, die es in Unicode gibt? Soll die dann auch ein <reg> bekommen? Wer erkennt überhaupt, dass es sich um eine Variante handelt? Zumindest in der Theorie muss man das nicht regularisieren, und die Suche funktioniert von alleine richtig.
 
-Sollen wir umsteigen auf ein System, wo die Chinesen <001> tippen, und dann im Anhang eine IDS-Sequenz?
-
+Sollen wir umsteigen auf ein System, wo die Chinesen <001> tippen, und dann im Anhang eine IDS-Sequenz? Beispielsweise würde 国 durch die Unicode-Zeichenfolge ⿴口玉 beschrieben werden.
+