Help:Déduction

La recherche sémantique peut être utilisée pour trouver des pages basées sur les informations que des utilisateurs ont entrées dans celles-ci dans un wiki. Ceci simplifie bien des tâches mais réclame que l'information sémantique soit entrée manuellement en premier lieu. Dans certains cas, on souhaiterait que le wiki soit plus « intelligent » et qu'il déduise certains faits même s'ils n'ont pas été entrés directement. Dans certains cas, SMW peut faire de telles déductions automatiquement comme décrit dans cet article.

Sous-catégories
MediaWiki supporte une hiérarchie de catégories qui aident à simplifier les déclarations de catégories nécessaires à chaque page. Par exemple, supposons qu'un wiki utilise les catégories « Personne », « Femme » et « Homme ». Il est clair pour le commun des mortels que toute page qui appartient à la catégorie « Femme » devrait aussi appartenir à la catégorie « Personne ». Mais « Femme » est clairement plus spécifique et beaucoup de wikis (dont Wikipédia) ont une politique pour utiliser les catégories les plus spécifiques sur une page &mdash; autrement la page contiendrait des dizaines de catégories qui seraient particulièrement difficiles à maintenir. Pour indiquer qu'une catégorie est plus spécifique qu'une autre, MediaWiki supporte une hiérarchie de catégorie où les utilisateurs peuvent statuer qu'une catégorie est une sous-catégorie d'une autre, simplement en plaçant la catégorie en question sur la page de la sous-catégorie, par exemple, la page Catégorie:Femme contiendrait le texte

Pour plus de détails, voir le manuel de MediaWiki.

Par défaut, SMW utilise cette information de sous-catégorie dans les recherches sémantiques : quand on demande toutes les pages qui appartiennent à une catégorie donnée, il trouvera aussi toutes les pages qui appartiennent aux sous-catégories de celle-ci. Dans l'exemple ci-dessus, la requête   donnerait aussi toutes les pages des catégories « Femme » et « Homme ». En d'autres termes, la requête correspond à

OR OR

Si l'arborescence de catégorie est développée, SMW donnera aussi les sous-catégories concernées. Par exemple, on peut avoir une catégorie « Mère » pour toutes les femmes qui ont des enfants et qu'elle soit une sous-catégorie de « Femme ». Ainsi la requête ci-dessus retrouverait aussi toutes les pages de la catégorie « Mère ».

Le mécanisme de SMW des déductions de sous-catégories peut être restreint ou désactivé par l'administrateur du site. Normalement, il support seulement une profondeur donnée dans la hiérarchie de catégorie ce qui veut dire qu'elle peut ne pas donner tous les résultats s'il existe une longue chaine de sous-catégories. L'utilisation d'une requête créée manuellement avec OR comme l'exemple du dessus est manière de détourner cette limite mais elle ne prend pas du tout en compte tout changement éventuel fait au niveau de la hiérarchie de catégories.  Catgegory:Cities  still returns all pages related to that topic, it just does not return actual cities only. So one might argue that the name of the category is confusing in some sense, but this is merely a matter of how to organise a wiki. If a wiki has no category for actual cities as such, then no semantic query can produce all cities directly.

A more serious problem in large wikis might be what is called «semantic drift». This occurs if the exact intention of some category is not really specified, e.g. because it lacks a detailed description on its page. Different users then may have slightly different readings of the categories meaning, and this may influence how they use sub-category statements. For example, some editors may reasonably say that «Priest» is a subcategory of «Religious office» (referring to the job category), while others may deem «Female priest» to be a subcategory of «Priest» (referring to the class of people having that job) – but this would imply that all pages in «Female priest» are also implicitly categorised in «Religious office», thus confusing people and job occupations. It is therefore important to always clearly describe on a category page what should go into a category and what shouldn't, and also to point to alternative catgegories that may be suitable.

Subproperties
Just like categories, also properties can be more specific than one another. For example, a wiki may have the property «capital of» to relate cities to countries, and a property «located in» that generally describes that some city is located in some country. Now it happens to be the case that every capital city also must be located in the country that it is capital of. In other words, «capital of» is a subproperty of «located in». Whenever a user states that a page is a capital of some country, SMW should then also conclude that the page has an (implicit) «located in» relation to that country as well. To say that in the wiki, the following can be entered on the page Property:Capital of:

subproperty of::Property:located in

Once this has been stated, a query  located in::Germany  will also return the capital Berlin even if no «located in» property is given on that page. Similar considerations as in the case of cateogries apply, and detailed descriptions on property pages are a good method for avoiding semantic drift.

Equality of pages: redirects
It often happens that a thing can be referred to by different names, such as in the case of "Semantic MediaWiki", which is synonymous with "Semantic MediaWiki". In MediaWiki, this is solved by redirects that forward readers from one page to another. But synonyms may be even more important in a semantic wiki, where one wishes to organise content and make it more accessible. If different editors use different page names in annotations, then it is hard to create queries which will still display a unified view on the wiki content.

SMW therefore treats all redirects between pages as synonyms. This means that it does not matter at all whether a redirect page or the actual target page is used in a query or annotation. SMW internally uses only redirect targets to work with, and all functions will take the redirect structure into account. This mechanism works only for immediate redirects: redirects that point to other redirect pages are not supported and should be resolved (this is also the case in MediaWiki anyway).

Since SMW 1.2, it is also possible to use redirect on properties and categories with the same effect, so multiple synonyms for properties can be created. It is not suggested to use that feature for the case of categories, though, simply because MediaWiki's category functions will still ignore category redirects such that some wiki features will not work as expected. Redirects between two different namespaces, such as redirects from normal pages to properties, properties to categories, etc. are not supported in a special semantic way. They still create normal MediaWiki redirect pages but nothing else.

Inferencing and printout statements
Printout statements do generally not perform any inferencing, i.e. they will only return the statements that are explicitly made for some page. This is desired in some situations, and it may be a limitation in others. A work-around can be to use a template for annotation, and to give two property values explicitly in that template, essentially by writing something like

capital of::located in::Germany

which is the same as writing capital of::Germany and located in::Germany, but it will show only one link to Germany.

Inferencing features that are not supported
It sometimes happens that ambitious contributors in a wiki will create properties that also suggest a specific meaning for automated deduction. It should therefore be noted that SMW does not support any of the following features:


 * Transitivity
 * Domain and range restrictions
 * Number restrictions and functional properties

Even if properties that sound like the above are introduced, and even if these are linked to well-known properties in ontology languages such as OWL, RDFS, SKOS, etc., SMW will not use these annotations to perform smarter queries. To prevent confusion, it is suggested to not use names that resemble established notions in existing ontology languages, or at least to clearly document this limiation on the property pages.

To some extent, one may be able to craft queries to achieve a similar effect. The sample pages Germany and California show examples of queries for inverse relationships; the sample page Germany shows an example of a subquery that approximates a transitive relationship to some extent.

-->