Restrictions sur vivofr:Fonction

[ghost]

Objection reportée par @HueyNemud

Une vivofr:Fonction décrit la relation entre une personne (foaf:Person) et une organisation (foaf:Organization)

Or là avec les restrictions

      rdfs:subClassOf [
          a owl:Restriction ;
          owl:onProperty vivo:relates ;
          owl:someValuesFrom foaf:Person ;
        ] ;
      rdfs:subClassOf [
          a owl:Restriction ;
          owl:onProperty vivo:relates ;
          owl:someValuesFrom foaf:Organization ;
        ] ;

je peux très bien avoir quelque chose comme :

unefonction a vivofr:Fonction
cbrando a foaf:Person
ehess a foaf:Organization
photodechaton a foaf:Image

unefonction vivo:relates cbrando # fonction -> personne, 1ere restriction OK
unefonction vivo:relates ehess # fonction -> organisation, 2ere restriction OK
unefonction vivo:relates photodechaton # c'est valide car les restrictions someValuesFrom restent vraies

Question : est-ce voulu ?

Ou bien est-ce que la restriction devrait plutôt être quelque chose du genre :

  rdfs:subClassOf [
      a owl:Restriction ;
      owl:onProperty vivo:relates ;
      owl:allValuesFrom [ a owl:Class ;
                                       owl:unionOf ( foaf:Organization
                                                             foaf:Person
                                                            )
                                    ]
    ] ;

[ghost]

Par la même occasion il faudrait préciser sur fonction et appartenance ne relient pas l'individu au même type d'organisation.

• Une fonction relie une personne à une organisation dotée de la personnalité juridique : une entreprise (vivo:Company), une administration (notamment une université, vivo:University, mais aussi vivo:Hospital), ou une institution sans but lucratif au service des ménages, au sens de l'INSEE : parti politique, Église, associations diverses et variées (vivo:Association). Il s'agit, dans le cas général, de l'employeur mais on peut avoir des fonctions bénévoles. Par extension de sens, certaines relations marchandes (prestations) peuvent être considérées comme des fonctions.
• Une appartenance relie une personne à une entité qui constitue une subdivision interne des organisations décrites au point précédent : entité administrative (vivofr:ORG_0000014) ou structure de recherche (vivofr:ORG_0000002)

@dsi-ehess/vivo-ehess-2-team

[HueyNemud]

Une remarque sur ma remarque : la phrase " c'est valide car les restrictions someValuesFrom restent vraies" n'est pas très correcte. Une restriction OWL de type "subClassOf" est une condition nécessaire (mais pas suffisante) d'appartenance à la classe sur laquelle est définie la restriction. Seul un raisonneur saura l'utiliser pour vérifier la cohérence de l'ontologie.

J'ai voulu tester le comportement de raisonneur HermiT inclus dans Protégé avec les deux solutions sur l'exemple suivant :

unefonction a vivofr:Fonction;
undocument a foaf:Document;
unefonction relates uneressource;

avec foaf:Document qui a la particularité d'être définit disjoint de foaf:Organization et foaf:Project

1. Avec 2 restrictions someValuesFromdéfinies sur vivofr:relates Aucune incohérence détectée par le raisonneur. Nous sommes en monde ouvert et comme foaf:Document n'est pas explicitement déclaré disjoint de foaf:Person, les deux axiomes restrictifs sont bien valides pour le triplet unefonction relates uneressource; (i.e. il est possible que undocument soit défini ailleurs comme étant aussi une instance de foaf:Person, ce qui serait toujours cohérent dans notre ontologie, bien que ce soit -pour un humain- un peu contre-intuitif).

2. Avec 2 restrictions someValuesFromdéfinies sur vivofr:relates et l'ajout d'un axiome owl:disjointWith foaf:Person sur foaf:Document. Toujours aucune incohérence détectée par le raisonneur. C'est bizarre, ce n'est pas le comportement que j'attendais puisque cette fois les deux restrictions devraient être invalides : undocument ne peut être ni un foaf:Person, ni une foaf:Organization... Note : Oui c'est du hacking d'ontologie cracra mais c'est seulement pour l'exemple 😬

3. Avec une seule restriction someValuesFrom définie sur l'union des classes foaf:Person et foaf:Organization Aucune incohérence détectée par le raisonneur. C'est normal, on est dans le même cas qu'en point 1.

4. Avec une seule restriction someValuesFrom définie sur l'union des classes foaf:Person et foaf:Organization et l'ajout d'un axiome owl:disjointWith foaf:Person sur foaf:Document. Cette fois le raisonneur détecte une incohérence. C'est le comportement attendu, tout va bien.

D'autre part, cette seule restriction ne suffit pas à décrire qu'une vivofr:Fonction lie une foaf:Person à une foaf:Organization. Pour ce faire on peut ajouter des contraintes de cardinalité qualifiées à la classe vivofr:Fonction, du genre :

[ rdfsyn:type owl:Restriction ;
  owl:onProperty vivo:relates ;
  owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
  owl:onClass foaf:Organization
] ,
[ rdfsyn:type owl:Restriction ;
  owl:onProperty vivo:relates ;
  owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
  owl:onClass foaf:Person
],

Ainsi, on a trois conditions nécessaires (mais pas suffisantes) pour qu'une ressource R soit une vivofr:Fonction :

