Abstraktní Wikipedie/Šablonovací jazyk pro Wikifunkce

Návrh Ariela Gutmana a Maria Keet

Poznámka: Pokud vás zajímá hlavně implementace jazyka, podívejte se na implementaci níže.

Cílem tohoto dokumentu je navrhnout syntaxi šablonovacího jazyka, který by se používal v projektu Abstraktní Wikipedie. Jedná se o rozpracování dokumentu Architektura systému generování přirozených jazyků (NLG), a zejména jeho komponenty "šablonový renderer". Cílem tohoto dokumentu je navrhnout šablonovací jazyk. Toto je rozpracování dokumentu Architektura systému generování přirozeného jazyka (NLG). Lze jej implementovat na platformě Wikifunkcí transformací syntaxe "Kompozice", nebo v jiném programovacím prostředí, například v prostředí Wikipedie Scribunto, a případně jej lze mapovat nebo transformovat do jiných systémů NLG nebo realizátorů.

Klíčové změny oproti první verzi jsou následující: 1) zobecnění realizačního algoritmu, přičemž ten, který je přizpůsoben Wikifunkcím, tvoří přílohu; 2) explicitnější vyjádření některých návrhů a řešení připomínek, návrhů a příkladů vznesených členy komunity; 3) další názorná rozšíření, jako je vztah k jiným realizátorům a implementacím NLG.

Úvod

Van Deemter, Krahmer & Theune (2003) popisují systémy založené na šablonách takto:

Systémy založené na šablonách jsou systémy generující přirozený jazyk, které mapují svůj nejazykový vstup přímo (tj. bez zprostředkujících reprezentací) na jazykovou povrchovou strukturu (srov. Reiter a Dale (1997), s. 83-84). Podstatné je, že tato lingvistická struktura může obsahovat mezery; dobře zformovaný výstup je výsledkem tehdy, když jsou mezery vyplněny, přesněji řečeno, když byly všechny mezery nahrazeny lingvistickými strukturami, které mezery neobsahují.

Jinými slovy, šablony lze chápat jako sekvence (statického) textu proložené sloty nebo mezerami, které mají být vyplněny nějakým strukturovaným obsahem - ať už se jedná o data např. z databáze, znalosti z ontologie nebo jiného informačního zdroje se strukturovaným obsahem (v našem případě použití většinou informace pocházející z Wikidat, včetně nového abstraktního obsahu, který bude teprve definován) - nebo výsledek nějakého výpočtu (případně výstup jiné realizované šablony nebo funkce). V návrhu modulu NLG pro WF byl přidán další prvek (v návaznosti na Gutman et al., 2019; 2022), a to UD/[:en:Universal Dependencies SUD] anotace propojující sloty šablony, takže výsledným výstupem není pouhý řetězec textu, ale spíše syntaktický strom (nebo les stromů) definovaný nad sloty/částmi textu. Slot může odpovídat různým úrovním organizace syntaxe jazyka, a to fragmentu věty, slovu, podslovnímu morfému atd. V závislosti na syntaxi cílového přirozeného jazyka tak může být závislostní vazba definována mezi různými jazykovými prvky výsledné věty podle potřebné granularity.

Šablony lze přeložit jako bezkontextové gramatiky, v nichž texty slouží jako terminální symboly a sloty jako neterminální symboly. Z tohoto důvodu jsou šablony přinejmenším stejně expresivní jako systémy založené na CFG, které, jak známo, pokrývají většinu (ale ne všechny) jevů jazyka. Rozdíl mezi nimi spočívá v tom, že tvůrci šablonového systému si zpočátku nekladou nároky na to, aby pro úlohu NLG používali nějaké zprostředkující lingvistické reprezentace, ale ve skutečnosti - jak šablonový systém roste a stává se nezávislým na doméně - může získat šablony, které se podobají formální gramatice cílového jazyka.

V následujícím textu představíme navrhovanou syntaxi šablonovacího jazyka pro Wikifunkce, nejprve ve formě volného textového popisu a následně pomocí formálního zápisu jako CFG a jako logický model zobrazený diagramaticky (srov. Mahlaza & Keet 2021).

Syntaxe šablonovacího jazyka

Šablonu tvoří kombinace:

