Abstrakte Wikipedia/Vorlagensprache für Wikifunctions/Umwandlung von Vorlagensyntax in andere Formalismen

From Meta, a Wikimedia project coordination wiki

Die Vorlagensprache ist für den Einsatz im Rahmen der Abstrakten Wikipedia gedacht, kann aber flexibel interpretiert werden. Vielleicht hast du beispielsweise bereits einen Realisierer für deine Sprache, der sich nicht einfach in Wikifunctions oder Scribunto umwandeln lässt, die Ausgabe soll jedoch ein Wikipedia-Artikel sein, oder du möchtest die ersten Stufen von NLG (Wikidata + Konstruktoren + Vorlagen) verwenden, aber die Ausgabe soll eher ein mehrsprachiges Quiz für deine eigene mobile App als ein Wikipedia-Artikel sein. Dies sollte nicht undurchführbar sein. Ein wichtiger Schritt, um dies zu realisieren, ist die Umwandlung der Vorlagensprache in einen anderen Realisierer oder (einen Teil) eines NLG-Systems, wie etwa Grammatical Framework und SimpleNLG, unter vielen verfügbaren Systemen. Jedes dieser Systeme hat seine eigene Art, Grammatiken oder Vorlagen zu spezifizieren, mit denen mehr oder weniger Grammatik in irgendeiner Weise verknüpft ist, sowie Algorithmen zu deren Interpretation, die algorithmisch die beabsichtigte Bedeutung liefern. Aus diesem Grund ist es eventuell nicht möglich, die Vorlagensprache verlustfrei auf eine andere Vorlagen-Spezifikationssprache oder eine ähnliche Formalisierung abzubilden. Die Idee besteht vielmehr darin, eine Umwandlung der Vorlagensyntax zu entwickeln, sodass die beabsichtigte Semantik so weit wie möglich erhalten bleibt, ohne sich gegenseitig zu widersprechen.

Umwandlung in ToCT

Wir nutzen die “Aufgabenontologie für komplexe Vorlagen” (ToCT)[1] für diese Abbildung. Eine Ontologie hat ihre eigene Semantik (modelltheoretisch oder graphbasiert, im Fall von OWL-Ontologien in der Web-Ontologiesprache OWL dargestellt) und daher ist keine algorithmische Interpretation erforderlich. Gefragt ist, wie diese Elemente der Vorlagensprache unter Berücksichtigung der Einschränkungen in ToCT-Elemente abgebildet werden.

Abbildung in ToCT-Elemente

Wenn wir zunächst informell vergleichen, stellen wir Folgendes fest. Im Gegensatz zur Vorlagensprache, die über Text, Lücken und Funktionen verfügt, verfügt ToCT über Wörter und Lücken als Schlüsselelemente und ignoriert Funktionen und Untervorlagen. Abhängigkeitsbeziehungen mit Rollen in der Vorlagensprache haben in ToCT ein verallgemeinertes Gegenstück mit einer flexibleren (unterspezifizierten) Beziehung ‘beruht auf’, die derzeit nicht auf Abhängigkeitsgraphen im UD/SUD-Sinn basiert (aber teilweise von diesen inspiriert ist). Umgekehrt verfügt ToCT über bestimmte Elemente für Wortfragmente, wie Konkordien und Affixe, die in der Vorlagensprache nicht als Elemente erster Ordnung in der Sprache vorhanden sind, um die Arbeit für Niger-Kongo-Sprachen zu erleichtern. Jedes ToCT-Element wird durch seinen automatisch generierten Teilnamen identifiziert, der vom Benutzer geändert werden kann und daher mit den Identifikatoren der Vorlagensprache übereinstimmen kann. Die Sprache, die man für die Vorlagensprache auswählen kann, hängt davon ab, was Wikidata unterstützt, wohingegen dies mit ToCT flexibler ist, das das Modell für Sprachannotationen, MoLA, von Gillis-Webber, Tittel & Keet (2019)[2] ist und das nicht nur jeden ISO-639-Code, sondern auch benutzerdefinierte (gesprochene oder tote) Sprachen und Dialekte unterstützt.

