Chantier de mise à jour des ontologies PAIR, CdlT, Places de marché etc!

[guillaume.rouyer]

Salut tout le monde !

Du côté des Chemins de la Transition on amorce avec @daemu un travail de mise à jour de notre ontologie, laquelle est basée à 90% sur pair.

Ce travail sera également l’occasion de proposer des ajouts et des évolutions pour PAIR.
Première réunion cette après midi (vendredi 29/09) qui sera suivie de nombreuses autres. (Si vous êtes intéressés et que vous souhaitez contribuer faites signe !)

@thomas.francart, tu avais réalisé un export csv de l’ontologie pair, qui est super pour travailler de manière collaborative… J’ai essayé d’exporter l’ontologie CdlT avec Protege, mais le résultat n’est vraiment pas satisfaisant, à moins que je m’y sois mal pris ?

Tu pourrais nous aider ou nous dire le logiciel et/ou la méthode utiliisée ?

Merci par avance !

[thomas.francart]

C’était des requêtes SPARQL d’export qui sont ici : https://github.com/assemblee-virtuelle/pair/tree/master/3-Dissemination (2 fichiers .rq). C’était pour travailler sur les traductions, il n’y a pas toute l’ontologie.

Maintenant nous travaillons beaucoup les modélisations dans des tableaux Excel qui encodent du SHACL comme celui-là : https://skos-play.sparna.fr/play/excel_test/excel2skos-use-case-3.xlsx

[srosset]

Super !

Je n’aurai pas beaucoup d’énergie pour vous accompagner là-dessus, mais n’oubliez pas Destination Oasis. Pour le moment les offres d’hébergement sont des cdlt:HostingServices, mais ça pourrait devenir de simple « offres », ce qui pourrait permettre de les afficher sur la future « place du marché » des CDLT.

Voilà à quoi ressemblent les services pour le moment:

https://data.cooperative-oasis.org/services

Les lieux eux-mêmes sont de simple pair:Place avec quelques prédicats spécifiques aux CDLT:

https://data.cooperative-oasis.org/places

Si une nouvelle ontologie est disponible et qu’elle peut permettre de faire apparaître les offres d’hébergement sur le site des CDLT, je pourrai m’occuper de la migration côté Oasis, puis de la synchronisation avec CDLT.

[guillaume.rouyer]

Salut tout le monde !

Je ne sais pas ce qui m’a pris, en cette fin d’année je me suis offert le luxe de me replonger dans l’ontologie PAIR et me suis amusé à faire une « vue d’artiste » (simplifiée) d’une version sensiblement modifiée sur Canva (plus facile à manipuler que Yed !)

Fichier source ici

Joyeux noël à tou.te.s !

[fluidlog]

L’année dernière, j’avais commencé aussi un schéma simplifié de l’ontologie PAIR pour le projet Low-tech Lab qui l’utilise (voir [Archipel du Low-tech Lab] Archipelago pour cartographier les communautés du Low-tech Lab en France - Projets / SemApps - Assemblée Virtuelle).

L’objectif était de cacher un peu les classes intermédiaires (Agent, Actor, Activity, Resource), pour que les utilisateurs comprennent mieux les relations qu’ils voient dans Archipelago, et d’expliquer la notion de Rôles et de relations réifiées.

Ca donnait quelque chose comme ça :

En lien avec la dernière version de PAIR de 2021.

Depuis cette année, j’utilise de nouveau PAIR (au lieu d’HeCo, ontologie créée pour Carto4CH, mais qui était trop complexe à maintenir) pour cartographier l’écosystème du projet ECHOES dans le domaine du patrimoine culturel (voir Carto ECHOES - Projets / SemApps - Assemblée Virtuelle).

Je vais donc continuer ces schémas pour mieux expliquer l’ontologie.

Et là, en me concentrant sur chaque relation, je commence à voir des petits trucs qui me questionnent.

Par exemple :