1. Volného textu, včetně interpunkčních znamének a lexémů (slov) se zvláštním chováním;
2. Slotů, což jsou interpolace parameterů nebo volání lexikálních funkcí a podšablon, případně anotované závislostním vztahem.

Podstatou je následující nenormativní diagram s klíčovými rysy šablonovacího jazyka v ORM notaci:

Ilustrační diagram s klíčovými prvky jazyka šablon v ORM notaci: obdélník s plnou čarou = entita; obdélník s přerušovanou čarou = hodnota (zhruba: atribut); obdélník s přepážkami a značkou vedle = vztah; šipka = subsumpce; fialová skvrna = povinné omezení; fialová čára nad obdélníkem = omezení jedinečnosti; fialové kolečko s kapkou = je povinné; fialové kolečko s čarou = vnější jedinečnost.

Jednotlivé části textu (oddělené mezerami) a sloty budeme souhrnně nazývat prvky šablony. Každá šablona má minimálně jeden prvek. Šablonovací jazyk umožňuje specifikovat závislostní spoje mezi sloty tak, že každou šablonu lze interpretovat jako strom nad zúčastněnými sloty. Protože dílčí šablony nemusí být nutně připojeny k tomuto stromu a dílčí šablona může mít označený vlastní kořen, umožňuje jazyk šablon specifikovat les nad sloty v různých dílčích šablonách, který pak může být v případě potřeby připojen ke kořenu superšablony. Záměrem této struktury je poskytnout závislostní gramatickou analýzu produktivních prvků v šabloně, která má být vodítkem pro realizaci. Oblíbené rámce závislostní gramatiky, které lze k tomuto účelu použít, jsou např. UD nebo SUD, ale je třeba si uvědomit, že tyto rámce obvykle poskytují analýzu pouze na úrovni slov, takže pokud jsou sloty spíše morfematické, pak by bylo třeba buď použít jiný rámec gramatiky, nebo rozšířit rámec závislostní gramatiky UD/SUD (např., jak bylo nedávno navrženo pro UD nebo úzce související catena).

Sloty jsou ohraničeny složenými závorkami a skládají se ze dvou částí podle následující syntaxe (hranaté závorky označují volitelnost):

{[dependencyLabel:]invocation}

1. dependencyLabel: Volitelná část dependencyLabel má následující syntaxi, skládá se ze tří prvků, za nimiž následuje dvojtečka: role[_index][<sourceLabel]:
   • role označuje (příchozí) závislostní vztah slotu, a je tedy povinnou složkou dependencyLabel.
     • Slot, který funguje jako kořen (neboli head) stromu závislostí, musí mít roli root. Pokud jsou v šabloně použity štítky závislostí, musí být přesně jeden slot označen jako root.
     • Každá role by měla odpovídat funkci Wikifunkcí, která transformuje strom lemmat tak, aby odpovídal použití dané role; např. role subj by vynucovala shodu subjektu a slovesa ve stromu lemmat. Tyto funkce Wikifunkcí jsou specifické pro daný jazyk a navíc mohou mít v daném jazyce štítek (např., "onderwerp" pro subj v nizozemštině).
   • _index je nepovinné kladné celé číslo následující za podtržítkem, které umožňuje rozlišit více slotů se stejnou rolí (např. dva adjektivní modifikátory: amod_1, amod_2). Kombinace role a index musí být v každé šabloně jedinečná.
     • Kombinace role a index musí být v každé šabloně jedinečná.
     • Pokud je samotná role v rámci šablony jedinečná, není indexová část potřeba.
   • <sourceLabel je nepovinný řetězec za otevírací hranatou závorkou, který umožňuje specifikovat zdroj příchozího vztahu zadaného jako označení zdrojového slotu (což je jeho role následovaná nepovinným indexem). Není-li zdroj uveden, je slot root implicitně považován za zdroj.
   • Pokud se vyskytuje, následuje za částí dependency label dvojtečka, která ji odděluje od volání.
