Skip to topic | Skip to bottom
Home

Tesi
Tesi.AppuntiGestioneTrucchir1.4 - 28 Jan 2011 - 13:07 - FrancescoPoggitopic end

Start of topic | Skip to actions
Torna al diario di bordo

Appunti Gestione trucchi

Definizioni

Si fa riferimento seguenti concetti, introdotti in questo articolo:

  • dominanza: la chiusura transitiva della relazione parent/child.

  • contenimento: la relazione superset/subset sui nodi foglia raggiungibili da un nodo seguendo la relazione parent/child.

  1. Il contenimento risolve sempre verso le foglie.
  2. In caso di overlap su un nodo child da parte di due nodi p1 e p2 ...

Tipi di elemento:

  • first level element: elementi che hanno come content model contenuto semplice (solo sequenze di range o attributi) e elementi vuoti.
  • mixed content element: elementi che contengono sequenze di range e first level element.
  • structure element: elementi che contengono solamente altri elementi.
vedi qui (par.4.2 pag 7) e qui (par. 4.3 pag 23).

Principi generali

Principi genarali per l'applicazione di conversione:

  • Il documento EARMARK in input e' un DAG (non sono presenti cicli)
  • Anche in presenza di overlap di piu' di due nodi sullo stesso nodo, si procede sempre risolvendo l'overlap fra coppie di nodi, ricorsivamente. E' ipotizzabile:
    • un ordine fra nodi con/senza indicazione di trucchi
    • un ordine fra trucchi (prima tutti i nodi in milestone, poi quelli in fragmentation, ecc...)
    • un ordine fra nodi che utilizzano lo stesso trucco
  • Per realizzare il processo di linearizzazione XML di un documento EARMARK e' necessario introdurre relazioni di dominanza non presenti nel documento originale (nei linguaggi di markup basati su strutture ad albero e' frequente che contenimento => dominanza). In particolare e' accettabile (e necessario) in caso di overlap estendere l'insieme dei nodi dominati da un nodo, ma non e' accettabile estendere l'insieme dei nodi foglia contenuti in un nodo (vedi fig.3 di questo articolo, con nodi con identifier "name", "normal" e "jazzy" interpretati come elementi invece che attributi). Nel secondo caso l'applicazione puo' procedere in uno dei modi seguenti modi (vedi principi generali)
    • generare un errore.
    • generare un warning con un messaggio generale ed eliminare il nodo (o la sottogerarchia) in questione.
    • generare un warning particolare con tutte le informazioni specifiche ed eliminare il nodo (o la sottogerarchia) in questione.
    • esprimere il nodo (o la sottogerarchia) con RDFa
  • Considero overlap su nodo N da parte di due elementi A e B. Per risolvere overlap introduco dominanza fra i due nodi (vedi procedure descritte in seguito), ad esempio A va a dominare B. Se B contiene foglie non contenute in A (o nella gerarchia cui appartiene?), definisco:
    • foglieBnonA = {foglie contenute in B ma non in A}
    • sottogerarchiaB = {nodi dominati da B che contengono solo foglie dell'insieme foglieBnonA}

Comportamento in caso di strutture non gestite dall'applicazione (in ordine, da una gestione raw a gestione piu' raffinata):

  • generare un errore.
  • generare un warning con un messaggio generale ed eliminare i nodi che causano il problema.
  • generare un warning particolare con tutte le informazioni specifiche ed i nodi che causano il problema.
  • esprimere i nodi che causano il problema con RDFa

Fragmentation

