Unification des metadix et dictionnaires paramétrés

In English

Les paquets de différentes paires de langues utilisent différentes stratégies pour générer les dictionnaires .dix (dictionnaire unilingue) et (bidix) depuis des fichiers XML en utilisant des caractéristiques non supportées par le format .dix . Les objectifs de ces nouveaux formats dix-like sont :

• être capable d'utiliser des paradigmes paramétrés (ainsi un paradigme général peut être défini et utilisé avec de petites variations de paramètres), comme discuté dans la page Fichiers metadix et métaparadigmes;
• être capable de générer différentes versions d'un traducteur (par exemple, pour deux variétés différentes d'une langue, comme pour le portugais du brésil et d'europe) dont les noms pourraient être idéalement liés aux noms de modes.

Il y a actuellement un débat sur l'unification de ces formats dans un format metadix unique qui à son tour pourrait être aussi utilisé pour supporter d'autres caractéristiques souhaitables comme :

• avoir des méta-données (en-tête) dans les dictionnaires qui définissent si le dictionnaire est bilingue ou unilingue et les paires de langages et modes qu'il supporte (peut être que ça pourrait être rajouté au format .dix de base).

Voici une proposition (ouverte à la discussion) sur les deux premiers problèmes.

En-tête

Il serait utile d'avoir le(s) nom(s) de la/des langue(s) et probablement quelque autre information (peut-être sur les variétés ?) spécifiées dans une sorte de fichier d'en-tête.

<dictionary>
  <header>
    <type>monolingual</type>
    <language code="ca" full="Català"/>
    <alternatives>
      <alternative code="ca@valencian" full="Valencià"/>
      <alternative code="ca" full="Català"/>
    </alternatives>
  </header>
 
  ...

Alternatives

• En dotant l'élément e avec un attribut alt (variante) (actuellement v dans quelques dictionnaires et aversion [sic] dans d'autres), afin que l'entrée correspondante du metadix aille au .dix généré seulement si cette alternative ou variante est sélectionnée (les entrées sans alt iront dans le .dix sans condition); ça remplacera l'utilisation de l'attribut v ou aversion comme trouvé dans les dictionnaires es-ca pour traiter le dialecte valencien ou dans les dictionnaires es-pt pour distinguer le portugais d'europe et du brésil, ou dans les dictionnaires oc-ca pour distinguer la variété aranese. Voici un exemple du dictionnaire unilingue es-ca :

       <e alt="ca">
         <p>
           <l>haguéssim</l>
           <r>haver<s n="vbhaver"/><s n="pis"/><s n="p1"/><s n="pl"/><j/></r>
         </p>
       </e>

       <e alt="ca@valencian">
         <p>
           <l>haguérem</l>
           <r>haver<s n="vbhaver"/><s n="pis"/><s n="p1"/><s n="pl"/><j/></r>
         </p>
       </e>  

Et un exemple du dictionnaire unilingue es-pt

    <e lm="correto" alt="pt_BR">
        <i>corret</i>
        <par n="abert/o__adj"/>
      </e>
      
      <e lm="correcto" alt="pt_PT">
        <i>correct</i>
        <par n="abert/o__adj"/>
      </e>

Dans les fichiers de transfert de structure, les règles rule peuvent aussi avoir des variantes comme observé dans le paquet es-pt. La proposition est de doter l'élément rule de l'attribut alt (actuellement v ou aversion) :

• avoir une façon de marquer un groupe d'entrées comme appartenant à une certaine variante. A cette fin, un élément enveloppant e-group (nom en discussion; actuellement appelé aversion [sic]) contiendrait un ensemble d'entrées et ce sera équivalent à avoir toutes ces entrées marquées avec une certaine valeur de l'attribut alt ainsi cette écriture

<e-group alt="xx">
<e> ... </e>
<e> ... </e>
</e-group>

serait équivalente à avoir

<e alt="xx"> ... </e>
<e alt="xx"> ... </e>

Ça pourrait être vu comme une manière de factoriser une valeur commune de alt. Peut-être qu'on pourrait étendre l'utilisation de e-group pour factoriser d'autres attributs comme r.