2. invocation může být jeden ze tří typů: functionInvocation() nebo interpolation nebo "string"
   • functionInvocation() je, jak už název napovídá, voláním funkce. Funkce může mít mezi závorkami seznam argumentů oddělených čárkou, které mohou být samy o sobě voláními jak je definováno výše. Všimněte si, že volaná funkce může být dílčí šablonou.
   • interpolation se rovná vyplnění slotu formálním argumentem šablony. Protože argument obecně není požadovaného návratového typu slotu, aby to fungovalo, musí být na parametr použita implicitní konverzní funkce. Zejména formální parametry, které jsou konstruktory, při interpolaci způsobí vyvolání odpovídající šablony s jejich poli, aby bylo možné kompozicionality.
   • "string" (libovolný text opatřený uvozovkami) je ekvivalentní použití stejného řetězce jako volný text, ale s tím rozdílem, že může být označen závislostní rolí jako jakýkoli jiný slot.

Formalizace jako CFG

Výše uvedenou syntaxi lze formalizovat jako soubor pravidel CFG. Neterminální symboly jsou uvedeny kurzívou, zatímco terminální symboly (a také množiny terminálních symbolů) jsou uvedeny jako monospace.

Pravidlo	Komentář
Template → Element
Element → {Slot} | Text | Element Element
Text → lexeme | punctuation | string	lexém je množina všech tvarů, které mají stejný význam (např. sedět, sedí a sedím), ale nakonec vede k lemmatu, takže ji berte jako Text končící terminálem - zkrácená notace. punctuation je také množina, která nakonec vede k terminálnímu symbolu, a i pro něj je zde použita zkrácená notace. string může být libovolná kombinace znaků s výjimkou mezer a { }.
Slot → DependencyLabel : Invocation | Invocation
DependencyLabel → Label < SourceLabel | Label | root
Label → Role _ Index | Role
Role → …	konečná množina jmen rolí (kromě kořene), například převzatých z UD/SUD nebo jejich rozšíření
Index → 1 | 2 | …	konečná množina celých kladných čísel
SourceLabel → Label	zdrojový štítek může být pouze jeden z těch, které byly použity jako Label jinde v šabloně; zde pro přehlednost používáme jiný neterminálový název
Invocation → FunctionInvocation | Interpolation | String
FunctionInvocation → F(ArgumentList) | F()	funkce s proměnným, případně prázdným, počtem parametrů
ArgumentList → invocation | invocation , ArgumentList	Jakékoli volání může sloužit jako parametr
F → functionName | templateName	Jedná se o názvy funkcí (nebo šablon, které se chovají jako funkce) dostupných v systému
Interpolation → interpolation	množina jmen (polí v konstruktoru), která jsou pouze terminály, proto je zde použit zkrácená notace.
String → "string"	samozřejmě také množina terminálů (umístěných v rámci “ a ”), zkrácená notace.

Existují tři úrovně funkce šablony, které je třeba zaznamenat u každé šablony, ale které nemají vliv na části, které budou předmětem vykreslování. Jsou to:

• Název/identifikátor šablony (povinné). V daném rozsahu šablon (který je definován implementací) musí být název jedinečný.
• Jazyk, ve kterém je šablona vykreslena (povinný). Kód jazyka by měl odpovídat jazykům, které se používají, plánují se používat nebo se mohou v budoucnu používat ve Wikidatech.
• "Propozice" (nepovinné). Konstruktor může být spojen s více než jednou šablonou, tj. může k němu být přiřazen seznam variantních šablon. Takový seznam variantních šablon bude mít jednu nebo více předběžných propozicí pro výběr příslušné šablony. Vybere se a realizuje první variantní šablona, která splňuje předběžné propozice. Propozice mohou zahrnovat parametry, jako např:
  • Podmínky náhodné nebo řazení variant šablon pro injektování varianty;
  • Globální, jazykově specifické nebo specifické parametry pro vykreslení, jako je úroveň formálnosti nebo slovosled;
  • Zda jsou určitá pole konstruktoru přítomna, nebo ne, případně podmínky pro jejich hodnoty;
  • Gramatická role dílčí šablony v rámci nadřazené šablony (definovaná závislostí).
  • V případě potřeby mohou být upřesněny další.

Rozšíření pomocí podmíněných funkcí

Syntaxi lze rozšířit o takzvaný "syntaktický cukr", což je zkrácený zápis pro složitější šablony s více podšablonami. Například volání slotu lze rozšířit o jednu nebo více podmíněných funkcí, například takto:

{[dependencyLabel:](invocation)[|conditionalFunction]*}