Ordine risoluzione overlap (confronto fra piu' nodi) :

Si analizzano i nodi del grafo partendo dalle foglie. Ogni volta che si individua una situazione di overlap su un nodo si determina l'insieme di tutti i nodi in overlap su quel nodo e si tenta di risolvere l'overlap:

  • Per prima cosa si risolve l'overlap fra le coppie di nodi senza trucco specificato, usando il principio dell'ordine di contenimento. In particolare:
    • se nodo A contiene esattamente le stesse foglie di B, allora A domina B o B domina A, indifferentemente
    • se nodo A contiene tutte le foglie di B piu' altre foglie, A domina B
    • altrimenti c'e' un errore: e' possibile fornire un warning e procedere senza risolvere questa situazione
  • Ripetere il punto precedente per tutti i nodi senza un trucco specificato.

  • Si procede cercando di risolvere le situazioni di overlap per tutti i nodi che hanno un trucco specificato. Si procede considerando coppie di nodi (nodo con trucco, nodo contenitore) ricorsivamente, per tutti i nodi senza trucco:
    • per prima cosa bisogna bisogna scegliere il nodo contenitore che andra' a dominare il nodo con il trucco specificato:
      • Se c'e' solo un nodo senza trucchi spedificati si sceglie questo nodo
      • Se c'e' piu' di un nodo senza trucchi specificati si sceglie il nodo che domina l'insieme di foglie piu' esteso
      • Se c'e' un nodo gia' espresso con trucchi (nel nostro caso puo' essere solo un nodo frammentato) si sceglie questo nodo
      • Altrimenti si sceglie il nodo (con un trucco indicato) che domina l'insieme di foglie piu' esteso
    • bisogna scegliere il secondo nodo da esprimere con trucchi. Fra quelli con un trucco specificato si sceglie quello che domina l'insieme di nodi foglia piu' esteso (considerando solo le foglie contenute nel nodo contenitore). NB: specificare meglio .
    • individuata la coppia di nodi, si risolve l'overlap utilizzando il trucco specificato. E' possibile specificare piu' modi diversi per lo stesso trucco, e aggiungere nuovi modi al framework in un secondo tempo. Ad esempio e' possibile rendere disponibile in un primo tempo un trucco TEI-Milestone, e aggiungere al framework solo in un secondo tempo, in maniera modulare, la gestione di flat-Milestone. Ognuno di questi modi e' da considerarsi come un trucco differente.
  • Ripetere la procedura del punto precedente per tutti i nodi con trucco specificato.

Ordine di contenimento:

  1. se leaf(A) = leaf(B), e' indifferente
  2. se leaf(A) inclusione.png leaf(B), B va a dominare A
  3. se nessuno dei due insiemi e' contenuto completamente nell'altro bisogna adottare un altro principio (ad esempio nodo(#foglieMaggiore) domina nodo(#foglieMinore) ).

NB: l'ordine dei punti precedenti e' importante.

La seguente immagine rappresenta un documento EARMARK di esempio:

20101218_fragmentation_color.jpeg

Esempio:

Si indica di usare fragmentation per gli elementi "text_red" e "leaf_red" di destra.

<doc>
   <par>
      <text_red id="text_red:1.1" next="text_red:1.2">
         <leaf_red>
            Testo,
         </leaf_red>
         <text id="leaf_red:1.1" next="leaf_red:1.2">
            testo
         </text>
      </text_red>
   </par>
   <par>
      <text_green>
         <leaf_green>
            <text_red id="text_red:1.2">
               <leaf_red id="leaf_red:1.2">
                  e
               </leaf_red>
            </text_red>
            ancora
         </leaf_green>
         <leaf_green>
            testo
         </leaf_green>         
      </text_green>
   </par>
</doc>

Milestone

Non esprime elementi discontinui. Gli elementi discontinui da esprimere con milestone non vengono gestite (genero un errore o un warning come descritto qui

Da sola non e' sufficiente per esprimere self-overlap (serve meccanismo di co-indexing)

Stand-off markup

Che meccanismo di puntamento utizzare in XML? Solo XPointer?

Domande

Come posso effettuare una query SPARQL che restituisca la chiusura transitiva di una relazione?

  • Vedi 1, 2, 3 .

Ci sono strumenti per provare SPARQL 1.1?
to top

I Attachment sort Action Size Date Who Comment
20101218_fragmentation_color.jpeg manage 34.8 K 18 Dec 2010 - 19:32 FrancescoPoggi esempio per fragmentation
inclusione.png manage 0.3 K 20 Dec 2010 - 11:52 FrancescoPoggi  
inclusioneUguale.png manage 0.3 K 20 Dec 2010 - 11:53 FrancescoPoggi  

You are here: Tesi > EarmarkFretta > EarmarkFrettaDiarioDiBordo > AppuntiGestioneTrucchi

to top

Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback