Sébastien Ferré
email: ferre@irisa.fr

Exploration d'expressions mathématiques en RDF Extension du langage de requêtes LISQL pour la représentation et l'exploration d'expressions mathématiques en RDF

Keywords: Web sémantique, RDF, expressions mathématiques, exploration

Les expressions mathématiques comptent pour une part importante dans les connaissances humaines. Nous en proposons une représentation en RDF afin de pouvoir les intégrer aux autres connaissances dans le Web sémantique. Nous étendons ensuite le langage de description et d'interrogation LISQL afin de concilier des représentations non-ambiguës, des requêtes expressives et des notations naturelles et concises. Par exemple, la requête int(... ?X ˆ2..., ?X) permet de trouver les intégrales en x dont le corps contient la sous-expression x 2 . Tout cela permet d'utiliser Sewelis, un système d'information logique pour le Web sémantique, pour la représentation et l'exploration guidée d'expressions mathématiques. Ce guidage dispense les utilisateurs de maîtriser la syntaxe de LISQL et le vocabulaire tout en leur garantissant des expressions bien formées et des résultats à leurs requêtes.

Introduction

Les expressions mathématiques comptent pour une part importante dans les connaissances humaines et jouent un rôle central dans les documents scientifiques. Comme pour les autres formes d'information non-textuelle (ex., images, XML), il est donc important de pouvoir rechercher ces expressions par leur contenu [START_REF] Youssef | Roles of math search in mathematics[END_REF]. Par exemple, on peut souhaiter retrouver les expressions contenant une intégrale en une certaine variable x contenant le terme x 2 , telles que x 2 + 1 dx ou y 2 -y dy. Cet exemple fait apparaître deux difficultés de la recherche d'expressions mathématiques. La première est la nécessité de prendre en compte la structure IC 2012 de l'expression, par exemple le fait que la sous-expression x 2 soit dans la portée d'une intégrale. La deuxième est la nécessité de s'abstraire du nom des variables liées, par exemple la variable x ci-dessus qui est liée par l'intégrale dx et qui peut être renommée en y sans que cela ne change le sens de l'expression (α-équivalence). Les approches qui consistent à appliquer les méthodes de recherche dans les textes en linéarisant ces expressions [START_REF] Miner | An approach to mathematical search through query formulation and data normalization[END_REF] ne permettent pas de traiter ces difficultés [START_REF] Youssef | Roles of math search in mathematics[END_REF]. Cela a pour conséquence de retourner des faux positifs tels que 2x dx = x 2 + c, et d'avoir des faux négatifs tels que y 2 -y dy. Les approches à base de langage de requête [START_REF] Altamimi | A math query language with an expanded set of wildcards[END_REF][START_REF] Kohlhase | A search engine for mathematical formulae[END_REF][START_REF] Guidi | A query language for a metadata framework about mathematical resources[END_REF] permettent au contraire de bien traiter ces aspects en raisonnant directement sur la structure des expressions et en utilisant des "jokers" à la place de variables ou de sousexpressions. Dans le langage de Altamimi & Youssef (2008), la requête \int ...$1^2... d$1 répond à la recherche ci-dessus.

Les Systèmes d'information logiques (LIS, [START_REF] Ferré | An introduction to logical information systems[END_REF]) apportent un nouveau paradigme de recherche d'information combinant étroitement interrogation et navigation. Ils offrent ainsi aux utilisateurs l'expressivité de l'interrogation avec la facilité d'utilisation de la navigation. Initialement de puissance similaire à la recherche à facettes (Sacco & Tzitzikas, 2009), les LIS ont été récemment étendus aux données du Web sémantique avec comme résultat fort que la navigation offre une expressivité proche de celle de SPARQL et la garantie qu'aucun lien de navigation ne mène à un résultat vide [START_REF] Ferré | Semantic search : Reconciling expressive querying and exploratory search[END_REF]. Le prototype Sewelis 1 guide les utilisateurs dans la construction incrémentale de requêtes arbitrairement complexes par ajouts successifs d'éléments pertinents. Cette construction incrémentale des requêtes et le souci de s'abstraire de notions de bas niveau (ex., algèbre relationnelle, logique) nécessite un langage différent de SPARQL : LISQL (LIS Query Language) [START_REF] Ferré | Semantic search : Reconciling expressive querying and exploratory search[END_REF]. Par exemple, dans des données de type généalogiques, il est possible d'atteindre par navigation, c'est-à-dire sans rien saisir, la requête LISQL qui retourne les «personnes nées en 1601 ou 1649 quelquepart en Angleterre et dont le père est né à un endroit différent».

La contribution de ce papier est de montrer comment les expressions mathématiques peuvent être représentées en RDF (section 2) de telle sorte qu'il soit possible de faire des recherches prenant en compte leur structure et le renommage de variables liées (section 3). La syntaxe du langage LISQL doit cependant être enrichie pour que la présentation des expres-1 http ://www.irisa.fr/LIS/softwares/sewelis sions et des requêtes se rapprochent de la notation mathématique (section 4). Nous détaillons ensuite un scénario complet de construction guidée de requêtes (section 5). À la section 6, nous complétons LISQL pour la représentation et l'exploration des structures de taille variable (ex., ensembles, vecteurs). Après une comparaison avec les travaux existants (section 7), nous terminons par une conclusion et des perspectives (section 8). Pour définir la représentation des expressions, nous nous inspirons des termes Prolog [START_REF] Sterling | The Art of Prolog[END_REF] en raison de leur simplicité, de leur généricité et de leur adéquation avec RDF. En Prolog, un terme est soit un atome, soit un nombre, soit une variable, soit un terme composé. Les atomes sont des symboles logiques et correspondent bien aux URIs. Les nombres correspondent naturellement aux littéraux de RDF, lesquels peuvent également être des chaînes de caractères, des dates, etc. Comme en Prolog, les variables interviendront dans les requêtes mais pas dans les faits. Un terme composé est constitué d'un foncteur et d'une série d'arguments. Le foncteur est un atome et les arguments sont des termes quelconques. En supposant un espace de nommage term:, on peut définir les propriétés term:functor, term:arg1, term:arg2, ... pour lier la ressource représentant le terme composé à chacune de ses composantes. Afin de ne pas mélanger les notions d'identité et de contenu, on emploiera uniquement des blank nodes pour les termes composés et non des URIs. Il reste possible de lier une identité (URI) à un contenu (un terme) via une propriété ad-hoc, par exemple la propriété rdf:value.

La figure 1 donne la représentation graphique de la représentation RDF de l'expression x 2 + 1 dx. Cette expression implique les opérateurs mathématiques math:integral (intégrale), math:plus (addition) et math:power (puissance), qui sont tous utilisés comme foncteurs d'arité 2. Dans le cas de math:integral, le second argument joue le rôle de va- Comparé à Turtle, LISQL utilise l'indentation à la place des blocs ([. . .]) et sépare le prédicat et l'objet par un deux-point. Chaque niveau d'indentation correspond à une ressource. Le premier niveau correspond à l'expression entière, le deuxième correspond à la sous-expression x 2 + 1, le troisième à la sous-expression x 2 et le quatrième à la variable x. Une construction de la forme (p : o) au niveau d'une ressource s établit un triplet (s, p, o) où à la place de o on peut avoir un terme atomique (sur la ligne) ou un terme composé (sous-bloc en indentation).

Représentation LISQL des requêtes

Nous nous intéressons maintenant à la représentation de requêtes en LISQL pour la recherche d'expressions mathématiques. La table 1 donne les constructions syntaxiques du langage LISQL et leur traduction dans des graph patterns SPARQL. Une requête LISQL dénote un ensemble de ressources, ses réponses, et sa traduction GP (x, q) prend donc en paramètre une variable x en plus de q. Le résultat d'une requête LISQL est l'ensemble des valeurs que peut prendre x pour vérifier GP (x, q), soit le résultat de la requête SPARQL SELECT ?x WHERE GP (x, q). Dans la syntaxe concrète de LISQL, le connecteur and est remplacé par des retours à la ligne et les parenthésages nécessaires par des indentations. query q graph pattern GP (x, q) r FILTER ( ?x = r) a c ?x a c p : q 1 ?x p ?y. GP (y, q 1 ) p of q 1 ?y p ?x. GP (y, q 1 ) ?

OPTIONAL { } q 1 and q 2 GP (x, q 1 ) GP (x, q 2 ) q 1 or q 2 { GP (x, q 1 ) } UNION { GP (x, q 2 ) } not q 1 FILTER NOT EXISTS { GP (x, q 1 ) } ?v FILTER ( ?x = ?v) Les variables LISQL jouent le même rôle que les variables en Prolog. Le point d'interrogation ? est simplement une variable anonyme. Elles servent de joker dans une requête en acceptant n'importe quel terme à leur emplacement. Elles servent également à poser une contrainte d'égalité entre deux atomes d'une expression. Cela permet de résoudre l'équivalence d'expressions au renommage des variables liées près : il suffit d'introduire une variable LISQL pour chaque variable liée. Par exemple, si on cherche les expressions x dx, x 2 dx ou y 2 dy, on construira la requête suivante.

term:functor : math:integral term:arg1 : ?X or term:functor : math:power term:arg1 : ?X term:arg2 : 2 term:arg2 : ?X Pour traiter la requête de l'introduction où x 2 peut être un sous-terme du corps de l'intégrale, il reste à exprimer la relation de terme à sous-terme. Un triplet (s, term:subterm, o) représente le fait que le terme s contient o comme sous-terme à une profondeur quelconque. La relation de sousterme est caractérisée par l'expression régulière (arg1 |arg2 | . . .) * sur les chemins du graphe RDF. Pour donner cette sémantique à term:subterm, il suffit de déclarer dans l'ontologie des termes, exploitée par l'interpréteur LISQL, que les propriétés term:arg1, term:arg2, ... sont des souspropriétés de term:subterm, et que la propriété term:subterm est transitive et réflexive. La recherche des intégrales en x contenant le terme x 2 peut alors se formuler comme suit.

term:functor : math:integral term:arg1 : term:subterm : term:functor : math:power term:arg1 : ?X term:arg2 : 2 term:arg2 : ?X Cette requête retourne les expressions x 2 dx, x 2 + 1 dx, y 2 -y dy, mais pas les expressions x 2 + y dy et 2x dx = x 2 + c. Maintenant, en partant du même exemple, supposons que l'on veuille obtenir le corps des intégrales plutôt que les intégrales elles-même. Il suffit pour cela de changer le point de départ de la requête et d'utiliser la construction p of q 1 de LISQL, qui permet de traverser les arcs du graphe RDF en sens inverse.

term:subterm : term:functor : math:power term:arg1 : ?X term:arg2 : 2 term:arg1 of term:functor : math:integral term:arg2 : ?X Cette requête recherche un terme contenant le sous-terme x 2 et apparaissant comme le corps d'une intégrale en x.

4 Extension de LISQL pour des représentations plus compactes f (a 1 ,a 2 ,. . .) term:functor : f term:arg1 : a 1 term:arg2 : a 2 . . . f (this,a 2 ,. . .) : q term:arg1 of term:functor : f term:arg2 : a 2 . . . q ...q... term:subterm : q ...this... : q term:subterm of q TAB. 2 -Nouvelles constructions syntaxiques de LISQL pour les termes et leur équivalence en LISQL originel. La deuxième construction se généralise pour n'importe quelle position de this.

Les exemples de la section précédente montrent que la syntaxe concrète de LISQL est lourde au point de rendre les descriptions et les requêtes presque illisibles et éloignées des notations mathématiques. La table 2 étend la syntaxe de LISQL avec de nouvelles constructions qui se réduisent simplement aux constructions existantes (sucre syntaxique). Là encore, nous nous inspirons de ce qui est fait en Prolog. La notation fonctionnelle f (x, y) sert à représenter un terme composé. En remplaçant un argument par le mot-clé this, on forme une propriété complexe allant d'un terme argument à son terme parent : par exemple, thisˆ2 lie x à x 2 , (a+b) à (a + b) 2 et peut se lire "a pour carré". Ensuite, on représente les URIs (opérateurs et variables) par leur label, par exemple + au lieu de math:plus et x au lieu de <x1>. Enfin, pour rendre les représentations encore plus lisibles, les foncteurs binaires peuvent être déclarés comme opérateurs infixes avec une certaine priorité (ex., x ˆ2 + 1 au lieu de +(ˆ(x,2),1)), et les foncteurs unaires peuvent être déclarés comme opérateurs préfixes (ex., -x ˆ2 au lieu de -(ˆ(x,2))) ou postfixes (ex, n ! au lieu de !(n)).

L'application de toutes ces améliorations aux exemples de la section précédente donne les représentations LISQL suivantes :

int(x ˆ2 + 1,x) pour la description de x 2 + 1 dx, int( ?X or ?X ˆ2, ?X) pour la recherche des intégrales en x dont le corps est x ou x 2 , int(... ?X ˆ2..., ?X) pour la recherche des intégrales en x contenant x 2 , -... ?X ˆ2... and int(this, ?X) : ? pour la recherche des corps des intégrales en x contenant x 2 .

5 Construction guidée de requêtes LISQL Dans les sections précédentes, les requêtes sont données toutes faites, ce qui suggère que les utilisateurs doivent les saisir. Les problèmes liés à la saisie de requêtes sont les possibles erreurs de syntaxes (quelle est la grammaire du langage de requêtes ?), la méconnaissance du vocabulaire (quelles sont les URIs, classes et propriétés ?) et le manque de contrôle du volume des résultats (vide ou pléthorique). Une des motivations de la représentation d'expressions mathématiques en RDF est l'utilisation de Sewelis pour leur exploration. Cette section montre comment Sewelis permet de construire de façon guidée et incrémentale des requêtes complexes et pertinentes.

n. notation math.

notation LISQL 1

x 2 dx int(x ˆ2, x)

2 x 2 + 1 dx int(x ˆ2 + 1, x) 3 2x dx = x 2 + c int(2 * x, x) = x ˆ2 + c 4 y 2 -y dy int(y ˆ2 -y, y)
TAB. 3 -Un petit jeu de données formé de quatre expressions.

Nous utilisons ici un jeu d'expressions mathématiques assez simple pour que les relations entre le jeu de données et les réponses du système soient transparentes. La table 3 liste quatre expressions sous leurs notations mathématique et LISQL. Elles font intervenir les opérateurs arithmétiques usuels, l'égalité et l'intégrale.

Nous décrivons maintenant le scénario qui permet de construire la requête int(... ?X ˆ2..., ?X). Après avoir chargé ce jeu de données dans Sewelis, la requête initiale par défaut est la requête vide ? qui sélectionne toutes les ressources, c'est-à-dire les constantes, les opérateurs, les variables, les 13 termes composés mais également les classes et les propriétés connues. Parmi les suggestions d'incréments de requêtes, on trouve les schémas de termes composés associés aux opérateurs utilisés, FIG. 2 -Une capture d'écran de Sewelis prise en cours de construction d'une requête. La requête est à gauche avec une zone de saisie matérialisant le focus. Les suggestions sont dans les deux colonnes à droite, colorées selon leur type (ex., termes en cyan, classes en orange).