Volitelná část conditionalFunction, která se může opakovat tak, že se od předchozí funkce oddělí symbolem svislítka, určuje volání podmíněné funkce, která kromě zadaných parametrů přebírá i výsledek volání před symbolem svislítka. Jinými slovy, jedná se o funkci, která přijímá seznam lexémů a vrací upravený seznam lexémů. Některá možná použití jsou následující:

• To umožňuje podmíněné elidování slotů (při případném zachování jejich gramatických rysů) nebo podmíněnou pronominalizaci (generování odkazovacích výrazů); např. "Lev Simba ... ; on ..." srov. opakování "Lev Simba ... ; Simba ...".
• Umožňuje větší flexibilitu ve struktuře věty, aby se usnadnila volba mezi alternativními slovy ve slotu, jako je běžná změna pořadí vět; např. "protože x, udělali jsme y" a "udělali jsme y, protože x".
• a případně další operace.

Důvodem této syntaxe namísto prostého skládání funkcí je zvýšení čitelnosti šablony, protože hlavní část invocation by měla jasně označovat typ vykreslovaného výsledku, který ve slotu očekáváme. Bez tohoto syntaktického cukru by bylo možné vložit jednu funkci do druhé a získat {ConditionalFunction(invocation, conditional_arguments)} nebo přidat podmíněnou vrstvu nad (pod)výběr šablony, aby bylo možné takové předběžné podmínky zpracovat.

Příklady syntaxe jsou uvedeny níže.

Stěžejní funkce

Základním prvkem jazyka šablon jsou volání funkcí v rámci slotů. Tato volání funkcí by měla vracet buď lexémy (paradigmata skloňovaných forem spojených s gramatickými rysy, podobně jako lexémy Wikidat), nebo částečně specifikované syntaktické stromy lexémů, kde je minimálně uveden kořenový lexém každého podstromu.

Stěžejní funkce jazyka šablon však vracejí jednotlivé lexémy. Tyto stěžejní funkce budou napsány přispěvateli Abstraktní Wikipedie, takže neexistuje žádný uzavřený seznam. Příklady funkcí, které lze předem nebo časem považovat za stěžejní funkce, mohou být např:

• Lexeme(L-id, …): Načte lexém Wikidat spojený s L-id (v daném jazyce) a převede jej na typ Lexém. Dalšími parametry mohou být Q-id gramatických rysů, které omezují výběr vzoru.
• Label(entity) nebo Label(entity, language): Načte štítek spojený s Q-id v daném jazyce, který je výchozí pro jazyk realizace, pokud není zadán.
• Cardinal(integer): Vytvoří lexém singleton, který se skládá z celého čísla (popř. hláskového) s odpovídajícím gramatickým číslem (jednotné/množné číslo/atd.).
• Ordinal(integer): Vytvoří lexém singleton odpovídající požadovanému pořadovému číslu (případně se skloňováním, v závislosti na jazyce).
• TemplateText(string): Vytvoří lexém odpovídající vstupnímu řetězci.

Kromě toho lze implementovat funkce odpovídající konkrétním sémantickým doménám, například:

• Person(entity): Podobně jako Name, ale doplňuje gramatický rod v souladu s rodem osoby, případně vytváří i pronominalizované formy lexémů.

Dispečink funkcí specifických pro daný jazyk

Všechny výše uvedené funkce mohou mít (a pravděpodobně budou mít) implementaci specifickou pro daný jazyk. Způsob volby jazykově specifické implementace závisí na implementaci.

Zpracování připomínek

K šabloně nebo prvku šablony můžete chtít přidat komentáře. V současné specifikaci neexistují pro prvky samostatná pole pro poznámky. V případě potřeby může každá implementace přidat návod ke komentářím, podobně jako se přidávají komentáře v kódu: můžete je umístit kdekoli ve specifikaci, před nimiž je vhodný vyhrazený znak (znaky). Tento vyhrazený řetězec závisí na implementaci, ve které jsou uloženy specifikace šablony.; např., s // comment here, jak je použito ve výše uvedené specifikaci CFG, % comment here, nebo <!-- comment here -->. Například ve Wikifunkcích se komentáře zobrazují i na patičce funkce, což by se dalo převzít i pro šablony nebo jinou doplňkovou součást rozhraní.

Realizační algoritmus

Realizace šablony zadané pomocí výše uvedeného zápisu probíhá v pěti různých fázích.

Fáze 1

