Impossible de remapper les property paths avec RiC-O 1.0

[tfrancart]

Bonjour @florenceclavaud (pas urgent)

@Marie-Sparna a repointé la config A de Sparnatural par rapport à RiC-O 1.0. Le tableau Excel de pointage est dans ce repository àhttps://github.com/sparna-git/sparnatural-rico-1.0/blob/main/Pointage%20config%20A%20-%20RiC-O_v1-0.xlsx

On tombe sur un "hic" : avec le nouveau mécanisme de relations "rolifiées", il n'est plus possible d'écrire des property paths directs qui traverses les relations (à moins d'inclure les propriétés de rolification dans le property path, mais comme personne ne va les saisir, et que les raisonneurs ne savent pas les ajouter, ce n'est pas une bonne idée).

Avant, on avait <https://www.ica.org/standards/RiC/ontology#groupIsSourceOfMembershipRelation>/<https://www.ica.org/standards/RiC/ontology#membershipRelationHasTarget> et on savait qu'on était sur une MembershipRelation de part l'utilisation du prédicat groupIsSourceOfMembershipRelation. Mais maintenant, avec les prédicats génériques, le path devient thingIsSourceOfRelation/relationHasTarget, ce qui traverse tous les types de relation, pas seulement les MembershipRelations. Pour ce cas, on peut toujours mapper sur la propriété binaire hasOrHadMember.

Autre cas plus problématique : "date de dabut d'exercice" est mappée actuellement sur <https://www.ica.org/standards/RiC/ontology#agentIsTargetOfPerformanceRelation>/<https://www.ica.org/standards/RiC/ontology#beginningDate>. Avec les relations génériques, ça deviendrait agentIsTargetOfRelation/beginningDate, ce qui irait regarder sur tous les types de relation. On ne peut pas écrire de property path pour ce cas avec le RiC-0 1.0.

Une solution serait une évolution de Sparnatural pour:

• pouvoir écrire un sparqlString contenant une variable SPARQL, ce qui permettrait d'inclure le prédicat de type, comme par exemple : <https://www.ica.org/standards/RiC/ontology#agentIsTargetOfRelation> ?x_$index . ?x_$index a <https://www.ica.org/standards/RiC/ontology#PerformanceRelation> . ?x_$index <https://www.ica.org/standards/RiC/ontology#beginningDate>
• Pour garantir l'unicité des variables, il faut que Sparnatural remplace dans la query la partie $index par un numéro unique correspondant au numéro du critère interne dans Sparnatural

On peut aussi supprimer ça dans la config.

On en reparle à l'occasion

[florenceclavaud]

@Marie-Sparna a repointé la config A de Sparnatural par rapport à RiC-O 1.0. Le tableau Excel de pointage est dans ce repository àhttps://github.com/sparna-git/sparnatural-rico-1.0/blob/main/Pointage%20config%20A%20-%20RiC-O_v1-0.xlsx

Merci beaucoup, je regarde dès que je peux.

On tombe sur un "hic" : avec le nouveau mécanisme de relations "rolifiées", il n'est plus possible d'écrire des property paths directs qui traverses les relations (à moins d'inclure les propriétés de rolification dans le property path, mais comme personne ne va les saisir, et que les raisonneurs ne savent pas les ajouter, ce n'est pas une bonne idée).>

Ah oui ! et flûte :(.

Avant, on avait https://www.ica.org/standards/RiC/ontology#groupIsSourceOfMembershipRelation/https://www.ica.org/standards/RiC/ontology#membershipRelationHasTarget et on savait qu'on était sur une MembershipRelation de part l'utilisation du prédicat groupIsSourceOfMembershipRelation. Mais maintenant, avec les prédicats génériques, le path devient thingIsSourceOfRelation/relationHasTarget, ce qui traverse tous les types de relation, pas seulement les MembershipRelations. Pour ce cas, on peut toujours mapper sur la propriété binaire hasOrHadMember.

Oui, et sauf si j'ai oublié qque chose pendant la rolification, toutes les classes de relation n-aires sont associées à un shortcut (souvent en fait deux, puisqu'elles correspondent à des relations orientées) dans RiC-O 1-0. Je vais vérifier cela, même si je suis sûre à 99 % que je l'ai fait, j'y ai passé beaucoup de temps. Seulement pour que ça marche dans Sparnatural il faudrait que le jeu de données inclue les shortcuts, et on ne peut pas l'exiger... Dans les jeux de données des AnF ça va marcher (avec RiC-O Converter) mais au-delà... même si on recommande de générer ces shortcuts, tout le monde ne le fera pas.

Une solution serait une évolution de Sparnatural pour:>

• pouvoir écrire un sparqlString contenant une variable SPARQL, ce qui permettrait d'inclure le prédicat de type, comme par exemple : <https://www.ica.org/standards/RiC/ontology#agentIsTargetOfRelation> ?x_$index . ?x_$index a <https://www.ica.org/standards/RiC/ontology#PerformanceRelation> . ?x_$index <https://www.ica.org/standards/RiC/ontology#beginningDate>>
• Pour garantir l'unicité des variables, il faut que Sparnatural remplace dans la query la partie $index par un numéro unique correspondant au numéro du critère interne dans Sparnatural>

