LES DIFFÉRENTS RAISONNEURS

Un raisonneur est un logiciel basé sur un algorithme qui permet de:

Créer des inférences à partir d’une ontologie et permet donc de créer automatiquement une nouvelle information.

Par exemple, soit deux personnes et une relation symétrique ‘ami de’, si la personne A est ami à la personne B alors le raisonneur peut déduire de lui même que la personne B est ami à la personne A.

Valider le schéma d’une ontologie et ainsi vérifier qu’il n’a ai pas d’inconsistances. Par exemple, l’héritage de deux classes disjointes.

Il existe pour chaque langage, un raisonneur particulier. La complexité et la puissance des déductions dépendent du type de raisonneur choisi.

Dans le moteur OntoMea, les quatre raisonneurs suivants sont disponibles:

RDFS OWL DIG

Générique (utilise des règles prédéfinies)

Raisonneur RDFS

Le raisonneur RDFS est la solution la plus légère mais également la plus performante.

Elle est idéale pour les ontologies simples n’utilisant que les règles de déductions suivantes :

subClassOf subPropertyOf type

domain range

Exemple de déduction possible effectuée par le raisonneur RDFS. Grâce à la propriété

‘subClassOf’, nous allons gérer l’héritage.

<rdf:Description rdf:about=" #Mere">

<rdfs:subClassOf rdf:resource=" #Personne"/>

</rdf:Description>

<rdf:Description rdf:about=" # Pere ">

<rdfs:subClassOf rdf:resource=" #Personne"/>

</rdf:Description>

<rdf:Description rdf:about=" #Antoine">

<rdf:type rdf:resource=" #Pere"/>

</rdf:Description>

Cette ontologie précise que les classes ‘Mere et ‘Pere’ sont des sous-classes de

‘Personne’ et que ‘Antoine’ est une instance de la classe ‘Pere.

Ensuite, si l’on désire récupérer toutes les ressources du type ‘Personne’ il ne nous reste plus qu’à activer le raisonneur RDFS. Ainsi, le raisonneur logiquement va ajoute au modèle de base les lignes suivantes. Car si Antoine est un père alors c’est une personne aussi. Fonction transitive : (A -> B) & (B -> C) -> (A->C)

<rdf:Description rdf:about=" #Antoine">

<rdf:type rdf:resource=" #Personne"/>

</rdf:Description>

Ce raisonnement est commun à tous les raisonneurs. Le nombre et la complexité des nouvelles données déduites dépendent du type de raisonneur.

Raisonneur OWL

Le raisonneur OWL est une implémentation du standard OWL/Lite. S’il est nécessaire d’utiliser un raisonneur OWL/DL, il est préférable d’utiliser l’interface DIG d’OntoMea.

Jena offre trois niveaux de complexité pour son raisonneur OWL : Micro

Mini Full

Le niveau de complexité augmente selon le type de raisonneur sélectionné et, en contre partie, les performances diminuent. Malgré tout, OWL/Micro permet d’effectuer la plupart des déductions OWL et reste le meilleur compromis pour la plupart des ontologies.

Le raisonneur OWL permet d’effectuer des déductions plus complexes que RDFS. Il prend en charge la notion de restriction. Ainsi, il est possible de créer des classes définies avec certaines conditions de restriction.

Par exemple, si la classe ‘Car’ a une restriction ‘owl :hasValue 4’ sur la propriété

‘hasWheelNumber’, le raisonneur déduira automatiquement que l’instance suivante appartient à la classe ‘Car’ :

<Vehicule rdf:ID=" #MyVehicule">

<has:WheelNumber>4</ has:WheelNumber >

</Vehicule >

Interface DIG

Le dernier raisonneur disponible dans l’application OntoMea est un raisonneur interfacé avec un moteur externe offrant une interface DIG. Ce genre de moteur utilise le langage OWL/DL et peut être une alternative au raisonneur OWL de Jena qui est une implémentation de OWL/Lite.

Afin de configurer OntoMea pour une utilisation avec un moteur externe, il est nécessaire de préciser dans le fichier de configuration l’URL de l’interface DIG.

Le graphe d’inférences généré par ce processus ne contient pas les nouvelles déductions par défaut. Lors d’une requête, le moteur d’inférences externe sera interrogé.

A noter qu’OWL/DL, bien que plus complète, nécessite une plus grande précision dans les schémas d’ontologies. De nombreux schémas fonctionnant parfaitement avec OWL/Lite peuvent engendrer des erreurs lors de leur utilisation via l’interface DIG.

Raisonneur Générique

Le raisonneur générique de Jena permet d’exécuter des inférences selon un jeu de règles définies. Ces règles peuvent provenir de jeux déjà définis comme RDFS ou OWL.

Mais il est également possible de créer ses propres règles en se basant sur la syntaxe fournie par Jena.

Dans le moteur OntoMea, le raisonneur générique fonctionne en parallèle avec les autres raisonneurs. Il n’est donc pas nécessaire d’ajouter des jeux de règles RDFS ou OWL lors de la création de règles personnalisées.