Všechny prvky šablony jsou rozvinuty vyhodnocením jejich obsahu: textové prvky, řetězce slotů a interpolace řetězců jsou transformovány na lexémy (buď pomocí obecné funkce, nebo funkce specifické pro daný jazyk) a všechny funkce slotů jsou vyhodnoceny se svými parametry. Všimněte si, že při vyhodnocování podšablon je třeba je vyhodnotit rekurzivně až do fáze 2 (podrobněji níže).

Výsledkem vyhodnocení každého textového prvku nebo slotu by měl být buď lexém, nebo datový typ seznamu lexémů:

• Lexém se skládá z množiny forem, z nichž každá má svůj vlastní pravopis spojený se seznamem gramatických rysů a také se seznamem společných gramatických rysů (platných pro všechny formy nebo je omezující). Každý gramatický rys se skládá z identifikátoru (např. "singulár") spojeného s gramatickou kategorií (např. "číslo"). Mezi těmito gramatickými rysy by měl být povinný rys slovní druh. Všimněte si, že ohledně výše uvedených termínů panuje určitý zmatek, protože různé zdroje používají termín feature buď jako kategorii, nebo jako specifickou hodnotu kategorie (viz Kibort & Corbett, 2008, kde se o této terminologii hovoří). Zde používáme termín feature v užším smyslu pro označení hodnoty kategorie (např. plurál) a v širším smyslu (psáno tučně) pro označení výše uvedeného datového typu označujícího jak kategorii, tak jí přiřazenou hodnotu.

  Všechny textové prvky a většina základních funkcí by se měly vyhodnocovat jako datový typ lexém.

• Seznam lexémů je jednoduše uspořádaný seznam položek, z nichž jedna je identifikována jako kořen seznamu. Každá položka je sama o sobě buď lexém, nebo seznam lexémů. To znamená, že seznam lexémů je částečně specifikovaný strom lexémů. Rekurzivním ponořením do kořene seznamu lexémů se nakonec dostaneme k jedinému lexému, který se označuje jako kořenový lexém seznamu.

  Výsledkem vyhodnocení šablon by obecně měl být seznam lexémů (s výjimkou zvláštního případu, kdy se šablona vyhodnotí jako jediný lexém), přičemž každá položka tohoto seznamu odpovídá jednomu prvku šablony. Navíc prvek, který je dán kořenovým štítkem, který by měl odpovídat položce, která je identifikována jako kořen seznamu.

Fáze 2

V této fázi se vyhodnocují štítky závislostí šablony. Na pořadí vyhodnocení nezáleží. Pro každý slot šablony s označením nazýváme samotný slot cílový slot. Slot, na který odkazuje štítek slotu, se nazývá zdrojový slot. Pokud není k dispozici štítek slotu, je zdrojový slot vždy považován za kořenový slot šablony (ten, který je identifikován příkazem kořenový štítek).

Cílový lexém je lexém, který je výsledkem vyhodnocení cílového slotu. Pokud je výsledkem tohoto vyhodnocení seznam lexémů, vybereme kořenový lexém tohoto seznamu. Podobně najdeme zdrojový lexém.

Každé označení závislosti by mělo odpovídat funkci, která jako vstupní argument přijímá dva argumenty lexému, kterými jsou zdrojový a cílový lexém. Pokud taková funkce neexistuje, je závislostní značka inertní. Aby bylo zajištěno, že pořadí vyhodnocování funkcí závislostního štítku je nepodstatné, smí každá taková funkce používat pouze následující tři operace:

• Verifikace slovního druhu lexému s ohledem na závislostní štítek (tj. slovní druh by měl být podřazena pod nějaký typ slovního druhu).
• Sdílení některých vlastností, identifikovaných podle jejich kategorií, mezi dvěma lexémy pomocí sjednocení. Vlastnosti lze sjednotit pouze tehdy, jsou-li kompatibilní podle dané hierarchie vlastností. Jakmile jsou sjednoceny, jsou sdíleny napříč lexémy a jakákoli následná změna této vlastnosti prostřednictvím některého z lexémů (např. pomocí jiné funkce závislostního vztahu) by se dotkla i druhého lexému.
• Modifikace některých vlastností některého z lexémů předem určenou hodnotou, například přiřazení "nominativu" elementu, který je subjektem. Toho se dosáhne sjednocením vlastnosti, identifikovaného jeho kategorií, s předem stanovenou hodnotou.