Da es sich nicht um eine exakte 1:1-Zuordnung handelt, kann sie nicht verlustfrei sein und erfordert in beiden Richtungen einen Mensch im System. Ein möglicher Ablauf von der Vorlagensprache in ToCT ist wie folgt, wobei die oben eingeführte Vorlagensprache mit TL und ToCT mit ToCT bezeichnet wird.

  1. Erweitere die Vorlage, indem du jede Untervorlage in die Hauptvorlage einklappst, sodass nur eine Ebene für die Vorlage vorhanden ist. Dazu gehört auch der mögliche Prozess der Auswahl von Untervorlagenvarianten auf der Grundlage einer möglicherweise spezifizierten Vorbedingung.
  2. Erweitere die Vorlage, indem du jede Unterfunktion, die als Untervorlage fungiert, in die Hauptvorlage einklappst, sodass nur eine Ebene vorhanden ist.
  3. Übertrage das Sprachattribut der TL-Vorlage: Kopiere entweder den ISO-639-Sprachcode und verwende den vom System generierten Namen dafür oder füge einen anderen Namen dafür hinzu und gib an, ob er bevorzugt oder alternativ ist.
  4. Indexiere die Reihenfolge der TL-Elemente von Anfang bis Ende, beginnend bei 1.
  5. Gruppiere aufeinanderfolgende TL-Elemente nach Wortbildung und lasse Kontraktionen aufgrund phonologischer Konditionierung weg.
  6. Konvertiere jede unveränderliche Textzeichenkette, die ein Wort werden soll, von TL in To:
    1. Wenn es sich um ein unimorphes Wort handelt, verwende das Element “Unimorphisches Wort” und übergib die Indexnummer.
    2. Wenn es sich um einen Satz (zwei oder mehr Wörter) handelt, verwende das Element “Satz” und übergib die Indexnummer.
  7. Konvertiere für jede isolierte Lücke, die zu einem Wort oder einem Satz werden soll, jede TL-Lücke in eine ToCT-Lücke und übertrage die Indexnummer.
  8. Bestimme für jede Kombination aus TL-Text und -Lücken, die zu einem Wort werden soll, das ein polymorphes Wort ist, für jedes Element:
    1. Bestimme, um welches Element es sich handelt: eine Konkordanz, ein Affix, eine Wurzel oder ein Stamm (eine Textzeichenkette) oder eine Lücke (d. h. etwas, das eher Inhalte als linguistische Daten abruft).
    2. Erstelle ein “Polymorphes Wort” und füge diese Elemente in der entsprechenden Reihenfolge hinzu.
  9. Stelle sicher, dass die Reihenfolge der Elemente in To mit der in TL übereinstimmt.
  10. Löse TL-Abhängigkeiten von ToCTs reliesOn auf. (Da TL-Abhängigkeiten spezifischer sein können als reliesOn, ist dies kein verlustfreier Prozess. ToCTs reliesOn wird in naher Zukunft verfeinert.)
  11. Übertrage die Interpunktion aus der TL-Vorlage in ToCT.

Beispiele in Turtle-Syntax

ToCT speichert Instanziierungen von Vorlagen in Turtle-Syntax - Terse RDF Triple Language, ein W3C-Standard, für die Serialisierung. (Es hätte genauso gut die offizielle Austauschsyntax für OWL (RDF/XML) oder eine andere sein können.) Aufgrund der ausgefeilten Turtle-Syntax, die nicht für den menschlichen Gebrauch, sondern für die Back-End-Verarbeitung gedacht ist, geben wir nur zwei Beispiele an: die einfachste Vorlage für Schwedisch und die aufwändigste für isiZulu.

Die Vorlagensyntax für das Ausführungsbeispiel auf Schwedisch:

Age_renderer_sv(Entity, Age_in_years): "{Person(Entity)} är {Age_in_years} år gammal."

Die ToCT-Syntax lautet wie folgt, was später erklärt wird (der erste Teil mit @base und @prefix ist nur Turtle-Administration und kann vorerst ignoriert werden):

@base <http://people.cs.uct.ac.za/~zmahlaza/templates/owlsiz/> .
@prefix toct: <https://people.cs.uct.ac.za/~zmahlaza/ontologies/ToCT#> .
@prefix mola: <https://ontology.londisizwe.org/mola#> .
@prefix co: <http://purl.org/co/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix cao: <http://people.cs.uct.ac.za/~zmahlaza/ontologies/ConcordAnnotationOntology#> .

<ageSE> a toct:Template
    ; toct:supportsLanguage <lang>
    ; toct:hasFirstPart <Person>
    ; toct:hasLastPart <.>
    ; toct:hasPart <ar>, <ageYears>, <argammal> .

<lang> a mola:Language
    ; mola:isFamily <Swedish> .

<Person> a toct:Slot
    ; toct:hasLabel ""^^xsd:string
    ; toct:hasNextPart <ar> .

<ar> a toct:UnimorphicWord
    ; toct:hasValue "är"^^xsd:string
    ; toct:hasNextPart <ageYears> .

<ageYears> a toct:Slot
    ; toct:hasLabel ""^^xsd:string
    ; toct:hasNextPart <argammal> .

<argammal> a toct:Phrase
    ; toct:hasValue "år gammal"^^xsd:string
    ; toct:hasNextPart <.> .

<.> a toct:Punctuation
    ; toct:hasValue "."^^xsd:string .