Il est possible dans le fichier de configuration d’OntoMea de préciser quels sont les fichiers contenant les règles personnalisées. Les formats admis pour la balise

<uri>x</uri> sont les suivants :

l’URL du fichier de règles.

Le chemin absolu du fichier sur la machine locale.

Le nom du fichier à condition qu’il se trouve dans le répertoire KBOntoMea/Data/Rules.

Les modes de fonctionnements du raisonneur générique

Le raisonneur générique est en fait constitué de deux moteurs de règles distincts :

Forward engine permet de déduire des inférences pendant la création du graphe inféré. Ce graphe contient alors les données de base ainsi que les nouvelles déductions générées par le raisonneur générique.

Backward engine est un moteur d’inférence qui s’exécute lors d’une requête sur le graphe d’inférences. Aucunes nouvelles données ne sont ajoutées aux données de bases. Lorsque des inférences sont déduites lors de l’exécution d’une requête, les résultats obtenus sont stockés en mémoire.

Le moteur OntoMea utilise par défaut la configuration hybride. Cette structure permet d’effectuer des inférences en deux temps. Les règles attribuées au Backward engine peuvent se baser sur les résultats obtenus par le Forward engine.

Format de règles du raisonneur générique

Le format utilisé par les règles personnalisées de Jena est composé de trois parties distinctes :

Une liste de préfix qui définissent les ontologies utilisées dans les règles.

@prefix foaf: <http://xmlns.com/foaf/0.1/>.

Une liste de conditions (prémisses).

Une liste de conclusions.

Rule := bare-rule . or [ bare-rule ]

or [ ruleName : bare-rule ]

bare-rule := term, ... term -> hterm, ... hterm // forward rule or term, ... term <- term, ... term // backward rule hterm := term

or [ bare-rule ]

term := (node, node, node) // triple pattern

or (node, node, functor) // extended triple pattern or builtin(node, ... node) // invoke procedural primitive functor := functorName(node, ... node) // structured literal

node := uri-ref // e.g. http://foo.com/eg or prefix:localname // e.g. rdf:type

or <uri-ref> // e.g. <myscheme:myuri>

or ?varname // variable

or 'a literal' // a plain string literal or 'lex'^^typeURI // a typed literal, xsd:* type names supported

or number // e.g. 42 or 25.5

Le tableau de description de la syntaxe propre au ‘général purpose rule engine’

Le moteur d’inférences analyse les conditions et, s’il trouve des ressources qui les vérifient, ajoute alors les déclarations définies dans les conclusions de la règle. Les conditions peuvent prendre deux formes différentes :

Un triplet. Par exemple: ?s rdfs :subClassOf ?p

signifie que la ressource ?s doit être une sous-classe de ?p.

Une fonction. Par exemple: greaterThan(?x, ?y).

Les conclusions ne sont possibles que sous la forme de triplets.

Il existe deux modes d’exécution des règles. Comme défini précédemment, les règles peuvent être exécutées avant ou après la création du graphe d’inférences. Pour spécifier le mode d’exécution d’une règle personnalisée, il est nécessaire d’utiliser les formats suivants :

conditions -> conclusions pour le mode forward.

conclusions <- conditions pour le mode backward

Il est évidement nécessaire que le raisonneur soit configuré dans le mode approprié ou dans le mode hybride. Dans le cas contraire, la règle sera exécutée dans le mode défini par le raisonneur.

(Voir : http://jena.sourceforge.net/inference/)

Exemple et limitation

Ci-dessous, un exemple d’une des mes règles pour définir les préférences en matière d’hôtel.

La règle sélectionne le nombre de fois où une personne a été dans un hôtel avec les caractéristiques suivantes : animaux autorisés ou chien autorisés ainsi que les animaux non-autorisés.

A partir de ces données, je calcule si le quotient du nombre de fois où il a choisi animaux autorisés est supérieur à 80% et les non-autorisés inférieur à 20%. De la j’en conclue que cette personne voyage avec un animal de compagnie c’est pourquoi je vais lui suggérer un hôtel qui a cette caractéristique.

@prefix tdprofile: <http://www.websemantique/TDprofile#>.

@prefix memo: <http://www.memoria-mea.ch/memonto.owl#>.

@prefix foaf: <http://xmlns.com/foaf/0.1/>.

[animaux_autorises:

(?personne tdprofile:chooseAnimauxAutorises ?a),

(?personne tdprofile:chooseChienAccepte ?b), max(?a, ?b, ?c),

(?personne tdprofile:sumHotel ?sH), quotient(?c, ?sH, ?qu), greaterThan(?qu, 0.8), (?personne tdprofile:chooseAnimauxNonAutorises ?d), caractéristique. Evidemment, j’ai tout d’abord cherché à calculer cette somme à l’aide d’une règle et malheureusement je suis tombé sur une des limitations des raisonneurs.

Actuellement, il n’a pas de support pour les fonctions d’agrégations dans Jena donc il m’est impossible de compter dans ma règles le nombre d’occurrences d’une caractéristique par rapport à un utilisateur. On pourrait imaginer contourner cette limitation avec le langage SPARQL d’ARC (Voir : http://arc.semsol.org/)