Všimněte si, že výše uvedené sjednocovací operace působí pouze na gramatické rysy na úrovni lexému, nikoli na vlastnosti na úrovni formy. Po této fázi společné gramatické rysy každého lexému nemusí nutně platit pro všechny formy, ale představují spíše gramatická omezení na formy.

Fáze 3

V tomto okamžiku již není stromová struktura seznamu lexémů nutná a seznam lze zploštit. Poté se projde výsledný seznam lexémů šablony a seznam forem každého lexému se ořízne podle gramatických omezení a v případě gramatické nedourčenosti, Seřazeny' lexikograficky podle předem stanovené relativní důležitosti gramatických kategorií a rysů, což zajišťuje, že formy s výchozími nebo neoznačenými rysy (např. "nominativ") mají přednost.

Pročištění tvarů lze provádět dvěma způsoby v závislosti na konzistenci a čistotě lexikálních dat:

• Pokud je známo, že lexikální data jsou konzistentní a čistá v tom smyslu, že existují formy pro všechny lingvisticky možné kombinace rysů a jsou zastoupeny přesně potřebné gramatické kategorie, lze provést striktní ořezávání, při kterém se zachovají pouze formy, které splňují omezení. Konkrétně to znamená, že pokud má forma gramatickou kategorii, která není uvedena v omezeních, bude ořezána. Z výsledných forem navíc odstraníme formy, které subsumují všechny ostatní formy v tomto seznamu. To se rovná hledání nejkonkrétnějších forem (z hlediska hierarchie rysů), které ještě subsumují omezení.
• Pokud jsou lexikální data známa pouze částečně nebo jsou "nečistá", může realizátor použít alternativní strategii s nejlepší snahou. Může se jednat o částečné ořezávání, kdy je zachován jakýkoli tvar, jehož omezení jsou sjednotitelná s omezeními, nebo o nějakou formu ořezávání člověkem ve smyčce, kdy se hledá vstup od uživatele, aby se vyplnila mezera a mohlo se přejít na přísné ořezávání, nebo o nějaký způsob něžné degradace, aby se odstranila postižená část.

Výsledkem obou těchto metod pročištění může být více zbývajících forem. Z tohoto důvodu je důležité seřadit formy podle kanonického pořadí, aby bylo možné nakonec vybrat preferovanou formu.

Fáze 4

V této fázi se prochází lineární seznam lexémů, odstraňují se prázdné lexémy (které mohou být výsledkem prázdné realizace podšablony nebo některých volání funkcí) a zjišťují se (nebo vyhledávají) fonologická omezení. To umožňuje výběr fonologicky podmíněných forem různých lexémů, čímž se účinně modelují jevy typu sandhi (jak uvnitř slova, tak na jeho hranicích).

Specifika této fáze závisí na jazyku realizace. Obecně platí, že ty lexémy, které mají fonologicky podmíněné formy, musí přistupovat k fonologické reprezentaci (nebo rysům) svých sousedních lexémů v lineárním seznamu lexémů a podle toho vybrat odpovídající formu. Všimněte si, že to může znamenat další ořezání existujícího seznamu forem (podle daných fonologických omezení) nebo může být použita nějaká logika k mutaci existujících forem.

V této fázi by mělo dojít také k nezbytnému sloučení forem. Jedná se o podobný postup jako při výběru fonologicky podmíněné formy, ale týká se více než jednoho lexému (obvykle dvou). V některých případech může vést k modifikaci jedné formy lexému a odstranění druhé formy lexému, kdy dojde ke splynutí dvou forem.

Fáze 5

V této fázi se vytváří konečný text. Preferované formy všech lexémů (první z ořezaného a seřazeného seznamu forem) jsou spojeny dohromady, přičemž mezi nimi jsou vhodné mezery. Obecně se dodržuje řádkování původní šablony, i když po sobě jdoucí řádky mezer mohou být zmenšeny na jednu mezeru. Některé mezery však mohou být odstraněny, zejména v blízkosti interpunkčních znamének nebo lexémů, které jsou označeny jako (ortografická) klitika.

V této fázi se také zpracovávají velká písmena a interpunkce, přičemž se odstraní interpunkce, která se při konečné realizaci stane nadbytečnou (k tomu může dojít, pokud se některá dílčí šablona realizuje například jako prázdný řetězec), a velká písmena na začátku věty (v jazycích, kde je to potřeba).