• Pourquoi dans l’Archipelago de l’AV, nous faisons un lien entre Person -hasTopic-> Topic, mais dans l’ontologie (tout du moins dans cette version de PAIR, je lis que les Topic ne sont liés qu’à des documents. Je pense que nous avons devancé le code avant de mettre à jour PAIR, ou alors il y a une autre version dans les tuyaux.

On voit dans le schéma que les Topic peuvent être lié aussi à des agents (avec hasTopic au lieu de hasInterest).

Je préfère en parler avec vous avant d’implémenter ces relations dans mon projet.

Autre besoin :
J’ai besoin de référencer des outils.
Après discussion avec Béatrice, je les placerais bien dans les ressources, au même titre que les documents et les skills, avec la possibilité de les relier avec :

• des acteurs (ex : person -uses-> tool)
• des activités (ex : project -produces-> Tool)
• en plus des objets (documents)

En gros, j’aimerais bien faire ça :

On a aussi détecté dans le schéma des choses en franglais

A-t-on encore facilement moyen de mettre à jour ce schéma ? (cf. outil graphique de Bernard Chabot ?).

Vu que cela entre dans mon projet ECHOES, je peux prendre le temps de faire une visio pour en parler, voir carrément mettre à jour une belle version 2025 corrigeant juste des coquilles (s’il y en a) et en ajoutant les Tools.
De plus, cela aurait le meilleur effet avant mon intervention au SemWebPro fin novembre.

Qu’en pensez-vous @guillaume.rouyer @thomas.francart @simon.louvet.zen @srosset ?

Je vous propose une petite visio pour en parler la semaine prochaine, disons mercredi 1er octobre à 11h ?

[thomas.francart]

Dire qu’une Personne possède un Sujet n’a pas de sens. Mais dire qu’une Personne s’intéresse à un sujet, oui. Donc c’est Person – hasInterest → Topic, mais pas hasTopic.

J’ai le même besoin de décrire des Outils, et oui ce sont bien des ressources, plus précisément des « Bit-based ressources ». J’ai besoin également de décrire : des Modèles (d’ontologie), qui sont des Documents+Resources et des Protocoles (idem).

L’outil de mise à jour du diagramme est Yed: yEd - Download.

Tes schemas sont super, on peut en parler. Je suis dispo le 7/10 à 11h ou bien on en parle quand tu viens le 7.

[simon.louvet.zen]

Dans Archipelago, je pense que nous avons utilisé Person - hasTopic-> Topic sans que ce soit implémenté dans l’ontologie pour aller plus vite et Thomas as raisons pour Person – hasInterest → Topic.
Les réactions inverses fonctionnent, car l’algo qui créé les relations inverses ne se préocupe pas du domaine d’application des relations.

[fluidlog]

Merci pour vos réponses.
Ok @thomas.francart pour en reparler le 7 à Tours (un sujet de plus…).
@simon.louvet.zen, en effet, actuellement, nous utilisons « hasTopic » dans la plupart des projets Archipelago…

On le voit facilement ici :
data.virtual-assembly.org/users

Ce que tu veux dire, c’est que si je change « hasTopic » en « hasInterest », entre les agents et les Topic (pour respecter l’ontologie actuelle), alors les relations inverses seront aussi mises à jour. Mais le problème est que dans l’ontologie, il n’y a pas de relation inverse à « hasInterest » :

Que diriez-vous d’ajouter « Topic » -interested-> « Agent » ? et de l’affecter comme relation inverse ?
PS : je viens de lire certaines issues relatives aux topic ou aux ressources :

• Supprimer des relations inverses · Issue #173 · assemblee-virtuelle/pair
• Clarifier hasTopic qui a pour domain (Object or Subject) · Issue #182 · assemblee-virtuelle/pair
• Refactorer les sous-classes de ressources · Issue #164 · assemblee-virtuelle/pair

Concernant les Tools et les Topic, peut-on imaginer de mettre des liens Resource <> Topic ? Car je trouverais intéressant pour nos futurs tools (bit based resource) d’être reliés avec des Topic, mais dans le cas d’un skill, je trouve ça un peu trop tiré par les cheveux…

Concernant Yed, je vais essayer de l’installer et de voir si je peux reprendre les schémas.

J’ai envoyé un message à @guillaume.rouyer pour avoir son avis. On verra si on fait une visio avant le 7.

[fluidlog]

@guillaume.rouyer est OK pour faire une visio demain a 11h, nous allons débroussailler le sujet déjà à deux, mais vous pouvez vous greffer sans problème :

Jitsi Meet

J’ai commencé à lire les issues ouvertes, et je vais en ajouter pour que ce que nous disons ici soit présent au bon endroit :

• Ajouter une relation inverse à pair:hasInterest entre Agent et Topic · Issue #194 · assemblee-virtuelle/pair
• Ajouter la notion d’outil (tool) dans les ressources (resource) · Issue #195 · assemblee-virtuelle/pair
• Mettre à jour le schéma de l’ontologie PAIR pour tout écrire en anglais et y ajouter les tools · Issue #196 · assemblee-virtuelle/pair

[thomas.francart]

@fluidlog

Que diriez-vous d’ajouter « Topic » -interested-> « Agent » ? et de l’affecter comme relation inverse ?

Oui ! plutôt « isInterestOf » pour respecter les conventions de nommage

Concernant les Tools et les Topic, peut-on imaginer de mettre des liens Resource <> Topic ?

Il y a hasSubjectType qui pointe vers un ResourceType. C’est un « typage faible ». Est-ce que ca suffirait ? On avait d’ailleurs trouvé une chouette taxonomie des types d’outils : Sparna's tools in Semantic Web Tool Hub

[fluidlog]

Pouvez-vous me dire où sont les fichiers originaux du schéma PAIR créé sous Yed ?
J’ai trouvé des fichiers au format graphml, mais ils ne s’ouvrent pas dans la dernière version de Yed que je viens d’installer.
pair/3-Dissemination/Diagrammes-PAIR-Winter-2020 at 5e8e5365a1446cc440e3e41651959cb3da0fdb39 · assemblee-virtuelle/pair

Et pour la dernière version, il n’y a que le png :
pair/3-Dissemination/Diagrammes-PAIR-Summer-2021 at 5e8e5365a1446cc440e3e41651959cb3da0fdb39 · assemblee-virtuelle/pair
Merci,

[fluidlog]

Pour celleux qui le souhaitent, la visio commence ici : Jitsi Meet

[fluidlog]

Hello,
3 mois plus tard… mais que s’est-il passé entre temps !?
En résumé, la réunion en octobre n’a pas eu lieu, j’ai eu Guillaume au téléphone rapidement et il a retrouvé le dernier fichier Yed original : PAIR_Core_Subjects.graphml

Il s’ouvre correctement dans Yed (contrairement à d’autres fichiers *.graphml plus anciens…).

Je l’ai mis au chaud à l’instant dans le projet github de PAIR :
pair/3-Dissemination/Diagrammes-PAIR-Summer-2021 at master · assemblee-virtuelle/pair

Du côté de @thomas.francart , nous avions une réunion le 7 octobre, mais nous n’avons pas eu le temps de parler de ce sujet, à part le fait que SPARNA a aussi besoin de sémantiser des tools.

Entre temps, d’autres sujets sont passés en priorité, comme le SemWebPro, ou l’étude de différents portails…

En tous cas, je me remets dessus en ce début d’année, je vais commencer par refaire une nouvelle version du schéma sous Yed, et ensuite la mise à jour d’un nouveau fichier owl, et donc, d’une nouvelle version de PAIR 2026 !

Je noterai tout ce que je fais dans ce PAD :
Ajout des tools dans l’ontologie PAIR - HedgeDoc

Et le détail des opérations sera dans les issues créées en octobre (voir au dessus).
N’hésitez pas à intervenir et à donner votre avis

Yannick

[fluidlog]

Voici une nouvelle version du schéma PAIR modifié sous Yed, si personne ne s’oppose, je la publierai sur le github de l’AV vendredi 09/01.

Le détail des modifications est sur le PAD :

Ajout des tools dans l'ontologie PAIR - HedgeDoc

Merci,

Yannick

[srosset]

C’est bizarre, quand tu parlais d’outils je pensais qu’il s’agissait d’objets physiques. D’ailleurs en regardant la définition en anglais, il semble que le mot « tool » plutôt référence à un objet physique (en tout cas la première définition).

tool

Même chose que le mot « outil » en français au fond… Pourquoi n’avoir pas utilisé le terme plus générique de « software » ?

[fluidlog]

En effet, nous avons fait un point avec @thomas.francart à ce sujet, et voici un CR.

Les besoins :

1. Dans Echoes, nous avons besoin de référencer des outils à la fois physiques et logiciels / bit-based resource (BBR) du patrimoine culturel, et de pouvoir les associer à des projets ou à des personnes.

Cas d’usage :

• une pelle pour un archéologue qui fait des fouilles, ou un scanner 3D, qui est un outil « physique », qui créer des données logicielles
• OpenRefine comme exemple de BBR, pour un développeur qui va sémantiser des données du patrimoine

2. Un autre besoin est de pouvoir filtrer une liste de BBR avec une taxonomie liée aux logiciels sémantiques. Par exemple, pouvoir différencier un thésaurus d’une ontologie.

Classe ou prédicat ?
J’étais donc parti pour ajouter une classe « tool » (un peu comme nous l’avons fait pour skill), mais suite à l’échange avec Thomas, il trouve plus logique d’utiliser le prédicat « uses » pour dire qu’on utilise une ressource. Et je suis d’accord avec cela, je n’avais pas vu ça sous cet angle.

Donc, dans l’état, PAIR répond au besoin, car il propose déjà le prédicat « uses » entre Agent et Resource.

En revanche, cela pose question de la manière de les lister dans un Archipelago, qui se base sur la classe… Ca, c’est un autre débat que nous pourrons avoir dans un second temps…

Autre remarque qui en découle sur les compétences :
Si on utilise le prédicat « uses » pour les outils, pourquoi ne pas revoir aussi notre copie pour les compétences ? En utilisant juste un prédicat (à trouver), qui peut se relier à des projets, à des logiciels… Par exemple Person → offers → Project ou Person → offers → Bit-based Resource.

Classification de BBR
Et pour le deuxième besoin de catégoriser des « bit-based resources », on pourrait en effet ajouter une sous-classe « Sofware » comme @srosset le propose ci-dessus, mais Thomas propose de travailler directement avec la classe « bit-based resources ».

Taxonomie
Thomas va donc essayer d’exporter une taxonomie depuis wikidata, cf semantic-tool-hub/SW-Tool-Hub-data: The Data for the Semantic Tool Hub Application, pour ensuite l’importer dans Archipelago, afin de filtrer les bit-based resources (qui seront majoritairement des software).

[guillaume.rouyer]

Salut tout le monde !

Rien à voir ou presque, je me permets de partager ici le projet Edgy, dont @sachaa est contributeur (il est en charge de sa modélisation sémantique )
qui rejoint plusieurs intentions qui étaient les nôtres quand on a créé PAIR !
Sûr que des discussions et collaborations fécondes pourraient advenir

[thomas.francart]

Voici une query SPARQL permettant d’extraire un SKOS à partir d’une hiérarchie de classes Wikidata. Pour extraire la taxonomie sous « Knowledge Graph Development »:

CONSTRUCT {
  ?scheme a skos:ConceptScheme .
  ?scheme skos:prefLabel "Knowledge graph development activities from Wikidata"@en .
  ?scheme skos:hasTopConcept ?level1 .

  ?level1 a skos:Concept .
  ?level1 skos:prefLabel ?level1Label .
  ?level1 skos:definition ?level1Description .
  ?level1 skos:topConceptOf ?scheme .
  ?level1 skos:inScheme ?scheme .

  ?level2 a skos:Concept .
  ?level2 skos:prefLabel ?level2Label .
  ?level2 skos:definition ?level2Description .
  ?level2 skos:broader ?level1 .  
  ?level2 skos:inScheme ?scheme .

  ?level3 a skos:Concept .
  ?level3 skos:prefLabel ?level3Label .
  ?level3 skos:definition ?level3Description .
  ?level3 skos:broader ?level2 .  
  ?level3 skos:inScheme ?scheme .

  ?level4 a skos:Concept .
  ?level4 skos:prefLabel ?level4Label .
  ?level4 skos:definition ?level4Description .
  ?level4 skos:broader ?level3 .  
  ?level4 skos:inScheme ?scheme .

  ?level5 a skos:Concept .
  ?level5 skos:prefLabel ?level5Label .
  ?level5 skos:definition ?level5Description .
  ?level5 skos:broader ?level4 .  
  ?level5 skos:inScheme ?scheme .
}
WHERE {
  BIND(wd:Q124614077 AS ?root)
  ?level1 wdt:P279 ?root .
  OPTIONAL { 
    ?level2 wdt:P279 ?level1 .
    OPTIONAL { 
      ?level3 wdt:P279 ?level2 .
      OPTIONAL { 
        ?level4 wdt:P279 ?level3 .
        OPTIONAL { 
          ?level5 wdt:P279 ?level4 .
        }
      }
    }
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],mul,en". }
}

Voici également la query pour avoir la représentation visuelle directe de l’arbre, lien direct : https://w.wiki/HSnU

#defaultView:Tree
# Direct URL : https://w.wiki/HSnU
SELECT ?root ?rootLabel ?level1 ?level1Label ?level2 ?level2Label ?level3 ?level3Label ?level4 ?level4Label
WHERE {
  BIND(wd:Q124614077 AS ?root)
  ?level1 wdt:P279 ?root .
  OPTIONAL { 
    ?level2 wdt:P279 ?level1 .
    OPTIONAL { 
      ?level3 wdt:P279 ?level2 .
      OPTIONAL { 
        ?level4 wdt:P279 ?level3 .
        OPTIONAL { 
          ?level5 wdt:P279 ?level4 .
        }
      }
    }
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],mul,en". }
}

[fluidlog]

Merci beaucoup @thomas.francart , je me note de commencer à tester ça dans Archipelago la semaine prochaine (je pense à partir de jeudi 22).

[fluidlog]

Bonjour,
Voici une version 1.1 du schéma de PAIR, avec le post-it remis et traduit et le retrait de la classe tool dans les BBR.

J’ai créé un PAD pour noter les modifications apportées au schéma de PAIR :
Versionning de modification du schéma PAIR - HedgeDoc
Yannick