par exemple int( ?, ?) ou ?+ ?. Si on sélectionne le premier, la requête devient int( ?, ?). Les réponses sont les 4 expressions et sous-expressions de type intégrale et la seule suggestion est this= ? : ? qui indique qu'une de ces intégrales apparaît comme terme gauche d'une égalité. Pour obtenir des suggestions sur une partie de la requête, on doit y positionner le focus, qui joue un rôle similaire au curseur d'un éditeur de texte. Toute sousrequête, et donc toute sous-expression, est un focus possible. Pour nommer la variable liée de l'intégrale, on déplace le focus sur le deuxième argument de l'intégrale. Les suggestions indiquent que la variable liée d'une intégrale est soit x soit y. On choisit d'insérer une variable LISQL ?X (à l'aide du bouton Name) pour s'abstraire du nom de cette variable liée. On déplace ensuite le focus sur le premier argument de l'intégrale. Les suggestions nous indiquent qu'à cette position on peut trouver une opération parmi l'addition, la soustraction, la multiplication et la puissance (1 occurence chacun) et rien d'autre (voir figure 2). On a également la suggestion ... ?..., qui indique que toutes les expressions à cette position sont un sous-terme d'une autre expression, ce qui est valide pour tous les termes. On choisit cette dernière suggestion et on déplace le focus sur le ? pour accéder aux sous-termes (au sens large) du corps de l'intégrale. La requête est désormais int(... ?..., ?X). Les suggestions sont les mêmes que précédemment plus la variable ?X et le nombre d'occurence de ? ˆ? est passé de 1 à 3 car 3 corps d'intégrales contiennent l'opérateur puissance. On sélectionne cette dernière suggestion pour contraindre une partie du corps de l'intégrale à être une puissance. Pour le deuxième argument de la puissance, la seule suggestion est 2, qu'on sélectionne. Pour le premier argument, les suggestions sont la variable LISQL ?X et les noms de variables x et y. On sélectionne la variable LISQL pour faire le lien avec la variable liée de l'intégrale. En remettant le focus sur la requête entière, on obtient bien les résultats attendus, à savoir les expressions 1, 2 et 4 de la table 3.

On peut aboutir au même résultat en partant du terme ?X ˆ2 et en accédant ensuite aux termes le contenant en sélectionnant l'incrément ...this... : ?. Les suggestions indiquent que x 2 apparaît comme corps d'une intégrale, comme premier argument d'une addition et d'une soustraction, et également comme sous-terme d'autres termes. Après quelques étapes, on atteint la requête ?X ˆ2 and ...this... : int(this, ?X) : ?, qui se lit comme «un terme de la forme x 2 qui apparaît comme sous-terme d'un terme qui apparaît lui-même comme corps d'une intégrale en x». En plaçant le focus sur le ? final, on obtient les mêmes réponses que ci-dessus.

Représentation des ensembles, listes, vecteurs et matrices

On trouve en mathématiques des structures de taille variable et nonbornée, notamment les ensembles, les listes, les vecteurs et les matrices. A priori, on peut utiliser les termes pour représenter ces structures, en utilisant un foncteur pour chaque type de structure et un argument pour chaque élément de la structure. Par exemple, on pourrait représenter l'ensemble {1, 2, 3} par le terme set(1,2,3) et le vecteur (1 2 3) par le terme vector(1,2,3). Un premier inconvénient est que, comme la taille de ces structures est non-bornée et potentiellement grande, cela suppose un ensemble non-borné de propriétés term:arg1, term:arg2... Un deuxième inconvénient est que cela ne permet pas de rechercher des structures contenant des éléments à des positions quelconques et dans un ordre donné, comme dans le langage de requête de Altamimi & Youssef (2008). Dans ce dernier, la requête vector(...,a,...,b,...) recherche les vecteurs contenant un a et un b dans cet ordre.

Nous réduisons le problème aux listes. En effet, une matrice est équivalente à un vecteur de vecteurs, un vecteur est isomorphe à une liste et pour les ensembles, bien que l'ordre des éléments ne soit pas significatif, leur représentation concrète implique le choix d'un ordre. De plus, les listes font partie intégrante du standard RDF. Si on a la liste [1,2,3], on peut en faire des ensembles ou vecteurs en lui appliquant différents foncteurs, set et vector, qui sont cette fois d'arité 1 quelque soit le nombre d'éléments.