Příklady šablon

Pro ilustraci syntaxe šablony a výsledné syntaxe kompozice prozkoumejme příklad konstruktoru uvedený v dokumentu o architektuře:

Age(
    Entity: Malala Yousafzai (Q32732)
    Age_in_years: 24
)

V tomto jednoduchém příkladu jsou pro vygenerování věty (např. "Malálé Júsufzajové je 25 let") nutná obě pole konstruktoru, ale mohly by existovat konstruktory s nepovinnými poli, které by umožnily větší flexibilitu.

Můžeme předpokládat, že konstruktor je přiřazen (orchestrátorem nebo specializovanou funkcí Dispatch) k volání šablonové funkce ve tvaru Age_renderer_xx, kde xx znamená kód jazyka. Kromě toho jsou podpole konstruktoru k dispozici jako formální argumenty těchto funkcí. Pro zjednodušení výkladu zde používáme anglické značky, ale v praxi mohou být jméno konstruktoru i jeho parametry klidně Z-id.

Podívejme se, jak může vypadat implementace pro různé jazyky v syntaxi šablony a v odvozené syntaxi kompozice. Aby byly příklady realističtější (a zajímavější), předpokládejme, že některé z nich využívají volání dílčí šablony Year_xx, jejímž úkolem je vykreslit právě podstatné jméno "n let".

Švédština

Ve švédštině není (osoba) slovní skloňování. Pouze číslovka 1 se v tomto kontextu může skloňovat podle rodu podstatného jména, ale pokud nás zajímá pouze číselný výstup, je to irelevantní. Výsledná šablona je tedy velmi jednoduchá, protože není potřeba žádná gramatická shoda.

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

Francouzština

Za předpokladu, že se konstruktor Age vždy vztahuje k lidem, lze u tohoto konstruktoru ponechat hlavní sloveso avoir v jednotném čísle ve tvaru a, takže není třeba slovesné shody. Na druhou stranu podstatné jméno pro rok, an, se může skloňovat podle čísla (ans v množném čísle). K zakódování této skutečnosti použijeme gramatický závislostní vztah [avoir nummod]. Účinek tohoto vztahu (shoda rodu a čísla mezi podstatným jménem a kvantifikátorem) je definován jinde (v příslušné funkci).

Age_renderer_fr(Entity, Age_in_years):

"{Person(Entity)} a {Year(Age_in_years)}."

Year_fr(years): "{nummod:Cardinal(years)} {root:Lexeme(L10081)}"

Hebrejština

V hebrejštině jsou navíc dvě komplikace: jedna spočívá v tom, že hlavní predikát (pseudoverbální částice) se musí shodovat v rodě s podmětem (a přebírá počet let jako genitivní doplněk, označený pomocí závislostní značky gmod). Druhým důvodem je, že konstrukce pro vyjádření "n let" (v kontextu věku) vyjadřuje pouze n nebo rok v závislosti na hodnotě n. Můžeme předpokládat, že vestavěná funkce ElideIf umožňuje podmíněnou eliminaci textového obsahu seznamu lexémů, aniž by byly odstraněny gramatické rysy jejich kořene. Pomocí syntaxe Piping ji lze snadno aplikovat na základní volání slotu.

Age_renderer_he(Entity, Age_in_years):

"{subj:Person(Entity)} {root:GenderedLexeme(L64310, L64399)} {gmod:Year(Age_in_years)}."

Year_he(years):

"{nummod:Cardinal(years)|Elide_if(years<=2)} {root:Lexeme(L68440)|Elide_if(years>2)}"

Zulu

V jazyce zulu (tzv. isiZulu) je obecná struktura věty podobná větě "Osoba má rok(y), které jsou N" (Výstup pro příklad: UMalala Yousafzai uneminyaka engama-25). Je třeba dbát na několik úrovní shody:

1. Funkce Person pro jazyk Zulu by měla načíst jméno osoby spolu s příslušnou jmennou značkou (což je vždy u pro osoby, zapsané jako u- před samohláskami).
2. Sloveso "mít" (na-) se musí shodovat s podmětem pomocí značky shody. Zatímco obecně mají lidé vždy předmětový marker u-, pro účely příkladu zde připouštíme obecnější vzor shody předmětu, a to vynucením vztahu subj mezi slotem subject a slotem, který načítá morfém Subject Concord (pomocí stejnojmenné funkce). Morfém shody subjektu se řídí třídou podstatného jména v roli subjektu.
3. Slovo pro rok unyaka (pl. iminyaka), reprezentované L-id L686326, se shoduje v čísle (jednotné/množné) s věkem. Toho je dosaženo vynucením vztahu nummod mezi intervalem roku a intervalem čísla věku.
4. Relativní shoda spojuje roky s počtem let. Určuje se podle třídy podstatného jména léta (která se liší pro jednotné a množné číslo). Toho je dosaženo prostřednictvím vztahu concord aplikovaného na funkci načítající relativní konkordanční značku, jejímž zdrojem je lexém "rok", který má zase jako vlastnost třídu podstatného jména, jehož je součástí.
5. Samotná číslovka věku je považována za podstatné jméno a vyžaduje předponu podstatného jména. Toho se opět dosáhne pomocí vztahu concord, který má tentokrát svůj zdroj v kardinálním čísle věku. Předpokládáme, že funkce Cardinal_zu pro jazyk Zulu obohacuje kardinální lexém o příslušnou třídu podstatných jmen podle pravidel jazyka.

Kromě těchto morfosyntaktických vzorců shody je třeba provést několik fonologických úprav. O ty se postarají následující části NLG pipeline, ale pro úplnost je zde uvádíme:

1. Sloveso na ("mít") se píše jako jedno slovo spolu s následujícím slovem iminyaka ("roky"). Hláska /a/ se spojuje (tj. hlásková koalescence) s /i/ a vzniká /e/.
2. Kopula ba ("být") je v tomto kontextu realizována jako y, pokud po ní následuje /i/, jinak ng. Zde je ukázána funkce Copula().

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)}"

Bretonština

(Děkujeme VIGNERON za uvedení tohoto příkladu)

Bretonština je podobná švédštině v tom, že zde není nutné morfologické skloňování, protože podstatná jména mají po číslovkách vždy tvar jednotného čísla. Výsledná věta pro příkladovou konstrukci by měla znít "25 bloaz eo Malala Yousafzai". Z tohoto důvodu nemusíme slot lexému "rok" (bloaz, Lexém L45068) anotovat žádnou značkou závislostního vztahu, protože by byl standardně vybrán tvar jednotného čísla. Na druhou stranu slovo bloaz může projít fonologickou mutací (tzv. "změkčením") po určitých číslicích (1, 3, 4, 5 a 9) a číslo 1000 a stát se vloaz. Abychom to zohlednili, musíme předpokládat, že bretonská implementace funkce Cardinal (Cardinal_br) anotuje vykreslené číslo fonologickým rysem, který naznačuje, že toto číslo může vyvolat změkčení na tokenu, který za ním následuje. V takovém případě by se o změkčení následujícího podstatného jména postaral fonotaktický modul architektury NLG, aniž by bylo nutné anotovat závislostní značku.

Age_renderer_br(Entity, Age_in_years):

"{Cardinal(Age_in_years)} {Lexeme(L45068)} eo {Person(Entity)} ."

Instrumentalizace syntaxe šablony

Sémantika syntaxe šablony je dána jejím realizačním algoritmem, který může být implementován tak, jak je (viz také implementace), nebo může být syntaxe šablony použita jiným způsobem. V kontextu Wikifunkcí je třeba syntaxi šablony algoritmicky namapovat na kompoziční syntaxi Wikifunkcí. Jiné přístupy mohou zahrnovat mapování syntaxe šablon na jiné rámce NLG. Níže je uvedena ukázka; další mohou být přidány ve vhodnou dobu, jak se bude zvyšovat zájem, techniky a nástroje.

Transformace syntaxe šablon na kompoziční syntaxi Wikifunkcí

See also: Abstract Wikipedia/Template Language for Wikifunctions/Transformation of template syntax to Wikifunctions

Transformace syntaxe šablon na jiné formalismy v realizátorech NLG

See also: Abstract Wikipedia/Template Language for Wikifunctions/Transformation of template syntax to other formalisms

Implementace

V současné době existuje jediná implementace systému, a to jako modul Scribunto.

See also: Abstract Wikipedia/Template Language for Wikifunctions/Scribunto-based implementation