[Dizionario] Re: [Dizionaridizionario] necesse XML

[Andrea Sivieri]

> Sono d'accordo che disaggregare sia molto piu`
> difficile di aggregare, soprattutto se nel
> disaggregare non si vuole perdere l'aggregazione
> originale :)
> 
> Ciao, provo a darti le mie impressioni sui punti 
> che mi sono saltati all'occhio.

Grazie  :-)

> >         <word>frutto</word>
> > 
> >         <!--    Lista dei sinonimi -->
> >                 
> >         <syn>prodotto della terra, prodotto</syn>
> 
> questo in xml si scrive 
> <syn>prodotto della terra</syn>
> <syn>prodotto</syn>
> altrimenti introduci una notazione nuova (la virgola) e non e` piu`
> xml, ma un ibrido.

Obiezione accolta.

Stiamo parlando di un formato molto aderente agli
standard, mica di un formato con scorciatoie...

inoltre questo permetterebbe piu` facilmente di
fare delle SELECT che estraggono il meaning
contraddistinto da una particolare word e da
un certo sinonimo.
 
> >         <def src="Melchi">Tutto ci %/1iso8859-15ò che la terra 
produce</def>
> >         <def src="Test1">Prova</def>        
> >         
> >         <def src="Test2">Prova</def>                
> > 
> >         <!--    Ogni definizione viene da una qualche 
> >                 fonte a cui e` associato un identificatore (esempio: 
Melchi).
> >                 Possono esserci anche decine di definizioni-->
> 
> Questa andra` estesa... def/src non credo basti.

Sono partito con l'essenziale, di sicuro ho perso qualcosa,
visto anche la casistica minima che ho considerato.

> >         <!--    Considerazioni simili valgono per la lista di esempi -->
> >         
> >         <example src="Bibbia">Per sei anni seminerai la tua terra e 
> > raccoglierai i suoi frutti. [Esodo 23,10]</example>
> 
> Se le citazioni dalla bibbia fossero molte potrebbe convenire mettere il
> firerimento in 3 attributi separati.

Non oserei per ora andare oltre a questo:

<example src="Bibbia" pos="Esodo 23,10">Per sei anni seminerai la tua terra e 
raccoglierai i suoi frutti.</example>

perche` i tipi di fonti sono tanti...

> >     </meaning>
> > 
> >...
> >     <meaning>
> >         <word>pèsca</word>         <!-- Notare l'accento -->
> 
> Se mettiamo l'accento pero` credo che mettiamo in difficolta` anche il
> correttore ortografico (correntemente scriviamo pesca, a meno che non ci
> siano dei dubbi di interpretazione). Come lo risolviamo questo problema?

Bella domanda...

La gestione degli accenti interni, oltre alla sillabazione e alle
altre cose che riguardano la forma andrebbe spostata nella
parte della gerarchia XML dedicata appunto alla forma.

In caso di omografia si potrebbe usare invece un sinonimo 
per disambigurare:

<word syn="frutto">pesca</word>

> >         <syn>frutto</syn>    
> >         <def src="Melchi">Frutto del pesco</def>
> >         
> >         <!--    Segue la traduzione verso un meaning inglese 
(identificato da
> >                 "word|primo_sinonimo"). -->
> >                         
> >         <trans lang="en">peach|fruit</trans>
> 
> Anche in questo caso introdurre il "pipe" per dividere le parole non
> e` XML e alla lunga genera problemi ed e` difficile da processare con un
> XSL.

Soluzione come per le omografe:
"peach" vuol dire tante cose diverse che si scrivono nello stesso modo.

Per disambiguare:
<trans lang="en" syn="fruit">peach</trans>