• qu'il existe un seule triplet R vivofr:relates P avec P a foaf:Person
• qu'il existe un seule triplet R vivofr:relates O avec O a foaf:Organization
• que pour tout triplet R vivofr:relates X, X soit soit une instance de foaf:Person, soit de foaf:Organization

Graphiquement :

Conclusion

• les restrictions OWL ont vocation à être utilisées avec un raisonneur.
• Avoir un unique triplet fonction vivofr:relates X ne sera détecté comme incohérence qu'à l'unique condition que X ne soit ni une instance de foaf:Person, ni une instance de foaf:Organization et que la classe de X soit explicitement disjointe de foaf:Person et foaf:Organization (ou de leurs superclasses).
• avec la situation actuelle le raisonneur HermiT ne détecte aucune incohérence dans l'ontologie, même dans une situation où on s'attendrait à cela (cf. point 2). Je ne m'en explique pas la raison, il doit y avoir une finesse logique qui m'échappe...
• avec une restriction sur une union de classes, on obtient le comportement attendu de la part du raisonneur.
• il faut ajouter des contraintes de cardinalité qualifiées pour obtenir ce qui devait être -me semble t-il- exprimé à la base, c'est à dire qu'une Fonction lie une Personne à une Organisation.

[cvbrandoe]

Sauf erreur de ma part Vivo n'intègre pas de moteur de raisonnement OWL, Joachim et Michel peuvent confirmer ? Joachim genere de triples 'inferred' via Sangam, non ? Dans le sens de la suggestion de Bertrand, ça serait possible d'intégrer HermiT via l'OWL API pour générer de manière correcte ces triples en accord avec les restrictions corrigées par Bertrand, qu'en pensez vous ?

[HueyNemud]

@cvbrandoe Je ne sais pas quels mécanismes intègre Vivo et quels triplets vous souhaitez générer, mais il me semble que des restrictions sur des sous-classes vont permettre à un raisonneur uniquement de faire de la vérification de cohérence, pas vraiment d'inférer de nouvelles connaissances ?

Pour inférer de nouvelles connaissances il faudrait utiliser des axiomes EquivalentClass plutot que SubClassOf, mais les implications ne sont plus les mêmes. En l'occurence, le raisonneur infèrera que toute ressource avec exactement 2 relations vivofr:relates avec une foaf:Person et avec une foaf:Organization est une instance de la classe vivofr:Fonction.

[ghost]

@cvbrandoe Je ne génère pas les triples 'inferred' depuis Sangam : ils apparaissent bien spontanément dans Vivo. Malheureusement, nous n'avons pas réussi à faire inférer les types de personnes, cf. issue https://github.com/dsi-ehess/VIVO-EHESS/issues/2#issue-731178018. Donc ces types sont 'asserted'. Soit c'est une erreur dans la première mouture de l'ontologie Vivo, soit c'est la limite du raisonneur de Vivo, ce qui nous a amené à opter pour un vrai triple store pour la phase 2.

[michel-heon]

@j-dornbusch @cvbrandoe @HueyNemud @cvbrandoe , Au sujet du raisonneur dans VIVO, voici la doc. qui y fait référence. https://wiki.lyrasis.org/display/VIVODOC111x/Inferences+and+Indexing. Connaissant les gens de Lyrasys, il y a fort à parier qu'il s'agit du raisonneur de Jena, Je vais quand même poster un billet dans la canal des développeurs pour en savoir plus. Je vous reviens là-dessus sous peu.

Au sujet de la classe et des sous classes de 'Fonction' Voici un scénario de jeux de données indiquant une-Personne qui est un ingénieur.e d'études

:une-Personne
  rdf:type vivofr:FNC_0000015 ;
  rdf:type foaf:Person ;
  rdfs:label "une Personne" .

pour vivofr:FNC_0000015 qui est une 'ingénieur.e d'études

Après inférence (voir ci-dessous) on obtient que l'Individu est classifié sous vivo:Position

:une-Personne
  rdf:type vivofr:FNC_0000015 ;
  rdf:type vivo:Position ;
  rdf:type foaf:Person ;
  rdfs:label "une Personne" .

Remaques:

1. La classification sous vivo:Position vient de la déclaration qu'une vivo:Position est une equivalentClassOf vivofr:FNC_0000001 (Fonction)
2. Sémantiquement cela revient à dire qu'une personne c'est une fonction (Ce qui est un non sens, un personne ne peux pas être une fonction). alors que ce que l'on souhaites exprimer c'est plustot une 'relation de fonction' entre un individu et la fonction qu'il(elle) occupe (Pierre a pour fonction d'être ingénieur).
3. ainsi, en lien avec 2. il me semble qu'au lieu d'écrire :une-Personne rdf:type vivofr:FNC_0000015. il serait plus judicieux d'écrire en énoncé du style :une-Personne accupeLaFonctionDe vivofr:FNC_0000015
4. La conséquence de 3. c'est que vivofr:FNC_0000015 n'est pas une classe, mais un individu de vivofr:FNC_0000001. C'est en effet logique puisqu'il y a conceptuellement un changement de niveau d'abstraction entre le concept de "ingénieur.e d'études"et le concept de "Fonction", et en ce sens, il est plus approprié d'utiliser le rdf:type plustôt que le rdfs:subClassOf entre Fonction et "ingénieur.e d'études".