Das ageSE ist der gewählte Name für die ToCT-Vorlage und lang zeichnet die Sprache auf. Person ist eine Lücke, genau wie in TL, bei dem die Bezeichnung leer bleibt, da sie aus Wikidata abgerufen wird. Der nächste Teil besteht aus ar, einem unimorphen Wort, dessen anzuzeigende Bezeichnung är ist. Dann ist ageYears eine Lücke wie in TL, und der letzte aus mehreren Wörtern bestehende unveränderliche Teil, genannt argammal, ist ein Satz. Es endet mit einem Satzzeichen. Es gibt keine Abhängigkeiten und keine polymorphen Wörter.

Die Vorlagensyntax für das Ausführungsbeispiel in isiZulu war wie folgt:

Age_renderer_zu(Entity, Age_in_years):
"{subj:Person(Entity)} {root:SubjectConcord()}na{Year(Age_in_years)}."
Year_zu(years):
"{root:Lexeme(L686326} {concord:RelativeConcord()}{Copula()}{concord_1<nummod:NounConcord()}-{nummod:Cardinal(years)}"

Die ToCT-Syntax (auch unten erklärt):

@base <http://people.cs.uct.ac.za/~zmahlaza/templates/owlsiz/> .
@prefix toct: <https://people.cs.uct.ac.za/~zmahlaza/ontologies/ToCT#> .
@prefix mola: <https://ontology.londisizwe.org/mola#> .
@prefix co: <http://purl.org/co/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix cao: <http://people.cs.uct.ac.za/~zmahlaza/ontologies/ConcordAnnotationOntology#> .

<PersonAge> a toct:Template
    ; toct:supportsLanguage <lang>
    ; toct:hasFirstPart <Person>
    ; toct:hasLastPart <punct>
    ; toct:hasPart <hasyears>, <isof> .

<lang> a mola:Language
    ; mola:isFamily <isiZulu> .

<Person> a toct:Slot
    ; toct:hasLabel ""^^xsd:string
    ; toct:hasNextPart <hasyears> .

<hasyears> a toct:PolymorphicWord
    ; toct:reliesOn <Person>
    ; toct:hasFirstPart <SC>
    ; toct:hasPart <na>
    ; toct:hasLastPart <unyaka>
    ; toct:hasNextPart <isof> .

<isof> a toct:PolymorphicWord
    ; toct:hasFirstPart <RC>
    ; toct:hasPart <cop>
    ; toct:hasPart <nounprefix>
    ; toct:hasPart <dash>
    ; toct:hasLastPart <yearno>
    ; toct:hasNextPart <punct> .

<punct> a toct:Punctuation
    ; toct:hasValue "."^^xsd:string .

<SC> a toct:Concord
    ; cao:hasConcordType <subjC>
    ; toct:reliesOn <Person>
    ; toct:hasLabel ""^^xsd:string .

<na> a toct:UnimorphicAffix
    ; toct:hasValue "na"^^xsd:string .

<unyaka> a toct:Slot
    ; toct:hasLabel ""^^xsd:string .

<RC> a toct:Concord
    ; cao:hasConcordType <relC>
    ; toct:reliesOn <unyaka>
    ; toct:hasLabel ""^^xsd:string .

<cop> a toct:Copula
    ; toct:hasLabel ""^^xsd:string .

<nounprefix> a toct:UnimorphicAffix
    ; toct:reliesOn <yearno>
    ; toct:hasValue ""^^xsd:string .

<dash> a toct:UnimorphicAffix
    ; toct:hasValue "-"^^xsd:string .

<yearno> a toct:Slot
    ; toct:hasLabel ""^^xsd:string

Die Erläuterungen zur schwedischen Vorlage gelten hier ebenfalls, mit einigen Ergänzungen. Erstens gibt es weitere Elemente, wie zum Beispiel Concord und ein PolymorphicWord. Das Notationsprinzip für Letzteres ist dasselbe wie für die Vorlage: Es gibt eine Reihenfolge mit Teilen und für jeden Teil gibt es einen Eintrag mit weiteren Details. Zum Beispiel hat das polymorphe Wort isof einen Teil RC, der in seinem Eintrag weiter unten angibt, dass er vom Typ Concord ist, um welchen Concord-Typ es sich handelt (mit hasConcordType) und dass es reliesOn dem Teil, der mit unyaka identifiziert wird (unyaka ist eine Lücke zum Abrufen des Lexems aus Wikidata, es könnte aber auch eine Wurzel gewesen sein, von der man annimmt, dass sie bei Bedarf zu einem späteren Zeitpunkt pluralisiert wird). Dies entspricht dem Teil “{root:Lexeme(L686326} {concord:RelativeConcord()}” der TL-Vorlage.

Umwandlung in <System hier hinzufügen>

...

Referenzen

  1. Mahlaza, Zola; Keet, C. Maria (2021), AdeebNqo/ToCT, doi:10.5281/zenodo.5074931 
  2. Gillis-Webber, Frances; Tittel, Sabine; Keet, C. Maria (2019), A Model for Language Annotations on the Web, doi:10.1007/978-3-030-21395-4_1