Je trouve que ce serait bien. C'est une bonne logique. En SPARQL directement, c'est ce à quoi on pense naturellement. Ca demanderait beaucoup de travail de faire cela ?

On peut aussi supprimer ça dans la config.>

Ben le problème c'est qu'on a quand même besoin de parcourir ces relations, ou, comme tu le dis ci-dessus, de sortir parfois leur date, ou leur description. Je pense, dans le jeu de données RiC-O 1.0, à parcourir des relations chronologiques entre agents notamment.

On en reparle à l'occasion

Oui. Je dois d'abord importer le jeu de données dans le GraphDB. je vous fais signe quand c'est fait.

[florenceclavaud]

Bon, j'ai vérifié, toutes les classes *Relation de RiC-O 1.0 sont rolifiées.
Par ailleurs, voici un exemple de requête SPARQL qui traverse des relations n-aires, et qui est particulièrement pertinent et intéressant pour un archiviste ou pour un chercheur en histoire de l'administration :

# Recherche des collectivités (rico:CorporateBody) qui ont succédé à une collectivité précise, dont on connaît une partie du nom

PREFIX rico: <https://www.ica.org/standards/RiC/ontology#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?entite ?nom ?dateDebut ?dateFin ?archives WHERE
{
   ?bureauMH rdf:type rico:CorporateBody; rdfs:label ?label .
    FILTER contains(?label, 'Monuments historiques (1839'@fr) .
    ?bureauMH (rico:precedesInTime)+ ?entite .
    ?entite rdfs:label ?nom; rico:beginningDate ?dateDebut .
    OPTIONAL {
        ?entite rico:endDate ?dateFin; rico:isOrganicProvenanceOf ?archives 
    }    

}

Le verbe rico:precedesInTime est le raccourci de :thingIsSourceOfRelation/temporalRelation_role/relationHasTarget

Cette requête fonctionne sur le jeu de données RiC-O 1.0 des AnF fourni avec RiC-O 1.0:https://github.com/ICA-EGAD/RiC-O/tree/master/examples/examples_v1-0/NationalArchivesOfFrance/rdf-xml. Mais comme vous l'avez vu ça ne marche que parce que les triplets de raccourcis sont présents dans le jeu de données.

Et un autre exemple de requête SPARQL portant directement sur des relations et aussi utilisables pour le jeu de données 1.0. Pour cette requête, on peut configurer Sparnatural (on adapterait un peu la logique : trouve-moi les relations qui relient Jean Favier, et [tous les autres agents liés], et la description et les dates de ces relations). On ne l'a pas encore fait dans nos configs mais c'est également intéressant, et c'est aussi pédagogique pour expliquer ce que c'est qu'une instance de relation. Le test sur l'URI (pour éviter de ramener dans les résultats l'agent point de départ) par contre n'est pas a priori implémenté dans Sparnatural (ou bien je me trompe ?) ; or on a des relations 'symétriques' (pas orientées), et de toute façon pour cet exemple on ramène toutes les relations, donc on utilise rico:relationConnects.

# les relations de Jean Favier (agent/050312) avec d'autres agents

PREFIX rico: <https://www.ica.org/standards/RiC/ontology#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT DISTINCT ?relation ?label ?description ?dateDebut ?dateFin ?agentLié ?nomAgentLié

WHERE 
{
?relation a rico:Relation; rdfs:label ?label .
OPTIONAL {
?relation rico:generalDescription ?description; rico:beginningDate ?dateDebut ; rico:endDate ?dateFin .
}
?relation rico:relationConnects <http://data.archives-nationales.culture.gouv.fr/agent/050312> .
?relation rico:relationConnects ?agentLié .
?agentLié rdfs:label ?nomAgentLié .
FILTER (str(?agentLié) != 'http://data.archives-nationales.culture.gouv.fr/agent/050312')
}

ORDER BY ?dateDebut

Je mets cela ici parce que pour le démonstrateur RiC-0 1.0 ça peut être intéressant et que finalement pour les évolutions de Sparnatural aussi, ça pourrait l'être (je parle aussi du test sur l'URI).

Cette semaine je n'aurai pas le temps de travailler là-dessus mais je peux le faire la semaine prochaine. Je me demande par ailleurs si je ne vais pas ajouter aux exemples RiC-O 1.0 un jeu de requêtes SPARQL documentées.

[tfrancart]

Je crois que dans un premier temps, le plus simple est de faire apparaitre la Relation dans la config Sparnatural. De cette façon nous pourrons:

• lui attacher les critères de date et de description (ce qui solutionne le problème d'origine)
• répondre au dernier use-case cité sur les relations de Jean Favier

Et il faudrait en plus mettre dans la config les liens raccourcis correspondant.

Ce qu'on ne pourra pas faire c'est rechercher de façon tranparente sur un lien, sans se préoccuper de savoir si le lien est exprimée par une relation ou par un raccourci. Il faudra chercher soit sur le raccourci, soit en passant par la relation.

[florenceclavaud]

Bonjour @tfrancart, oui c'était bien mon idée de faire apparaître la Relation (en en restant à la superclasse Relation ou à une classe de haut niveau) dans la config générique RiC-O 1-0.

Mais il n'en reste pas moins que traverser une relation de façon transparente, sans compter sur la présence des raccourcis, est aussi important (traverser, c'est ce qu'on fait habituellement et cela simplifie le questionnaire), et donc je voudrais quand même savoir s'il est envisageable de faire évoluer pas trop tard Sparnatural selon ton idée (pouvoir définir un sparqlString incluant une variable qui type la relation).

[florenceclavaud]

Suite : j'ai pu importer dans le GraphDB des AN (dans un dépôt que j'ai nommé sparnatural-rico-1_0 comme dans la config. Sparnatural), dans 2 graphes nommés différents, l'ontologie RiC-O 1.0, et le jeu de données RiC-O 1.0 des AnF disponible ici.

J'ai eu au départ des soucis d'accès au dépôt, et l'interface d'administration de GraphDB que j'ai fini par utiliser (navigation privée dans Firefox) ne daigne pas me dire que l'import est terminé..., mais bon après quelques tests je crois que toutes les données y sont.

On pourrait aussi envisager d'importer dans un autre graphe le jeu de données écossais. Ca permettrait à mon sens d'avoir plus de possibilités à la recherche. Il est par ailleurs en anglais, donc on pourrait décliner l'interface en anglais. Mais il faudrait quand même que je demande à ma collègue du groupe EGAD qui m'a fourni les fichiers sources son accord.

On en reparle bientôt, pour aujourd'hui je n'ai plus le temps de faire plus.

[tfrancart]

Mais il n'en reste pas moins que traverser une relation de façon transparente, sans compter sur la présence des raccourcis, est aussi important (traverser, c'est ce qu'on fait habituellement et cela simplifie le questionnaire), et donc je voudrais quand même savoir s'il est envisageable de faire évoluer pas trop tard Sparnatural selon ton idée (pouvoir définir un sparqlString incluant une variable qui type la relation).

Non, on ne le fera pas. Car on est là en face d'une limite d'expressivité de SPARQL dans les property paths. C'est une limite que j'avais pointé dans des propositions pour un potentiel SPARQL 1.2 : https://github.com/w3c/sparql-dev/issues/99

Même si on implémentait ma proposition ci-dessus, on ne pourrait pas la combiner avec un opérateur "+", ce qui ne permettrait pas de toutes façons d'implémenter le cas d'usage fourni.

Le mieux que l'on puisse faire c'est de s'appuyer sur la propriété de rolification qui pourrait être inférée dans GraphDB. Dans ce cas nous pourrions avoir ce property path qui permet de 1/ requêter sur le raccourci ou la relation de façon transparente et 2/ suivre ces liens de façon récursive:

(rico:precedesInTime|(rico:thingIsSourceOfRelation/rico:temporalRelation_role/rico:relationHasTarget))+

[tfrancart]

Pour préciser : il y a 3 sujets:

1. Le fait de pouvoir faire un raccourci dans Sparnatural qui "traverse" une relation
2. Le fait de combiner ce raccourci avec le prédicat direct équivalent
3. Le fait de pouvoir traverser ces relations, les prédicats directs de faàon récursive

La seule façon de faire ces 3 choses en même temps est d'utiliser le property path proposé ci-dessus:

(rico:precedesInTime|(rico:thingIsSourceOfRelation/rico:temporalRelation_role/rico:relationHasTarget))+

Ce property path nécessite la présence du lien de rolification dans les données (ici rico:temporalRelation_role). Je ne souhaite pas faire de modifications dans Sparnatural pour contourner ce problème qui est à régler au niveau du triplestore, et qui de toutes façons ne répondra pas aux 3 besoins ci-dessus.

[florenceclavaud]

Oui j'ai bien compris ! Je suivais juste le fil de ta toute première proposition, et je n'avais pas vu ton lien vers https://github.com/w3c/sparql-dev/issues/99. Merci.

Pour une configuration générique, assez simple, RiC-O 1.0, je pense qu'on peut se passer de tout ça, et utiliser seulement les raccourcis (qui sont tous instanciés dans les deux jeux de données) et, en point d'entrée, au moins une classe de Relation directement (je pense à AgentToAgentRelation, pour les relations entre agents). On pourra aussi se servir du fait que dans RiC-O 1.0, il y a maintenant des relations transitives (comme includesTransitive, et aussi precedesInTime).

Par contre pour nos vrais gros jeux de données, comme celui du démonstrateur Sparnatural des AN, lorsqu'on va passer à RiC-0 1.0 on infèrera les propriétés de rolification pour pouvoir ensuite faire tout ce qu'on veut.