Le modèle MSXD

Le modèle MSXD (MultiStructured XML Documents) (Bruno et Murisasco 2006) a été défini dans l‘objectif de représenter les documents multistructurés en prenant en compte les annotations ajoutées par un utilisateur. A l‘opposé des deux modèles présentés précédemment qui préconisent le partage de contenu, le modèle MSXD se base sur le principe de la duplication du contenu. Les structures sont donc représentées les unes indépendamment des autres. Les relations entre ces structures sont gérées dans ce qu‘ils appellent un « schéma de document multistructuré ». Les représentations structurelles s‘appuient sur la notion de Hedge (Murata 1999) (fondation de RelaxNG (Clark et Murata 2001)).

En se focalisant sur les documents textuels, (Bruno et Murisasco 2006) définissent un document multistructuré comme un triplet (V, G, S) où V représente la valeur textuelle, G représente un ensemble de segmentations de V et S représente l‘ensemble des structures associées aux segmentations de G. Chaque structure et ses annotations sont définies au travers d‘un ensemble de segmentations et décrites avec le langage XML. Le schéma de document multistructuré définit les relations entre ces structures au travers de contraintes faibles exprimées par des relations d‘Allen (Allen 1983).

La Figure II.17 illustre un exemple de schéma de document multistructuré d‘un poème présenté dans (Bruno et Murisasco 2006). D‘une part, ce schéma référence trois structurations possibles de poèmes et un ensemble d‘annotations de son contenu ajouté par un utilisateur. Le schéma admet aussi un ensemble de contraintes illustrant les relations entre des fragments de structures différentes. Par exemple, la première contrainte traduit le

in beginin endin [s] in [s] beginin [s] endin after, after(k) before, before (k) with (k) withbegin (k) withend(k) same +, -, is parent (k) [s] child collapse, subtract, … matches Expression d‘appariements Opers on matches Content Basis Set manipulation By included elements Positional By including elements Positional Free View Constructor Composition operations Structure Basis

fait que les deux éléments « Sonnet » de la structure « poem_physical » et « Poem » de la structure « poem_linguistic » partagent le même contenu.

<MsXmlSchema xmlns: a =’http: // sis.univ -tln.fr/annot ’> <!-- Identification of the structures and annotations --> <Structures>

<Structure type="http://sis.univ -tln.fr/msxd/structure/poem/ physical" alias="poem_physical" grammar ="poem_physical.rnc"/> <Structure type="http: //sis.univ -tln.fr/msxd/structure/poem/ linguistic" alias="poem_linguistic" grammar

="poem_linguistic.rnc"/>

<Structure type="http: //sis.univ -tln.fr/msxd/structure/poem/ rythmic" alias="poem_rythm" grammar ="poem_rythm.rnc"/>

<Structures> <Annotations>

<Annotation type="http: // sis.univ -tln.fr/ annot" alias="rythm_annot" grammar ="rythm_annotation.rnc"/> <Annotations>

<Constrains>

<!-- RELATIVE CONSTRAINTS BETWEEN STRUCTURES --> <!-- Sonnet and poem are equals -->

<Equal >

<Fragments type="poem_physical" select ="/Sonnet "/> <Fragments type="poem_linguistic" select ="/Poem"/> </Equal >

<Equal >

<Fragments type="poem_linguistic" select ="/Poem"/> <Fragments type="poem_rythm" select ="/Poem"/> </Equal >

<!-- Attributes or elements title and author are equals --> <Equal >

<Fragments type="poem_physical" select ="/Sonnet /Head/Title"/>

<Fragments type="poem_rythm" select ="/Poem/@title "/> </Equal >

…

<!-- A reject begins a verse --> <Begins >

<Fragments type="poem_rythm" select ="Rej"/> <Fragments type="poem_physical" select ="Verse"/> </Begins >

<!-- A enjambment must overlap two verses --> <Overlaps >

<Fragments type="poem_rythm" select ="Enj"/> <Fragments type="poem_physical" select ="Verse"/> </ Overlaps >

<!-- First Sentence begins just after (meets) Head --> <Meets >

<Fragments type="poem_physical" select ="Head"/> <Fragments type="poem_linguistic" select ="Sentence [1]"/>

</Meets > …

</Constrains> </MsXmlSchema>

Figure II.17. Extrait d’un schéma de document multistructuré (Bruno et Murisasco 2006).

Le modèle MSXD permet de représenter les différentes structures associées à un document les unes indépendamment des autres. Aucune d‘entre elles n‘est privilégiée. La

duplication du contenu est l‘inconvénient majeur de cette solution. Si le problème de chevauchement d‘éléments ne se présente plus du fait que le contenu est dupliqué, le problème de cohérence est le problème de base à résoudre. Cette cohérence est assurée par des relations et des contraintes définies dans le schéma de document multistructuré. Or, la création d‘un tel schéma requiert des traitements volumineux comme l‘analyse simultanée de toutes les structures et l‘extraction des contraintes à expliciter.

Afin d‘interroger les documents multistructurés représentés selon le modèle MSXD, les auteurs proposent une extension de XQuery dans la mesure où leur modèle est proche de celui utilisé par XQuery et XPath (Fernandez et al. 2002). Ces derniers utilisent le modèle XDM (XML Data Model). Ce modèle est basé sur la notion de séquences et d‘item : une séquence est ensemble d‘item et un item peut être une valeur atomique ou un nœud. L‘extension du modèle XDM consiste à définir un item comme une valeur atomique ou un fragment au lieu d‘un nœud. De cette façon, la structure de XQuery n‘est pas modifiée. Les extensions ne concernent donc que la sémantique du filtre. Les relations d‘Allen sont également utilisées pour gérer le chevauchement d‘éléments. Pour la prise en compte de ces relations, des fonctions et des opérateurs ont été ajoutés à XQuery. A titre d‘exemple les fonctions « parents » et « children » sont étendues pour retourner respectivement tous les parents et tous les enfants d‘un fragment à partir de toutes structures contenant ce fragment.