Ça pourrait être étendu à d'autres fichiers de données linguistiques comme les fichiers de transfert de structure (.t1x, .t2x, etc.). L'élément correspondant serait rule-group.

Probablement c'est une bonne idée que toutes les valeurs possibles de alt soient déclarées auparavant dans l'en-tête (voir plus haut).

Une généralisation de ceci serait un élément wrap possédant trois attributs : element (le nom de l'élément affecté), attribute (le nom de l'attribut) et value (la valeur de l'attribut), ainsi <wrap element="e" attribute="alt" value="xx"> serait équivalent à <e-group alt="xx"> et <wrap element="rule" attribute="alt" value="xx"> serait équivalent à <rule-group alt="xx">, mais peut-être que c'est trop général.

Les paradigmes paramétrés

Il y a deux sortes de paradigmes paramétrés, qui pourraient être appelés paradigmes de formes de mots et paradigmes de symboles (les paradigmes de formes de mots sont observés dans la paire oc-ca pair et les paradigmes de symboles grammaticaux sont observés dans les dictionnaires en-ca).

Utilisation actuelle des paradigmes de formes de mots

Voici un exemple de paradigmes de formes de mots comme utilisé actuellement dans les dictionnaires oc-ca :

    <pardef n="ab/i[T]ar__vblex">
        <e aversion="oc@aran-ca">
                <p>
                        <l>í</l>
                        <r>i</r>
                </p>
                <i><prm/></i>
                <par n="cànt/iga__vblex"/>
        </e>
        <e aversion="oc@aran-ca">
                <i>i<prm/></i>
                <par n="cant/ar__vblex"/>
        </e>
        <e aversion="oc-ca">
                <i>i<prm/></i>
                <par n="cant/as__vblex"/>
        </e>
    </pardef>

Dans l'exemple, <prm/> sera substitué par la valeur du paramètre simple, comme dans :

        <e lm="abitar">
                <i>ab</i>
                <par n="ab/i[T]ar__vblex" prm="t"/>
        </e>
        <e lm="abocinar">
                <i>aboc</i>
                <par n="ab/i[T]ar__vblex" prm="n"/>
        </e>
        <e lm="originar">
                <i>orig</i>
                <par n="ab/i[T]ar__vblex" prm="n"/>
        </e>
   
        <e lm="brilhar">
                <i>br</i>
                <par n="ab/i[T]ar__vblex" prm="lh"/>
        </e>

Il y a seulement un unique paramètre sans nom <prm/>, ce qui pourrait être une limitation dans certaines applications. Ne soyez pas trompé par le nommage des paradigmes : ce n'est pas analysé, et c'est juste pour que le rédacteur du dictionnaire se rappelle ce qui est substitué et gardé.

Utilisation actuelle des paradigmes de symboles

Voici un exemple de paradigmes de symboles comme utilisé dans le dictionnaire en-ca :

 <pardef n="house__n">
   <e c="CP: nouns which add -s">
      <p>
         <l/>
         <r><s n="n"/><sa/><s n="sg"/></r>
      </p>
   </e>
   <e>
      <p>
         <l>s</l>
         <r><s n="n"/><sa/><s n="pl"/></r>
      </p>
   </e>
 </pardef>

Alors, le placeholder (??) <sa/> sera substitué par un symbole <s n="..."> nommé comme la valeur de l'attribut sa :

<e lm="time"><i>time</i><par n="house__n" sa="unc"/></e>

C'est les mêmes limitations que dans le cas des paramètres de formes de mots (paramètre unique, etc.). En plus, l'utilisation de la première et de la deuxième méthode est hétérogène et pourrait être unifiée quelque peu.

Une proposition unifiée

Paramètres de formes de mots

Voici les deux exemples ci-dessus dans la nouvelle notation proposée, qui sera expliquée plus bas :

    <pardef n="ab/i[T]ar__vblex" prm-list="cons">
        <e vnt="oc@aran">
                <p>
                        <l>í</l>
                        <r>i</r>
                </p>
                <i><txt-prm n="cons"/></i>
                <par n="cànt/iga__vblex"/>
        </e>
        <e vnt="oc@aran">
                <i>i<txt-prm n="cons"/></i>
                <par n="cant/ar__vblex"/>
        </e>
        <e vnt="oc">
                <i>i<txt-prm n="cons"/></i>
                <par n="cant/as__vblex"/>
        </e>
    </pardef>

et l'appel :

        <e lm="abitar">
                <i>ab</i>
                <par n="ab/i[T]ar__vblex" prms="cons='t'"/>
        </e>
        <e lm="abocinar">
                <i>aboc</i>
                <par n="ab/i[T]ar__vblex" prms="cons='n'"/>
        </e>
        <e lm="originar">
                <i>orig</i>
                <par n="ab/i[T]ar__vblex" prms="cons='n'"/>
        </e>   
        <e lm="brilhar">
                <i>br</i>
                <par n="ab/i[T]ar__vblex" prms="cons='lh'"/>
        </e>

L'utilisation de paramètres nommés permet un mécanisme simple pour des paramètres multiples. Par exemple le paradigme paramétré peut avoir prm-list="cons vowel" et les appels peuvent avoir, par exemple, prms="cons='lh' vowel='a'".

Paramètres de symboles

Voici les deux exemples de paramètres de symboles ci-dessus dans la nouvelle notation.

La définition du paradigme :

 <pardef n="house__n" prm-list="countable">
   <e c="CP: nouns which add -s">
      <p>
         <l/>
         <r><s n="n"/><symbol-prm n="countable"/><s n="sg"/></r>
      </p>
   </e>
   <e>
      <p>
         <l>s</l>
         <r><s n="n"/><symbol-prm n="countable"/><s n="pl"/></r>
      </p>
   </e>
 </pardef>

Et l'appel :

<e lm="time"><i>time</i><par n="house__n" prms="countable='unc'"/></e>

d'une manière complètement analogue aux paramètres de formes de mots. La seule différence est que <symbol-prm n="x"> génère <s n="y"> si la valeur de x est y, alors que <txt-prm n="x"> génère juste y.

Résumé de Francis Tyers

[avec des noms d'attributs légèrement changés pour se conformer à ce qui précède]

Voici un résumé bref détaillant les différentes manières dont le nouveau format pourrait être utilisé. Elles sont toutes dans différentes langues, mais il se pourrait que chaque paire de langues puisse utiliser toutes ces caractéristiques.

<pardef n="ab/i[T]ar__vblex" prm-list="cons cons2">
  <e alt="oc@aran">
    <p>
      <l>í</l>
      <r>i</r>
    </p>
    <i><txt-prm n="cons"/><txt-prm n="cons2"/></i>
    <par n="cànt/iga__vblex"/>
  </e>
  <e>
    <i>i<txt-prm n="cons"/></i>
    <par n="cant/as__vblex"/>
  </e>
</pardef>

<pardef n="house__n" prm-list="count">
  <e>
    <p>
      <l/>
      <r><s n="n"/><symbol-prm n="count"/><s n="sg"/></r>
    </p>
  </e>
  <e>
    <p>
      <l>s</l>
      <r><s n="n"/><symbol-prm n="count"/><s n="pl"/></r>
    </p>
  </e>
</pardef>

Appels :

  <e lm="house"><i>house</i><par n="house__n"/></e>
  <e lm="time"><i>time</i><par n="house__n" prms="count='unc'"/></e>
  <e lm="brilhar"><i>br</i><par n="ab/i[T]ar__vblex" prms="cons='lh' cons2='tx'"/></e>
  <e lm="aerodrom"><i>aerodrom</i><par n="aerodrom__n"/></e>
  <e lm="avion"><i>avion<b/>luka</i><par n="aerodrom__n"/></e>
  <e-group alt="sh_HR">
    <e lm="zrakoplov"><i>zrakoplov</i><par n="aerodrom__n"/></e>
    <e lm="zračna luka"><i>zračna<b/>luka</i><par n="luka__n"/></e>
  </e-group>
  <e lm="fajl" alt="sh_BS"><i>fajl</i><par n="aerodrom__n"/></e>
  <e lm="datoteka"><i>datoteka</i><par n="luka__n"/></e>