(série: bonnes pratiques et choix de solution pour des graphes de connaissances)

La question posée ici concerne le choix de domaine pour définir des uris et la façon d'assurer un déréférencement des uris qui soit expressif. Il s'agit d'explorer les conséquences du lien profond qui lie les uris et ce qui peut être fait au niveau du déréférencement. Il s'agit aussi de voir comment assurer cette expressivité tout en poursuivant les objectifs du Linked Open Data (LOD).

Commençons par une recommandation du LOD: assurer des liens entre les graphes de connaissances en réutilisant des URIs déjà définies et utilisées dans d'autres datasets. Prenons un exemple de fait que nous souhaiterions exprimer dans notre dataset, exploitant le préfixe http://exemple.org/kg/ que nous abrégerons pas my:, sur des œuvres d'art: (oeuvre X, a pour créateur, Victor Hugo). Une mise en application naïve de cette recommandation conduirait à:

• définir une URI dans notre domaine pour 'oeuvre X' comme my:5212,
• chercher une URI existante pour exprimer la propriété 'a pour créateur'; dès qu'on se renseigne un peu sur l'existant, on trouve la référence au Dublin Core dans lequel la propriété dcterms:creator est définie; une autre façon de la trouver est d'utiliser le site Linked Open Vocabularies (LOV) et de faire une recherche sur créateur ou creator, le résultat nous montre que dcterms:creator semble le plus approprié,
• maintenant, nous voulons trouver une URI pour Victor Hugo; là encore, on trouve rapidement qu'il existe des graphes de connaissances généralistes comme DBPedia, Wikidata et Yago; par exemple, Wikidata présente une interface de recherche (https://www.wikidata.org/wiki/Wikidata:Main_Page) dans laquelle nous pouvons faire une recherche sur 'Victor Hugo' qui nous conduit rapidement sur https://www.wikidata.org/entity/Q535 (en fait https://www.wikidata.org/wiki/Q535 qui est la page HTML associée à l'entité https://www.wikidata.org/entity/Q535)

Cela nous donnerait le triplet:

my:5212 dcterms:creator wd:Q535

(note: certains préfixes utilisés peuvent être explicités avec le service https://prefix.cc/)

L'œuvre a donc un identifiant dans mon graphe de connaissances, et a une propriété issue d'un vocabulaire défini ailleurs et une valeur pour cette propriété définie encore ailleurs. J'ai donc bien ainsi tissé des liens avec d'autres datasets.

Quels sont les inconvénients de cette approche naïve?

D'abord, cela constitue des points de faiblesse pour notre graphe. En effet, admettons que l'exploitation de celui-ci dépende de propriétés de l'entité wd:Q535, ne serait-ce que le label associé. Si le dataset externe venait à être temporairement indisponible ou substantiellement modifié, l'exploitation de notre graphe serait compromise. Plus de datasets différents seraient référencés dans notre graphe, plus les exploitations de celui-ci seraient donc fragile.

Ensuite, concernant le déréférencement, le triplet ci-dessus ne suffirait pas à afficher une page descriptive de l'entité de façon compréhensible par une personne. On pourrait lui ajouter le triplet:

wd:Q535 rdfs:label "Victor Hugo"

Cela nous permettra d'afficher dans la page un lien dont le texte serait "Victor Hugo" et le lien associé "http://www.wikidata.org/entity/Q535". Mais un clic sur ce lien nous enverra vers la page correspondante de Wikidata avec sa propre présentation et aucun lien inverse renvoyant vers notre graphe. Globalement, si on veut avoir un déréférencement riche et contenant des liens internes à notre graphe, nous devrons définir une URI dans notre domaine pour Victor Hugo, par exemple my:Victor_Hugo.

Mais, si on veux maintenir des liens externes, nous allons devoir compléter par un triplet qui assure ce lien; on aura alors:

my:5212 dcterms:creator my:Victor_Hugo

my:Victor_Hugo owl:sameAs wd:Q535

my:Victor_Hugo rdfs:label "Victor Hugo"

En fait, on pourrait très bien avec nos propres URIS, puis compléter avec un ou plusieurs sameAs:

my:5212 dcterms:creator my:Victor_Hugo

my:Victor_Hugo rdfs:label "Victor Hugo"

Le même raisonnement pourrait se décliner sur les propriétés. Cependant, cela parait moins important tant des propriétés comme dcterms:creator et rdfs:label sont communément utilisés.

La critique liée au déréférencement sur une propriété est illustrée par exemple par le lien dcterms:creator qui envoie sur une description en anglais qui pourrait être inappropriée dans le contexte du dataset qu'on est en train de créer. De façon analogue et encore plus nette, rdfs:label renvoie sur une page contenant une ontologie complète au milieu de laquelle la propriété label est définie, ce qui n'est pas très convivial. Cependant, dans ce cas, on peut s'abstenir de rendre ce lien actif dans la page de déréférencement; par contre, il est pertinent de l'utiliser parce que de nombreux datasets l'utilisent et il est commun de chercher à "comprendre" une URI d'entité en cherchant le label associé grâce à une propriété rdfs:label.

Une autre approche peut consister à définir notre propre propriété comme égale ou dérivée de la propriété généralement utilisée. Par exemple, nous aurions:

my:label

Diverses façon peuvent être utilisées pour exprimer la relation entre my:label et rdfs:label. Par exemple:

my:label owl:sameAs rdfs:label

ou

my:label rdfs:subPropertyOf rdfs:label # permettrait d'exprimer des différences entre les deux

ou

my:label owl:equivalentProperty rdfs:label

L'inconvénient de ces approches est qu'elle complexifie l'écriture de requêtes sur le dataset et nécessite une compréhension des méthodes d'élaboration du dataset par ceux qui veulent l'exploiter.

Ce billet pourrait donner lieu à des développements longs. Nous allons nous limiter. Pour conclure, nous pouvons recommander de commencer par nos propres URIs pour les entités et pour les propriétés, sauf pour les propriétés qu'on souhaitera partager avec un maximum de datasets déjà bien établis et dans une deuxième étape, d'établir des liens entre nos URIs et des datasets externes.

Note: pour aller plus loin, je recommanderais, par exemple, l'article "An Analysis of Links in Wikidata" parru dans les actes de la conférence ESWC 2022.