> >         <!--    Sarebbe secondo me di scarsa utilita` tradurre 
> >                 un po' come viene parole italiane in parole varie di altre
> >                 lingue. La cosa piu` efficiente mi sembra tradurre tutti
> >                 i meaning italiani o di altre lingue in meaning inglesi.
> >                 Se si fa questo per M lingue, si hanno automaticamente M*M
> >                 dizionari multilingue pronti, avendo fatto un lavoro 
> >                 proporzionale a M, invece che M*M.
> >                 Senza contare il fatto che si avrebbe la corrispondenza
> >                 con i sinonomi giusti nelle altre lingue: e` questo quello
> >                 che un traduttore vorrebbe. :-) -->                       
> 
> Rimango dell'idea che la mia proposta di <accezione lang=""> sia la più
> flessibile. una semplice corrispondenza (anche molti a molti) lemma
> italiano <-> lemma inglese non contiene abbastanza informazioni per
> formare un dizionario bilingue.
>
> Mentre la forma che proponevo puo` essere usata per inglobare questa
> (credo sia piu` generale).

Hai ragione che qualcosa non viene coperto:
devo pensarci un attimo...

... voglio anche capire un po' meglio il comportamento
in un contesto multilingue delle accezioni come le
intendi tu. Riporto il tuo esempio e domani lo riguardo:

<dict>
   <voce>
      <lemma>casa</lemma>
      <sillabazione>ca-sa</sillabazione>
      <pronuncia>...</pronuncia>
      <classificazione tipo="sostantivo" genere="" numero .../>
      <significato>
        <accezione tipo="comune">
          <significato>edificio suddiviso in vani e 
          adibito ad abitazione</significato>
          <esempio>vivere in una bella casa</esempio>
          <sinonimo>abitazione</sinonimo>
        </accezione>
        <accezione tipo="fig">
           <esempio>portare a casa la pelle</esempio>
           <significato>uscire felicemente da 
             una situazione pericolosa  </significato>
          <sinonimo>salvarsi</sinonimo>
        </accezione>
        <accezione senso="abitazione" xml:lang="en">
          <significato>house</significato>
	</accezione>
        <accezione senso="residenza abituale" xml:lang="en">
          <significato>home</significato>
	</accezione>
      </significato>
   </voce>  
</dict>

>>... 
>> <!--    Sia le forme regolari che quelle irregolari dovranno essere
>>         collegate alle forme base, che poi fanno da ponte verso i 
significati
>>         (meanings). E` indicata la classe in modo da permettere
>>         la declinazione o coniugazione a partire dalla forma base
>>         (a riguardo ci sono cose da perfezionare) -->
>> 
>> <base_forms>
>>     <base_form>
>>         <word>pèsca</word>
>>         <comment>il frutto</comment>
>>         <class>noun:f-ca-che</class>
>>     </base_form>
>
>Perche' in una sezione a parte e non nel file precedente?

Intendi come mai non nella sezione precendente, quella dei meaning...

Per due ragioni:
1. per una base_form ci possono essere tanti meaning
2. se ci sono delle cose da dire sulla forma, tipo accenti, sillabazione, ecc.
   le si dicono dentro a <base_form></base_form>, cosi` dentro ai meaning
   basta metto l'identificatore della base_form, non altro. Il proposito e`
   quello di avere disaccoppiamento tra significati e forma.

Nella tua impostazione il lemma aggrega tutto il resto,
per cui metti le informazioni sulla forma del lemma direttamente
dov'e` il lemma, senza ridondanze. Ma non mi convince quello
che succede dei significati, devo ripensarci...

>Anche in questo caso poi e` presente una notazione estranea
>all'XML
>io avrei scritto 
>
><noun>-ca</noun>
><noun>-che</noun>
>
>o una qualsiasi variante in cui l'informazione non vada parsata da
>nessuno se non dal parser xml.

"noun:f-ca-che" e` solo un nome per una classe di forme derivate
che il computer deve prendere come un tutt'uno, senza interpretarlo.

Verrebbe usato per tutte le base_form per le quali vale ad esempio
la seguente regola:

    <form prec="1"> 
        <class>noun:f-ca-che</class>
        <rule><base>[1]ca</base><self>[1]che</self></rule>
        <attrib>gender=f,num=p</attrib>
    </form>

Quindi il contenuto di <class> non e` un ibrido, ma solo un'etichetta
che deve essere facile da ricordare e veloce da scrivere, qualsiasi
altro modo per creare etichette che non collidano e ben accetto.
Queste etichette sono identificatori che fanno da ponte tra le
base_form e le forme derivate a loro collegate.

Vediamo poi degli "ibridi" nella riga:
<rule><base>[1]ca</base><self>[1]che</self></rule>

Il fatto e` che il parser XML non farebbe niente di utile 
a spezzare il contenuto di <base> o <self> in parti piu`
piccole, anzi poi bisognerebbe _sempre_ rimetterle insieme.

Invece:
<attrib>gender=f,num=p</attrib>

potrebbe diventare:
<attrib gender="f" num="p" />

per evitare l'ibrido. Lo stesso vale per gli altri attrib.

Vediamo cosa succede se incontro la parola "pesche" in un testo:

1. la regola <rule><base>[1]ca</base><self>[1]che</self></rule>
aggancia, perche` self="pesche" => [1]="pes" => base="pesca",
inoltre "pesca" e` una forma base esistente (se non lo fosse la
regola sarebbe da considerare fallita).

Ad esempio: "aribarche" verrebbe portato da questa regola
ad "aribarca", ma questa non e` una forma base conosciuta.
Non solo la forma base deve esistere, ma deve naturalmente
anche appartenere alla stessa classe che e` stata ipotizzata
dalla regola, altrimenti fallimento.

Torniamo invece a "pesche". Visto che la parola e` stata
agganciata dalla regola e che esiste una forma base di
uguale classe, abbiamo risolto il problema di risalire alla
forma base. Inoltre leggendo gli attrib associati alla regola
che e` stata attivata sapremo anche tutto il resto sulla
classificazione di questa forma derivata.

>Scusa se ho tagliato il resto, non ho avuto il tempo di leggerlo. Mi
>riprometto di farlo domani

Grazie invece...
Tu poi usi XSL dove io uso script Python, per cui 
vediamo aspetti diversi e questo e` un bonus.   :-)

Anche il sistema di regole che propongo e` solo un primo tentativo...

Ciao,
          Andrea