Les listes peuvent être représentées par des combinaisons de termes. Dans de nombreux formalismes (LISP [START_REF] Steele | Common Lisp : the Language[END_REF], Prolog [START_REF] Sterling | The Art of Prolog[END_REF] Par rapport à nos termes, le foncteur term:cons est implicite et les propriétés term:arg1 et term:arg2 sont remplacées par les propriétés rdf:first et rdf:rest. On peut donc facilement passer d'une représentation à l'autre et on les considérera comme équivalentes dans la suite.

Les exemples précédents montrent que la représentation à base de termes est un peu lourde comparé à la notation mathématique, et la notation LISQL encore plus. La notation Turtle 2 permet de représenter la liste [1, 2, 3] sous la forme (1 2 3), à la LISP. C'est satisfaisant, mais cela ne s'applique qu'aux descriptions de listes complètement instanciées. Pour représenter une requête telle que "quelles listes commencent par 1 suivi de 2", il faut revenir à la notation à base de termes, en l'occurence cons(1,cons(2, ?)). Encore une fois, on s'inspire directement de Pro-2 http ://www.w3.org/TeamSubmission/turtle/ log qui offre une syntaxe à la fois concise et couvrant aussi bien les descriptions que les requêtes. La table 4 donne la traduction des nouvelles constructions syntaxiques liées aux listes (les deux dernières constructions sont expliquées au paragraphe suivant). Celles-ci permettent de représenter la liste [1, 2, 3] sous la forme [1,2,3], donc de façon naturelle, et de représenter la requête retournant les listes commençant par 1 et 2 sous la forme Il reste la question de pouvoir exprimer des sous-séquences dans les listes, par exemple "les listes contenant les éléments a et b, dans cet ordre". Comme les listes sont avant tout des termes, il est tentant d'utiliser la propriété term:subterm et de former la requête ...[a|...[b| ?]...].... Cependant, les sous-termes d'une liste ne sont pas seulement ses éléments et ses sous-listes, mais également les sous-termes des éléments. La requête précédente aura donc des réponses inattendues, par exemple la liste [z,a,z,[z,b,z],z]. Nous introduisons donc une nouvelle propriété transitive term:sublist qui relie toute liste à chacune de ses sous-listes. Cette propriété est donc la fermeture réflexive et transitive de la propriété rdf:rest. Les deux dernières lignes de la table 4 en donne une notation abrégée utilisant l'ellipse (...). En fait, cette ellipse peut être utilisée à la place de n'importe quel élément et dénote une suite d'éléments (éventuellement vide). La requête ci-dessus peut maintenant s'exprimer par [...,a,...,b,...], qui est équivalente à [...|[a|[...|[b|[...|[]]]]]].

Comparaison aux travaux existants

Nous comparons notre approche avec, d'une part, des langages de représentation d'expressions mathématiques, et d'autre part, des langages de requête pour la recherche d'expressions mathématiques (utilisés par exemple dans le cadre d'assistants de preuves, tels que Coq [START_REF] Guidi | A query language for a metadata framework about mathematical resources[END_REF]). À notre connaissance, aucune approche existante ne permet l'exploration guidée de telles expressions.

Langages de représentation

Le langage de référence pour la représentation d'expressions mathématiques est le langage MATHML3 , un dialecte de XML. En fait, MATHML définit deux langages : un langage de présentation et un langage de contenu. C'est ce dernier qui nous intéresse car il représente la structure logique d'une expression et évite les problèmes d'ambiguité (ex., e comme constante de Neper ou comme variable quelconque) et de synonymie (ex., x/y et x y pour la division). Le langage L A T E X joue le même rôle que le langage de présentation de MATHML, même s'il est parfois utilisé comme langage de contenu.

Le langage de contenu (strict) de MATHML est basé sur un petit nombre de balises XML qui encapsulent différents types d'expressions : <cn> (nombres), <ci> (identificateurs), <csymbol> (symboles), <cs> (chaînes), <apply> (applications), <bind> et <bvar> (quantifications). Par exemple, l'expression x 2 dx admet la représentation suivante en MATHML : SPIN4 utilise un vocabulaire semblable à nos termes pour la représentation des expressions de SPARQL en RDF. La notation OWL/RDF définit un vocabulaire ad-hoc pour la représentation RDF des axiomes OWL, qui sont des expressions. L'intérêt de notre approche est de définir un vocabulaire générique pouvant s'appliquer à tout type d'expressions : formules mathématiques, axiomes OWL, requêtes SPARQL ou même LISQL. Par exemple, la requête LISQL ?Xˆ(1 or 2) peut être représenté en LISQL par lisql:term(ˆ, lisql:var("X"), lisql:or(1,2)), où le vocabulaire lisql: définit les foncteurs des constructions du langage LISQL. Appliqués à OWL, nos termes se rapprochent de la notation fonctionnelle de OWL (ex., some(hasChild,Man) en LISQL au lieu de [a owl:Restriction ; owl:onProperty ex:hasChild ; owl:someValuesFrom ex:Man] en Turtle), tout en restant compatible avec RDF. La syntaxe de Manchester5 pour OWL peut ensuite être obtenue simplement en définissant les foncteurs du langage OWL comme des opérateurs infixes ou préfixes (ex., hasChild some Man).

Langages de requêtes

Si on laisse de côté les approches à base de recherche textuelle dont les limites ont déjà été exposées dans l'introduction, on trouve des langages de requête qui opèrent directement sur la structure logique des expressions. MathWebSearch [START_REF] Kohlhase | A search engine for mathematical formulae[END_REF] Le langage de requête le plus avancé est celui de Altamimi & Youssef (2008). Il utilise une notation ASCII aussi naturelle que peut l'être une telle notation et un jeu de 6 jokers qui peuvent être utilisés à la place de : un ou plusieurs caractères, un ou plusieurs atomes, une ou plusieurs expressions. Notre approche avec le langage LISQL offre une expressivité plus grande et un certain nombre d'avantages en plus pour l'utilisateur. LISQL offre une plus grande expressivité avec la disjonction, la négation et la possibilité de rechercher des sous-expressions apparaissant dans un certain contexte. Par exemple, il est possible de rechercher les corps d'intégrales en x contenant x 2 ou x 3 : ... ?X ˆ(2 or 3)... and int(this, ?X) : ?. Les 6 types de jokers sont couverts par la combinaison de : la requête vide ? (le joker universel), les variables LISQL pour les co-occurences d'un même atome, les ellipses ... correspondant aux propriétés transitives term:subterm et term:sublist, et les requêtes LISQL classiques contraignant le type et le nom des différents atomes d'une expression. L'avantage principal de notre approche est que l'utilisateur n'a pas besoin de maîtriser la syntaxe du langage de requête puisqu'il est guidé pas à pas dans la construction des requêtes (et des représentations) avec la garantie d'obtenir des réponses. Un autre avantage est que des caractères UTF8 peuvent être utilisés dans les noms des symboles (ex., au lieu de int), ce qui est possible du fait que ces symboles ne sont pas saisis par l'utilisateur, mais sélectionnés dans une liste de suggestions (ils sont également accessible par complétion automatique à partir du nom ASCII).

Conclusion et perspectives

Notre approche pour la représentation et l'exploration d'expressions mathématiques présente plusieurs qualités. Tout d'abord elle permet la représentation en RDF standard de ces expressions, assurant l'interopérabilité avec les autres connaissances représentées en RDF. Ensuite, le langage LISQL étendu combine à la fois des requêtes expressives et des notations IC 2012 naturelles et concises sans lesquelles LISQL serait impraticable pour les utilisateurs finaux. Enfin, la navigation dans Sewelis permet de construire des expressions et des requêtes de façon entièrement guidée avec des garanties fortes sur leur cohérence avec la base existante. Ces résultats présentés pour des expressions mathématiques se généralisent à toutes données structurées pouvant se représenter sous forme de termes (ex., axiomes OWL, requêtes SPARQL).

Nous avons pour l'instant appliqué notre approche à un jeu de 70 expressions utilisant 34 foncteurs tirées du formulaire du bac S. Comme perspectives, envisageons de traiter des jeux de données plus larges, sans doute extraits de données MATHML, d'évaluer les performances de Sewelis et son utilisabilité.

  par e dont le reste est l [this|l 1 ] : l term:cons(this,l 1 ) : l le 1er élément d'une liste l dont le reste est l 1 [e|this] : l term:cons(e,this) : l le reste d'une liste l commençant par e [e 1 ,. . . ,e n |l] [e 1 |. . .[e n |l]. . .] une liste commençant par la série e 1 , . . . , e n et se terminant par la liste l [e 1 ,. . .,e n ] [e 1 ,. . .,e n |[]] une liste composée des éléments e 1 , . . . , e n [...|l] term:sublist : l une liste ayant pour sous-liste la liste l [...|this] : l term:sublist of l une sous-liste de la liste l TAB. 4 -Nouvelles constructions syntaxiques pour les listes avec leur équivalence en LISQL et en français. Les symboles e (resp. l) dénotent des expressions LISQL quelconques représentant des éléments de listes (resp. des listes).

2

  Représentation RDF et LISQL des expressions mathématiques Un jeu de données RDF est un graphe orienté et étiqueté dont les noeuds sont des ressources (URI, blank nodes et littéraux) et dont les arcs s forment des triplets (s, p, o). Dans un triplet (s, p, o), p est une propriété RDF qui joue le rôle de prédicat et établit une relation entre le sujet s et l'objet o. Pour représenter les expressions mathématiques en RDF, nous profitons du fait que toute expression peut être représentée par un arbre, et donc par un graphe. Ces graphes permettent de plus de partager les différentes occurences d'une même variable ou d'un même opérateur.

p -→ o

  , RDF), une liste est soit la liste vide, soit une structure composée du premier élément de la liste et du reste de la liste, lequel est lui-même une liste. Cela implique deux foncteurs, c'est-à-dire deux constructeurs de listes. Le foncteur term:nil d'arité 0, qui correspond au symbole [] en Prolog, crée une liste vide. Le foncteur term:cons d'arité 2, qui correspond au symbole (.) en Prolog, crée une liste non-vide. Ainsi, le terme cons(1,cons(2,cons(3,nil()))) représente la liste [1, 2, 3]. Ces deux foncteurs d'arité fixe et petite permettent donc de représenter des listes de longeur arbitraire. En RDF, la liste vide est représentée par l'URI rdf:nil et une liste nonvide est représentée par un blank node qui est lié au premier élément par la propriété rdf:first et au reste de la liste par la propriété rdf:rest. La liste [1, 2, 3] peut donc être représentée en LISQL comme suit.

	rdf:first : 1
	rdf:rest :
	rdf:first : 2
	rdf:rest :
	rdf:first : 3
	rdf:rest : rdf:nil

  Nous discutons ici de leur correspondance avec la représentation RDF. Les nombres et les chaînes sont naturellement représentés par des littéraux RDF de différents types (ex., xsd:integer pour les entiers, xsd:string pour les chaînes). Les symboles (ex., fonctions, opérations, constantes) sont naturellement représentés par des URIs, idéalement dans des vocabulaires standards. Les identificateurs peuvent aussi être représentés par des URIs, mais de préférence locaux au document les utilisant. Les applications (d'une fonction à des arguments) peuvent naturellement être représentées par nos termes. Enfin, les quantifications peuvent aussi être représentées par des termes en considérant le quantificateur (ex., ∃, ∀, ) comme foncteur et en traitant les variables liées comme des arguments restreint à des identificateurs. La représentation LISQL de l'exemple précédent est ainsi int(x ˆ2, x), où par convention, le deuxième argument de int désigne la variable liée.Notre représentation RDF permet donc de représenter tous les contenus MATHML et ce de façon interopérable avec le langage de connaissance généraliste qu'est RDF. Par rapport à MATHML, cela permet de mixer librement connaissances mathématiques et connaissances non-mathématiques et également d'annoter librement les expressions et leurs constituants. Par exemple, le symbole int pourrait être décrit comme étant un quantificateur dont la variable liée apparaît comme second argument.

	IC 2012
	<bind><csymbol>integral</csymbol>
	<bvar><ci>x</ci></bvar>
	<apply><csymbol>power</csymbol>
	<ci>x</ci> <cn>2</cn>
	</apply></bind>

  définit un langage de requêtes XML qui étend MATHML. Sa syntaxe XML le rend très difficile d'utilisation et son expressivité est limitée. Par exemple, il ne permet pas d'exprimer la relation d'expression à sous-expression (ex., ...x ˆ2...).

http ://www.w3.org/TR/MathML3/Overview.html

http ://www.w3.org/Submission/2011/SUBM-spin-sparql-20110222/

http ://www.co-ode.org/resources/reference/manchester_syntax/


Alice Hermann
email: alice.hermann@irisa.fr

Sébastien Ferré
email: sebastien.ferre@irisa.fr

Mireille Ducassé
email: mireille.ducasse@irisa.fr

Aide à la création d'objets dans une base RDF(S) Aide à la création d'objets dans une base RDF(S) avec des règles de relaxation

Keywords: Web sémantique, RDFS, création, acquisition interactive de connaissances, règles de relaxation, interaction utilisateur

Quand un utilisateur crée un nouvel objet dans le Web sémantique, les outils existants n'exploitent ni les objets existants et leurs propriétés, ni les propriétés déjà connues du nouvel objet. Nous proposons UTILIS, une méthode d'aide à la création de nouveaux objets. UTILIS cherche des objets similaires au nouvel objet en appliquant des règles de relaxation à sa description. Les propriétés des objets similaires servent de suggestions pour compléter la description du nouvel objet. Une étude utilisateur menée avec des étudiants en master montre que les suggestions d'UTILIS ont été utilisées. Les utilisateurs ont trouvé les suggestions pertinentes : dans la plupart des cas, ils pouvaient trouver l'élément recherché dans les trois premiers ensembles de suggestions. De plus, ils les ont appréciées, car la majorité souhaitent les avoir dans un éditeur de données du Web sémantique.

Introduction

La mise à jour des données du Web sémantique (SW) est cruciale pour prendre en compte les informations régulièrement découvertes. Cela est, cependant, fastidieux et, en pratique, les données du SW sont rarement mises à jour par les utilisateurs. Or, dans le Web 2.0, les utilisateurs contribuent à la production des données, ce qui prouve que la motivation n'est pas un problème. Des modèles existent pour rapprocher le SW et le Web 2.0, en reliant par exemple les étiquettes créées par les utilisateurs avec le vocabulaire du SW [START_REF] Passant | Meaning of a tag : A collaborative approach to bridge the gap between tagging and linked data[END_REF][START_REF] Limpens | Sémantique des folksonomies : structuration collaborative et assistée[END_REF]. Cependant, il existe encore des difficultés à intégrer les données du Web Cet article présente UTILIS (Updating Through Interaction in Logical Information Systems), une méthode qui utilise les objets existants et la description partielle d'un nouvel objet, pour aider l'utilisateur à créer le nouvel objet. UTILIS cherche les objets similaires au nouvel objet, c'est-à-dire ayant des propriétés et valeurs en commun. Ces objets et leurs propriétés servent de suggestions pour compléter la description du nouvel objet.

Dans la suite, les exemples et l'expérience sont liés à la mise à jour d'une base d'indexation de cases de bandes dessinées. Un extrait est montré en figure 1. La case A est une case de la collection Ma vie à deux, avec Missbean et son chat ainsi qu'une bulle de dialogue dite par Missbean, à son chat.

La principale contribution de ce papier est un processus d'interaction qui aide l'utilisateur à créer de nouveaux objets en suggérant des propriétés et des valeurs adaptées finement à chaque objet en cours de création. Les propriétés déjà connues d'un nouvel objet sont utilisées pour en suggérer d'autres. Supposons qu'un utilisateur ajoute une case et indique la collection de bande-dessinée à laquelle elle appartient, cette dernière peut aider à suggérer des personnages, il est probable que cette case et celles de la même collection aient des personnages en commun. Ce processus utilise un ensemble de règles de relaxation, inspirées par les travaux d [START_REF] Hurtado | Query relaxation in RDF[END_REF], et un algorithme efficace pour calculer des suggestions. Un avantage de notre approche est que la définition d'une ontologie n'est pas nécessaire pour calculer les suggestions, même si UTILIS peut en utiliser une pour améliorer ses suggestions lorsqu'elle est disponible.

Une étude utilisateur menée avec des étudiants montre que ces derniers ont utilisé les suggestions d'UTILIS. Ils les ont trouvées pertinentes, en effet, dans la plupart des cas, ils pouvaient trouver l'élément recherché dans les trois premiers ensembles de suggestions. De plus, ils les ont appréciées, car 14 sur 18 souhaitent les avoir dans un éditeur de données du SW.

La section 2 donne des définitions relatives à des langages du SW et aux systèmes d'information logiques utilisés pour l'interaction avec l'utilisateur. La section 3 spécifie notre approche, UTILIS. La section 4 présente la création de la description d'une case. La section 5 présente l'étude utilisateur. La section 6 compare notre approche à l'état de l'art.

2 Préliminaires RDF, RDFS et SPARQL. RDF et RDFS sont des langages du Web sémantique qui permettent l'interopérabilité entre outils. Les éléments de base de ces langages sont les ressources et les triplets. Un triplet (s, p, o) peut être lu comme une phrase où s est le sujet, p est le verbe, appelé prédicat, et o est l'objet. Un triplet est composé de 3 ressources. Une ressource peut être soit un URI (nom absolu d'une ressource), un littéral ou une ressource anonyme. RDF permet de représenter des données. Par exemple, dans la base d'indexation, le triplet (<CaseK>, :personnage, <Missbean>) peut être lu comme "La case K a pour personnage Missbean". RDF possède un vocabulaire prédéfini permettant de représenter l'appartenance à une classe de ressources (rdf:type), la hiérarchie entre les classes (rdfs:subClassOf) et entre les propriétés (rdfs:subPropertyOf). Par exemple, le triplet ( :Bulle1, rdf:type, :BulleDeDialogue) dit que "La bulle 1 est de type BulleDeDialogue", ou plus simplement "La bulle 1 est une bulle de dialogue". La ressource :BulleDeDialogue est une classe. Le triplet (:BulleDeDialogue, rdfs:subClassOf, :Bulle) dit que "La classe BulleDeDialogue est une sous classe de Bulle", ou " Chaque bulle de dialogue est une bulle". RDFS est un langage de représentation des connaissances avec syntaxe, sémantique et inférence [START_REF] Hitzler | Foundations of Semantic Web Technologies[END_REF]. Par inférence, les deux triplets précédents permettent de déduire le triplet (<Bulle1>, rdf:type, :Bulle). Dans la suite, les descriptions des objets sont écrites en notation Turtle (Beckett et al., 2010) par souci de concision. Par exemple, la description d'une nouvelle case sous forme de triplets ((<Ca-seK>, rdf:type, :case) (<CaseK>, :personnage, <Missbean>)) s'écrit en

Français

Quelles sont les cases avec au moins une bulle dite par Missbean ? SPARQL SELECT ?x WHERE { ?x a :case . ?x :bulle ?y . ?y :ditPar <MissBean>} Turle (<CaseK> a case ; :personnage <Missbean>). SPARQL, pour sa part, est un langage de requête pour RDF fondé sur le graph pattern matching [START_REF] Prud | SPARQL query language for RDF[END_REF]. Une question et sa traduction en SPARQL sont montrées dans la figure 2.

Systèmes d'Information Logiques (LIS). Les LIS [START_REF] Ferré | An introduction to logical information systems[END_REF] forment un paradigme de recherche d'information et d'exploration, combinant l'interrogation et la navigation. Ils se rapprochent du paradigme de la recherche par facettes (Sacco & Tzitzikas, 2009). Leur langage de requête, LISQL, a une expressivité proche de celle de SPARQL et une syntaxe similaire à Turtle [START_REF] Ferré | Semantic search : Reconciling expressive querying and exploratory search[END_REF]. Un prototype, Sewelis 1 , a été implémenté. L'utilisateur navigue de requête en requête. Les liens de navigation, calculés automatiquement à partir des données, sont des transformations de requête en s'assurant qu'après transformation, la nouvelle requête ait des résultats et que chaque requête avec des résultats soit atteignable.

UTILIS : Guidage interactif pour la création d'objets

Cette section décrit UTILIS, la méthode de guidage interactif pour aider les utilisateurs à créer des objets dans un graphe RDFS. UTILIS cherche les objets similaires à la description du nouvel objet, c'est-à-dire ayant des propriétés et valeurs en commun. La figure 3 illustre le processus de raffinement interactif de la description d'un nouvel objet. L'élément initial est composé de la description courante d'un nouvel objet et d'un focus qui Description <CaseK> a :case ; :collection <Ma vie à deux> ; :personnage [] Requête initiale SELECT ?z WHERE { ?x a :case . ?x :collection ?y . ?x :personnage ?z . FILTER ( ?y = <Ma vie à deux>)} FIGURE 4 -Une description et sa transformation en requête initiale. correspond à l'élément de la description que l'on souhaite compléter. Cette description est transformée en requête (section 3.1). Cette requête est utilisée comme point de départ pour obtenir des requêtes généralisées à l'aide de règles de relaxation (section 3.2). Les requêtes initiale et généralisées permettent de calculer des objets similaires. L'intégralité du graphe RDFS est utilisée pour trouver ces objets. Ces objets et leurs propriétés servent de suggestions pour compléter la nouvelle description (section 3.3). Après raffinement, la nouvelle description sera utilisée pour définir une nouvelle requête et ainsi de suite. Un algorithme efficace pour calculer les suggestions à partir du graphe RDFS et de la description du nouvel objet a été implémenté selon les principes de la programmation dynamique (section 3.4).

Transformation de la description en requête initiale

La description est composée des éléments qui ont été renseignés par l'utilisateur à propos du nouvel objet. La figure 4 montre une description et la requête initiale obtenue après transformation. La description signifie que la case K est une case de la collection Ma vie à deux, qui a un ou des personnages, lesquels n'ont pas encore été spécifiés. Le focus est représenté par la partie soulignée. La description est transformée en requête en 3 étapes. D'abord, l'identité du nouvel objet est remplacée par une variable. Par exemple, <CaseK> est remplacé par ?x. Ensuite, la description est transformée en graph pattern SPARQL. Cela permet de n'avoir qu'un élément modifiable par triplet. Chaque triplet n'est composé que d'un seul individu. Les autres éléments du triplet sont des variables ou la propriété pré-définie rdf :type. Par exemple, ( :collection <Ma vie à deux>) est transformé en ( ?x :collection ?y FILTER ( ?y = <Ma vie à deux>)). Enfin, la description est transformée en requête en définissant la variable au focus comme variable à chercher et le corps de la requête correspond au graph pattern de l'étape 2. Cette requête initiale permet d'obtenir les objets qui ont toutes les propriétés et valeurs déjà connues du nouvel objet.

Règle

Triplet ou filtre initial Triplet relâché Condition SuperProperty ?x p 1 ?y ?x p 2 ?y

p 1 subp p 2 SuperClass ?x a c 1 ?x a c 2 c 1 subc c 2 Resource ?x = r 2 nil Property ?x p 1 ?y nil ∄p = p 1 .(p 1 subp p) Class ?x type c 1 nil ∄c = c 1 .(c 1 subc c)
FIGURE 5 -Règles de relaxation. Les ?x et ?y sont des variables, les r i sont des ressources (URIs ou littéraux), les p j des propriétés, et les c k des classes ; a, subc, subp sont des abréviations pour rdf:type, rdfs:subClassOf et rdfs:subPropertyOf.

Relaxation de la requête initiale

Après avoir renseigné deux ou trois couples propriété-valeur, la description d'un nouvel objet devient unique dans la base, en effet les objets de la base n'ont pas tous les mêmes couples propriété-valeur. La requête initiale, obtenue à partir de la description du nouvel objet, est alors sans résultats. Pour continuer à proposer des suggestions à l'utilisateur, UTILIS cherche les objets similaires au nouvel objet en généralisant cette requête. Pour généraliser la requête initiale, nous avons défini des règles de relaxation, inspirées des règles d'approximation de requêtes d [START_REF] Hurtado | Query relaxation in RDF[END_REF]. La figure 5 montre l'ensemble des règles de relaxation, applicables aux triplets. La première colonne montre le nom de la règle, la deuxième le triplet avant relâchement, la troisième le triplet relâché et la quatrième les éventuelles conditions pour l'application de la règle. À part les règles SuperProperty et SuperClass, les règles n'ont pas besoin d'ontologies pour la relaxation. La règle SuperProperty s'applique à un triplet ayant une variable comme sujet et objet et une resource p 1 comme prédicat. La condition d'application de cette règle est que p 1 soit une sous-propriété d'une autre propriété p 2 . Après l'application de cette règle, le sujet et l'objet restent identiques mais la propriété p 1 est remplacée par la propriété p 2 . Par exemple, ( ?x,:sAdresseA, ?y) peut être relâché en ( ?x,:converseAvec, ?y) par l'application de cette règle s'il existe le triplet (:sAdresseA,rdfs:subPropertyOf,:converseAvec). Le triplet relâché nil correspond à la supression du triplet initial. La distance entre la requête initiale et la requête généralisée est le nombre de règles appliquées pour passer de l'une à l'autre. À distance 0, ce sont les résultats de la re-quête initiale, sans généralisation. Par exemple, supposons que la requête initiale, c'est-à-dire celle obtenue directement à partir de la description, est (SELECT ?x WHERE { ?x a :case . ?x :collection ?y . ?x :personnage ?z . ?x :personnage ?a . FILTER ( ?y = <Ma vie à deux> && ?z = <Miss-Bean> && a = Fatbean)}) 2 . Une requête généralisée peut être la même sans le filtre ( ?z = <Missbean>) en appliquant la règle Resource sur ce filtre. Cette requête généralisée a une distance de 1. À la même distance, la règle Resource peut aussi être utilisée sur d'autres filtres, par exemple sur le filtre ( ?a = <Fatbean>). L'union de tous les résultats des requêtes généralisées avec une seule étape de relaxation sont les résultats proposés à distance 1. Les règles peuvent être combinées. L'ordre d'application des règles n'a pas d'influence sur les requêtes généralisées. Chaque requête généralisée a une distance unique. Cette propriété de confluence permet d'avoir un algorithme efficace en utilisant la programmation dynamique (section 3.4).

Raffinement de la description du nouvel objet

Les objets similaires sont les résultats des requêtes généralisées ou non. Ces objets et leur propriétés servent de suggestions pour compléter la nouvelle description. Les suggestions sont des ressources, des classes ou des propriétés. Si le focus est sur une ressource, les suggestions sont des classes et des propriétés. Par exemple, supposons que la description d'un nouvel objet est (<CaseK> a :case). Les suggestions faites à l'utilisateur sont des propriétés (ex. :personnage [], :collection []) et des classes (ex. a :case muette). La propriété suggérée :collection [] peut être sélectionnée pour spécifier que la nouvelle case a une collection, comme toutes les autres cases connues. La nouvelle description est (<CaseK> a :case ; :collection []) et le nouveau focus est sur l'objet de cette propriété. Si le focus est sur un [], les suggestions peuvent de plus être des ressources, ici les collections. En sélectionnant ici la collection Ma vie à deux, la nouvelle description est (<CaseK> a :case ; :collection <Ma vie à deux>) et le nouveau focus est remonté au niveau de l'objet en cours de création.

Pour présenter les suggestions à l'utilisateur et lui permettre de compléter la description du nouvel objet, les mécanismes d'interaction de Sewelis ont été réutilisés pour la création. Les suggestions sont utilisées comme liens de navigation. Par défaut, seules les suggestions de la plus petite distance sont proposées, la liste peut être élargie aux distances supérieures à 2. Quelles sont les cases de Ma vie à deux avec les personnages Missbean et Fatbean ? la demande de l'utilisateur, jusqu'à ce que tous les objets compatibles avec l'élément à chercher soient proposés. À tout moment, l'utilisateur peut saisir manuellement ce qu'il souhaite ajouter. Cette saisie est nécessaire pour les nouvelles valeurs. Des mécanismes d'auto-complétion aident à trouver les valeurs existantes. Une fois la suggestion sélectionnée par l'utilisateur, la nouvelle description sera utilisée pour définir la requête initiale et celle-ci sera généralisée pour permettre de faire de nouvelles suggestions à l'utilisateur.

Algorithme de relaxation

Un algorithme naïf pour le calcul des résultats à une distance d d'une requête q consiste à générer toutes les requêtes généralisées à une distance d, et à calculer l'union de leurs résultats. Ces requêtes généralisées sont obtenues en appliquant d relaxations sur les n triplets de la requête, ce qui fait au moins C d n requêtes généralisées. En raison de la nature des requêtes dont les triplets forment des graphes sans cycle, les résultats de chaque requête généralisée peuvent être calculés en O(n) opérations ensemblistes de type intersection et traversée de relations binaires. Le coût de l'algorithme naïf est trop important, surtout que les requêtes généralisées sont seulement des intermédiaires dans notre approche.

Nous utilisons dans UTILIS un algorithme plus efficace fondé sur la technique de la programmation dynamique qui calcule directement les résultats E(d, q) à une distance d d'une requête q, où la requête est représentée en notation Turtle. La fonction E est définie récursivement en s'appelant elle-même avec de plus petites distances et/ou des sous-requêtes. Les cas de bases sont quand d = 0 et q est une requête atomique (c'està-dire une ressource, une classe, ou []). L'algorithme est défini par un ensemble d'équations, couvrant toutes les combinaisons d'une distance et d'une requête. Par exemple, l'équation qui définit E pour les conjonctions de requêtes est

E(d, q 1 ; q 2 ) = d i=0 (E(i, q 1 ) ∩ E(d -i, q 2 )).
Cette équation dit qu'un résultat d'une requête q 1 ; q 2 est un objet qui est à la fois un résultat à une distance d 1 de q 1 et un résultat à une distance d 2 de q 2 , tel que Les résultats intermédiaires de E(d, q) sont stockés dans une table avec une ligne pour chaque distance de 0 à d, et une colonne pour q et chacune des sous-requête de q (soit O(n) colonnes). La complexité de calcul d'une cellule de ce tableau est de O(d) opérations ensemblistes. Par conséquent, la complexité de notre algorithme est de O(nd 2 ) opérations ensemblistes, c'est-à-dire polynomial au lieu de combinatoire pour l'algorithme naïf.

d 1 + d 2 = d, où la distance d est distribuée entre les deux sous-requêtes (d 1 = i et d 2 = d -i) de

Exemple

Pour illustrer UTILIS, cette section détaille des étapes de la création de la description d'une nouvelle case dans la base d'indexation. La base contient les cases montrées dans la figure 1 et six autres cases. Imaginons La figure 6 présente les étapes 2 à 7 de la création. À chaque étape, la première boîte contient la description courante de l'objet, le focus est souligné, la seconde boîte contient les suggestions avec, devant chacune d'elles, la distance minimale entre la requête initiale et la requête généralisée qui a permis cette suggestion. Pour des raisons de place, nous ne montrons à chaque étape qu'un nombre limité de suggestions. L'élément en gras correspond au choix de l'utilisateur.

À l'étape 2, la description courante est <CaseK> a :case. Les suggestions s'adaptent à cette description : ce sont les propriétés d'au moins une case. L'utilisateur choisit :collection []. La partie supérieure de la figure 8 montre l'interface utilisateur pour l'étape 3, les annotations en rouge ayant été faites à la main, la description courante est dans la partie gauche. Dans la partie droite, les ressources suggérées pour le focus sont listées, ici les collections. Au-dessus de cette partie, le nombre de suggestions est indiqué et un bouton More permet de les élargir aux distances supérieures contenant des résultats. À l'étape 3, l'utilisateur choisit <Ma vie à deux> parmi toutes les collections. Retournons à l'étape 4 de la figure 6, la description est <CaseK> a :case ; :collection <Ma vie à deux>. Les suggestions sont les propriétés d'au moins une case de Ma vie à deux. La propriété choisie par l'utilisateur est :personnage [] pour spécifier les personnages de la nouvelle case. À l'étape 5, les suggestions sont tous les personnages des cases déjà indexées de Ma vie à deux. L'utilisateur choisit <Missbean> et <Fatbean>. À l'étape 6, la requête initiale, correspondant à la description, n'a pas de résultats. En effet, ces 2 personnages n'apparaissent ensemble dans aucune case de la base. Par relaxation, UTILIS fait des suggestions à l'utilisateur de distances 1 et 7. La partie inférieure de la figure 8 montre l'étape 7, les classes et propriétés suggérées sont dans la partie du milieu. À partir de là, l'utilisateur peut continuer la description de la case et quand il décidera qu'elle est complète, il l'ajoutera à la base avec le bouton Assert.

Expérience utilisateur

Afin de savoir si les suggestions proposées par UTILIS lors de la création de nouveaux objets peuvent être utiles aux utilisateurs, une expérimentation a été réalisée. Des utilisateurs ont testé et évalué l'utilisabilité d'UTILIS et de Protégé 3 . L'interface et le guidage de Protégé sont représentatifs des éditeurs actuels. En effet, deux tiers des utilisateurs du Web sémantique l'utilisent comme éditeur (Cardoso, 2007). Nous avons rentré le domaine et le co-domaine de chaque propriété. Quand un utilisateur choisit la classe d'un individu, un formulaire avec les propriétés, ayant cette classe comme domaine, est créé. Pour les valeurs, les suggestions sont les individus du co-domaine de chaque propriété.

Méthodologie

Les sujets étaient composés de 18 étudiants en master d'informatique. Ils avaient une connaissance préalable en bases de données relationnelles, mais ne connaissaient ni UTILIS, ni Protégé, ni le Web sémantique. Pour chaque éditeur, ils devaient effectuer les mêmes tâches. La procédure de 3. http://protege.stanford.edu l'expérience pour chaque sujet a été la suivante : 1) lire une note d'introduction sur l'expérience globale ; 2) apprendre à utiliser un éditeur à l'aide d'un tutoriel de 30 minutes avec un exemple de création d'indexation ; 3) formuler et créer des indexations avec cet éditeur pendant 30 minutes ; 4) remplir un questionnaire sur cet éditeur ; 5) procéder en répétant les étapes 2 à 4 avec l'autre éditeur, et 6) remplir un questionnaire comparatif.

Les sujets devaient mettre à jour une base déjà existante, décrivant des cases de bandes dessinées. La base était identique à chaque début de session de test. Elle était composée de 362 individus, divisés en 16 classes et reliés par 20 propriétés, incluant 89 cases. Les sujets devaient mettre à jour la base avec deux jeux de cases. Ils ont été divisés en 4 groupes, chaque groupe a effectué 2 sessions de 1h30. Chaque groupe a testé un premier éditeur avec un des deux jeux puis l'autre éditeur avec le second jeu. Chaque jeu était composé de 11 cases, la case utilisée pour le tutoriel et 10 cases à créer, avec au moins 2 cases de la même collection. Les cases étaient présentées sur papier dans le même ordre pour tous les sujets. Elles existaient déjà dans la base, mais n'avaient aucune classe ni propriété. Les sujets avaient pour instruction d'entrer un maximum d'informations sur chaque case, prenant la description des cases existantes comme modèle. Ils avaient pour consigne de réutiliser autant que possible l'information existante. Ils pouvaient néanmoins créer des nouveaux éléments s'ils en avaient besoin.

Pendant les expériences, un fichier de log des actions utilisateur a été créé, enregistrant en particulier le nombre de descriptions créées sous UTI-LIS et Protégé, le mode de sélection des éléments des descriptions et le nombre d'élargissements des suggestions. En effet, comme déjà mentionné, les utilisateurs peuvent élargir les suggestions aux distances supérieures si l'élément recherché n'est pas présent dans les premières.

Résultats

Cette section discute des résultats de l'expérience. Il n'existe pas de différence significative entre le nombre de descriptions créées par les deux groupes initiaux sous Protégé et UTILIS, ni dans le nombre moyen d'erreur. L'ordre d'utilisation des outils n'a pas eu d'influence. Les erreurs sous Protégé pouvaient être un oubli ou une erreur dans un élément de la case et sous UTILIS également un mauvais placement du focus. Les sujets ont trouvé les suggestions pertinentes et souhaitent les avoir dans un éditeur de données du Web sémantique.

Des suggestions pertinentes. Les suggestions ont été utilisées par les La connaissance utilisée pour assister les utilisateurs à la création de nouveaux objets peut être de différents types et change selon l'éditeur.

Protégé utilise le vocabulaire et les axiomes de l'ontologie. À l'étape 2 de notre scénario, avec la base utilisée pour l'expérience, si le domaine et co-domaine des propriétés sont renseignés, 6 propriétés seraient proposées, 20 sinon. À l'étape 5, les 51 personnages de la base seraient proposés et 362 objets sinon. OKM [START_REF] Davies | Making the Semantic Web usable : interface principles to empower the layperson[END_REF] utilise les objets existants pour créer automatiquement des formulaires. À l'étape 2, les propriétés des objets de la même classe que le nouvel objet seraient proposées. À l'étape 5, l'utilisateur devrait commencer sa saisie pour que des objets lui soient proposés, et les premiers seraient ceux qui sont déjà objet de la propriété :personnage. Semantic MediaWiki [START_REF] Völkel | Semantic Wikipedia[END_REF] est une extension de MediaWiki, utilisée par Wikipédia. Son extension Semantic Forms 4 permet de créer des formulaires, pour créer des pages de wikis avec des liens sémantiques. À l'étape 2, les propriétés sélectionnées par le créateur du formulaire seraient proposées. À l'étape 5, le système proposerait des objets ayant déjà cette propriété, selon la saisie de l'utilisateur. Le wiki sémantique KiWI [START_REF] Schaffert | Kiwi -a platform for semantic social software[END_REF], anciennement IkeWiki, nécessite une ontologie pré-existante. À l'étape 2, toutes les propriétés seraient proposées. À l'étape 5, il faudrait commencer à saisir pour avoir une suggestion. Avec UTILIS, aucun travail préliminaire, ni aucune ontologie pré-existante ne sont nécessaires. UTILIS n'a pas besoin non plus de connaître les domaine et co-domaine des propriétés et la liste des objets s'adapte au nouvel objet.

Les éditeurs Gino (Bernstein & Kaufmann, 2006) et QuiKey [START_REF] Haller | QuiKey -an efficient semantic command line[END_REF] et le wiki sémantique ACEWiki [START_REF] Kuhn | How controlled english can improve semantic wikis[END_REF] utilisent un guidage s'appuyant sur la syntaxe et le vocabulaire, pour créer des triplets RDF(S). Lorsqu'un utilisateur commence sa saisie, Gino suggère, par autocomplétion, les ressources, les classes, les propriétés et les mots grammaticaux syntaxiquement correct. À l'étape 2, l'utilisateur devrait saisir des caractères pour que Gino lui propose des propriétés. À l'étape 5, Gino proposerait des objets. Avec Quikey, les suggestions proposées diminuent en fonction de la saisie de l'utilisateur. À l'étape 2, toutes les propriétés seraient proposées. À l'étape 5, le même mécanisme s'appliquerait avec les objets. ACEWiki propose des listes contenant les mots-clés et les ressources du graphe, autorisés pour compléter le triplet. À l'étape 2, la liste 4. http://www.mediawiki.org/wiki/Extension:Semantic_Forms des propriétés serait proposée. À l'étape 5, la liste des objets remplacerait celle des propriétés. Avec UTILIS, le filtrage est effectué sans saisie.

Conclusion

Nous proposons un système, UTILIS, qui guide les utilisateurs lors de la création d'objets dans un graphe RDFS. Le guidage s'appuie sur les objets existants, et sur la description courante du nouvel objet. À chaque étape, la description courante est utilisée pour trouver des objets similaires, dont les propriétés sont ensuite utilisées comme suggestions pour compléter cette description. Les objets similaires sont les résultats de requêtes qui sont généralisées à partir de la description courante. Ces requêtes sont obtenues par application des règles de relaxation. Un algorithme efficace pour le calcul des suggestions a été conçu et implémenté dans Sewelis.

Comparé à d'autres éditeurs RDFS, les suggestions d'UTILIS sont fondées sur les objets existants, plutôt qu'uniquement sur le schéma RDFS. Elles sont ainsi adaptées à chaque objet en cours de création. Un avantage est qu'UTILIS n'a pas besoin qu'une ontologie soit définie, même s'il peut en utiliser une pour améliorer ses suggestions lorsqu'elle est disponible. L'expérience a montré que les sujets ont trouvé les suggestions utiles et les ont réellement utilisées. En effet, dans la plupart des cas, ils pouvaient trouver l'élément recherché dans les trois premiers ensembles de suggestions. De plus 14 sur 18 souhaitent les conserver dans un éditeur.

Remerciements : Nous tenons à remercier Marie Levesque (alias Missbean) pour l'utilisation de la case extraite de Ma vie à deux : Pour le meilleur et pour le pire ! et son éditeur City Editions. Nous remercions également les 18 étudiants de l'école d'ingénieurs INSA qui ont participé à l'expérimentation.

Références

FIGURE 1 -

 1 FIGURE 1 -Extrait de la base d'indexation de bande dessinée

FIGURE 2 -

 2 FIGURE 2 -Une question et sa traduction en requête SPARQL.

FIGURE 3 -

 3 FIGURE 3 -Raffinement interactif de la description d'un nouvel objet.

FIGURE 7 -

 7 FIGURE 7 -Case de bande dessinée extraite de Ma vie à deux : Pour le meilleur et pour le pire !, écrite et dessinée par Missbean, City Editions.

  BECKETT D., BERNERS-LEE T. & PRUD'HOMMEAUX E. (2010). Turtle -Terse RDF Triple Language. W3C Recommendation. BERNSTEIN A. & KAUFMANN E. (2006). Gino -a guided input natural language ontology editor. In Proceedings of the International Semantic Web Conference (ISWC) : Springer. CARDOSO J. (2007). The semantic web vision : Where are we ? IEEE Intelligent Systems, p. 84-88.

TABLE 1 -

 1 Pourcentages d'éléments sélectionnés dans les suggestions, par saisie et par création, la plage d'élargissements des suggestions et le pourcentage sélectionnés dans les 3 premiers ensembles de suggestions. utilisateurs pendant la création des nouvelles cases. Le tableau 1 montre la proportion d'éléments de la description choisis par sélection d'une suggestion, par saisie et par création, ainsi que la plage d'élargissements des suggestions et le pourcentage sélectionné dans les trois premiers ensembles de suggestions. On peut voir, par exemple, que l'ajout des personnages a été fait, dans 90% des cas par la sélection d'une suggestion, 8% par saisie et 2% par création. Les éléments relatif à la collection, aux personnages et aux interlocuteurs des bulles, ont été, s'ils existaient déjà, sélectionnés à plus de 80% dans les 3 premiers ensembles de suggestions. Pour les lieux et les autres éléments, les suggestions ont été moins utiles. Ces éléments de la description sont plus subjectifs que les précédents et ont beaucoup été créés par les utilisateurs. Les questionnaires remplis après les expériences donnent une image cohérente. En effet, 16 sujets ont trouvé les suggestions pertinentes pour les personnages, 15 pour la collection, 12 pour les interlocuteurs, mais seulement 6 pour les lieux et 3 pour les autres éléments.Des suggestions appréciées. Les sujets ont été interrogés sur les éléments de chaque éditeur qu'ils aimeraient avoir dans un éditeur. Dix sujets souhaitent avoir les propriétés dans un formulaire comme dans Protégé. Cependant, 13 ont déclaré avoir été gênés par le parcours des listes entières d'objets sous Protégé. Dans UTILIS, 14 souhaitent conserver les suggestions adaptées à l'objet en cours de création, et 11 le mode de recherche par auto-complétion. Neuf (resp. sept) sujets souhaitent avoir les suggestions d'UTILIS pour certaines (resp. toutes les) propriétés.