D’un tableau annoté vers un graphe de propriétés

Définition 1. D’après [Rodriguez et Neubauer, 2010] un graphe de propriétés est une combinaison de graphes orientés, étiquetés, attribués et de multi-graphes. Les arcs sont orientés, les noeuds et les arcs sont étiquetés, des paires de propriétés sous forme clé/valeur sont associées aux noeuds et aux arcs et il peut y avoir plusieurs arcs entre deux noeuds. La Figure II.14 illustre un exemple de graphe de propriétés.

Figure II.14 — Un exemple de graphe de propriétés

Dans un premier temps, nous avons fait le choix de transformer les tableaux annotés vers un graphe selon le modèle de graphe de propriétés pour les raisons suivantes : (1) le graphe de propriétés est l’ancêtre de plusieurs modèles de graphe tels que le graphe orienté, graphe sémantique, graphe RDF, etc ; ceci garanti la généricité de notre approche et un passage facile vers d’autres modèles pour permettre la réutilisation de nos tableaux dans d’autres contextes, et (2) ce modèle nous permet de capitaliser toutes les annotations du tableau et la formalisation que nous avons définies pour les tableaux.

Les règles suivantes permettent la transformation d’un tableau annoté T vers un graphe de propriété GP = (V, E):

– Dans T, nous avons des composants simples comme les StructData et les NumData et des composants composites tels que les StubHead et les UnitNumBloc. Chaque com- posant simple de C de délimitation DL, FL, DC, FC et ayant les annotations AI, AT et AS se transforme en un noeud identifié de façon unique dans l’ensemble V et ayant les propriétés{type, valeur, DL, FL, DC, FC, AI, AT, AS}. Le type est le nom du type du composant par exemple StructData, la valeur est le contenu de la cellule du compo- sant. Pour les autres propriétés, s’il s’agit d’une chaîne de caractères ou d’un entier il sera repris tel qu’il est, sinon si c’est l’identifiant d’un composant il faut prendre l’iden- tifiant du noeud correspondant à ce composant. Chaque composant composite de C se transforme en un noeud identifié de façon unique dans l’ensemble V et ayant les

pliquées pour les propriétés des composants simples s’appliquent sur les propriétés des composants composites.

– Dans T, nous avons un ensemble de relations R entre les composants du tableau. Ces relations se transforment en arcs entre les noeuds correspondant à ces composants. Nous avons essentiellement deux types de relations : (1) les relations de spécialisa- tion entre les StructData et (2) les relations d’association "indexer" entre les com- posants composites. Pour les relations de spécialisation, nous créons un arc orienté non-étiqueté entre les noeuds de type StructData. Pour les relations d’association "in- dexer", nous créons des arcs orientés dont la source est le composant qui indexe et la cible est le composant indexé. Par déduction, nous construisons des arcs d’association "indexer" entre les StructData et les NumData.

La Figure II.15 illustre un extrait du graphe de propriétés du tableau de la Figure II.10.

Figure II.15 — Un extrait d’un graphe de propriétés d’un tableau

3.2.5.2 D’un graphe de propriétés vers un graphe RDF

Dans un graphe RDF les données sont organisées en triplets de la forme(s, p, o)qui ex- priment qu’un sujet s est relié à l’objet o par un arc de propriété p. Les sujets, les propriétés et les objets identifient d’une façon unique, à travers des URI, des entités, des relations ou des concepts. Les objets sont les seuls à pouvoir prendre des valeurs constantes dites littéraux. Pour produire des données RDF, les étapes clés consistent à l’identification des données par des URI et à l’utilisation, dans la mesure du possible, de vocabulaires standardisés par le W3C.

Nous avons évoqué dans la section précédente qu’un graphe de propriétés peut se trans- former en un graphe RDF. [Rodriguez et Neubauer, 2010] proposent d’enlever les proprié-

tés des noeuds du graphe de propriétés pour passer à un modèle de graphe étiqueté puis de transformer les labels en URI pour obtenir un graphe RDF. Cette proposition est intéressante mais elle a l’inconvénient de faire disparaître les propriétés. Pour palier à cet inconvénient, nous proposons un autre processus de transformation qui comporte les étapes suivantes :

1. Éclater les propriétés d’un noeud sous format de triplet RDF (s,p,o) où s est le noeud, p est le nom de la propriété et o est la valeur de la propriété. En appliquant cette étape sur le graphe de la Figure II.15, nous obtenons le graphe illustré par la Figure II.16.

Figure II.16 — Un extrait de graphe de propriétés éclaté

2. Transformer chaque noeud de V qui a un identifiant unique en un URI.

3. Utiliser des vocabulaires standardisés, dans la mesure du possible, pour décrire les don- nées. Nous avons choisi d’utiliser les vocabulaires RDFS12et SKOS13. Les transforma- tions suivantes sont mises en place :

– La propriété "type" est remplacée par "rdf :type" ;

– La propriété "valeur" est remplacée par "rdfs :label" pour les données numériques ; – Les données structurelles de type "StructData" deviennent de type "skos :concept" ; – La propriété "valeur" est remplacée par "skos :label" pour les données structurelles ; – La propriété "is-a" pour la spécialisation entre les données structurelles est remplacée

par la propriété "skos :broader".

La Figure II.17 illustre un extrait du graphe RDF résultant après l’utilisation des parties de vocabulaires standards.

Figure II.17 — Un extrait de graphe RDF