assemblee-virtuelle
Pouvoir créer des relations réifiées
Description Pouvoir créer des relation réifiées (relations Person-Organization ou Agent-Activité par exemple)
Issues liées
- [x] Composant React-Admin pour éditer les relations réifiées #551
- [ ] Ajouter une relation réifiée via une modale #552
- [x] Générer la relation inverse pour les relations réifiées #553
Estimation du temps de travail en JH
- @srosset81:
- @simonLouvet:
J'aurai besoin d'un petit temps pour bien comprendre le besoin et les enjeux derrière ce sujet. (pour le moment je comprends, mais c'est vague dans ma tête)
J'ai créé des issues pour chaque point du chantier et j'ai modifié la description de ce chantier en concordance.
@simonLouvet @tfrancart Petite interrogation suite à une discussion avec Niko ce matin:
Est-ce que dans l'ontologie PAIR, un rôle peut être utilisé pour plusieurs organisations ou est-ce qu'il est spécifique à une organisation ?
Plus précisément, est-ce qu'on va avoir un rôle "Administrateur de l'organisation Assemblée Virtuelle" (avec un URI de type /organisations/assemblee-virtuelle/roles/admin) ou un rôle "Administrateur" (avec un URI /roles/admin) qui peut-être utilisé par plusieurs organisations ?
Le premier cas semble plus commode, on pourrait ainsi définir facilement des groupes, qui pourraient être utilisé notamment pour les groupes webACL.
J'imaginais plutôt la seconde solution. Dans l'idée les rôles possibles seraient fournis dans un référentiel contrôlé type SKOS. Qui pourrait être adapté/étendu pour un déploiement spécifique, mais qui resterait une liste générique. L'ensemble de "tous les administrateurs de l'assemblée virtuelle" doit donc se définir par croisement d'un rôle générique "Administrateur" et de l'organisation spécifique "Assemblée Virtuelle". Ca doit être jouable, non ?
Le jeu. 4 févr. 2021 à 18:13, Sébastien Rosset [email protected] a écrit :
@simonLouvet https://github.com/simonLouvet @tfrancart https://github.com/tfrancart Petite interrogation suite à une discussion avec Niko ce matin: Est-ce que dans l'ontologie PAIR, un rôle peut être utilisé pour plusieurs organisations ou est-ce qu'il est spécifique à une organisation ? Plus précisément, est-ce qu'on va avoir un rôle "Administrateur de l'organisation Assemblée Virtuelle" (avec un URI de type /organisations/assemblee-virtuelle/roles/admin) ou un rôle "Administrateur" (avec un URI /roles/admin) qui peut-être utilisé par plusieurs organisations ? Le premier cas semble plus commode, on pourrait ainsi définir facilement des groupes, qui pourraient être utilisé notamment pour les groupes webACL https://github.com/assemblee-virtuelle/semapps/issues/575.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/526#issuecomment-773468150, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU2H4KZI7EFC56IX3XPV5DS5LIUVANCNFSM4WOTTRPQ .
--
Thomas Francart -* SPARNA* Web de données | Architecture de l'information | Accès aux connaissances blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas
plusieurs organisations ou est
Les 2 sont possible
@simonLouvet @tfrancart Petite interrogation suite à une discussion avec Niko ce matin: Est-ce que dans l'ontologie PAIR, un rôle peut être utilisé pour plusieurs organisations ou est-ce qu'il est spécifique à une organisation ? Plus précisément, est-ce qu'on va avoir un rôle "Administrateur de l'organisation Assemblée Virtuelle" (avec un URI de type
/organisations/assemblee-virtuelle/roles/admin) ou un rôle "Administrateur" (avec un URI/roles/admin) qui peut-être utilisé par plusieurs organisations ? Le premier cas semble plus commode, on pourrait ainsi définir facilement des groupes, qui pourraient être utilisé notamment pour les groupes webACL.
Les 2 sont possibles sémantiquement. Cependant, circonstancier des rôles à des organisations nécessiterait un prédicat "rôle" entre Les classes d'Organization et de Role ce qui n'est pas actuellement le cas dans PAIR. Cela voudrait également dire que nous gérons les container imbriqué /organisations/assemblee-virtuelle/roles ce qui n'est pas le cas pour le moment.
Pour Passerelle Normandie, les rôles devraient être génériques avec un container classique.
@simonLouvet @tfrancart Après réflexion, ce que vous proposez ne semble pas pouvoir marcher. Imaginez que l'objectif soit de cartographier "Guillaume est administrateur de l'AV" et "Thomas est administrateur de Sparna". On aurait donc plus ou moins ces triplets:
</users/guillaume> pair:membershipActor </roles/admin>
</users/thomas> pair:membershipActor </roles/admin>
</roles/admin> pair:organizationOfMembership </organizations/virtual-assembly>
</roles/admin> pair:organizationOfMembership </organizations/sparna>
Mais il y aurait aucun moyen de savoir, à partir de ces triplets, de quelle organisation Guillaume et Thomas sont les administrateurs.
Et donc pour répondre à l'interrogation de Thomas:
L'ensemble de "tous les administrateurs de l'assemblée virtuelle" doit donc se définir par croisement d'un rôle générique "Administrateur" et de l'organisation spécifique "Assemblée Virtuelle". Ca doit être jouable, non ?
Ce serait jouable uniquement si on utilisait du RDF*. Les triplets ne peuvent pas contenir une double relation.
Donc il me semble que le seul moyen de s'en sortir est d'avoir des rôles spécifiques pour chaque organisation, c'est-à-dire des rôles "Administrateur de l'AV" ou "Administrateur de Sparna" (quel que soit l'URI choisi, là n'est pas la question).
Et au final, ces "rôles" ne sont pas très différents de sous-groupes. Je trouve d'ailleurs que la terminologie utilisée pour les prédicats est très compliquée. Ne pourrait-on pas avoir quelque chose de plus simple, du type hasRole, isRoleOf, etc. ? Sans différencier les "membership role" et les "involvement role". Et peut-être permettre aussi une relation simple type isMember, qui est quand même pratique quand on veut juste notifier l'appartenance d'une personne à un groupe, sans avoir à ajouter un sous-groupe (p.ex. /roles/virtual-assembly-members) juste pour ça ?
Ping @GuillaumeAV
Le ven. 5 févr. 2021 à 09:19, Sébastien Rosset [email protected] a écrit :
@simonLouvet https://github.com/simonLouvet @tfrancart https://github.com/tfrancart Après réflexion, ce que vous proposez ne semble pas pouvoir marcher. Imaginez que l'objectif soit de cartographier "Guillaume est administrateur de l'AV" et "Thomas est administrateur de Sparna". On aurait donc ces triplets:
</users/guillaume> pair:membershipActor </roles/admin>
</users/thomas> pair:membershipActor </roles/admin>
</roles/admin> pair:organizationOfMembership </organizations/virtual-assembly>
</roles/admin>pair:organizationOfMembership </organizations/sparna>
Non, c'est faux. On aurait la structure en étoile suivante :
</users/guillaume/membership1> a pair:MembershipAssociation . </users/guillaume/membership1> pair:membershipActor </users/guillaume> . </users/guillaume/membership1> pair:membershipRole </roles/admin> . </users/guillaume/membership1> pair:membershipOrganization </organizations/virtual-assembly> .
Mais il y aurait aucun moyen de savoir, à partir de ces triplets, de quel organisation Guillaume et Thomas sont les administrateurs.
Et donc pour répondre à l'interrogation de Thomas:
L'ensemble de "tous les administrateurs de l'assemblée virtuelle" doit donc se définir par croisement d'un rôle générique "Administrateur" et de l'organisation spécifique "Assemblée Virtuelle". Ca doit être jouable, non ?
C'est jouable si on utilise du RDF*. Les triplets ne peuvent pas contenir une double relation.
Donc il me semble que le seul moyen de s'en sortir est d'avoir des rôles spécifiques pour chaque organisation, c'est-à-dire des rôles "Administrateur de l'AV" ou "Administrateur de Sparna" (quel que soit l'URI choisi, là n'est pas la question).
Et au final, ces "rôles" ne sont pas très différents de sous-groupes. Je trouve d'ailleurs que la terminologie utilisée pour les prédicats est très compliquée.
Ne pourrait-on pas avoir quelque chose de plus simple, du type hasRole,
isRoleOf, etc. ?
Pas vraiment, cf. la structure en étoile ci-dessus. Le rôle est attaché au membership, pas à la personne.
Sans différencier les "membership role" et les "involvement role".
Non, car involvment va vers les Activity, et membership vers les Organizations.
Et peut-être permettre aussi une relation simple type isMember, qui est quand même pratique quand on veut juste notifier l'appartenance d'une personne à un groupe, sans avoir à ajouter un sous-groupe (p.ex. /roles/virtual-assembly-members) juste pour ça ?
Cette relation existe, c'est affiliates / affiliatedBy. OK, la différence de nommage n'est pas très heureuse ici.
Thomas
Ping @GuillaumeAV https://github.com/GuillaumeAV
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/526#issuecomment-773874391, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU2H4M25SMIZUIOTJ6ULNDS5OS2ZANCNFSM4WOTTRPQ .
--
Thomas Francart -* SPARNA* Web de données | Architecture de l'information | Accès aux connaissances blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas
Merci pour les précisions Thomas. C'est plus évident avec un exemple ! Je continue à trouver que c'est compliqué tout ça, mais bon, c'est les choix que vous avez fait, on va essayer de s'y adapter. :+1: Pour respecter les normes des webACL, on n'aura cependant pas d'autres choix que de créer des groupes, générés automatiquement à partir de ces données "en étoile". Du coup on aura potentiellement des groupes "administrateurs de l'AV", "administrateurs de Sparna", avec leur propres URIs.
Cela dit, certaines instances pourraient aussi faire le choix de ne pas utiliser les rôles et de se contenter de créer des pair:Group qui sont pair:partOf des organisations.
Le ven. 5 févr. 2021 à 10:02, Sébastien Rosset [email protected] a écrit :
Merci pour les précisions Thomas. C'est plus évident avec un exemple ! Je continue à trouver que c'est compliqué tout ça, mais bon, c'est les choix que vous avez fait, on va essayer de s'y adapter. 👍
Le besoin métier était de pouvoir exprimer le rôle de la personne dans une organisation ou une actitivté. L'ontologie ORG propose ce modèle de Membership (https://www.w3.org/TR/vocab-org/).
Pour respecter les normes des webACL, on n'aura cependant pas d'autres choix que de créer des groupes, générés automatiquement à partir de ces données "en étoile". Du coup on aura potentiellement des groupes "administrateurs de l'AV", "administrateurs de Sparna", avec leur propres URIs.
Oui, c'est une bonne chose. Instinctivement je me dis que c'est une bonne chose de dériver et séparer les groupes d'utilisateurs à partir du graphe de connaissance métier.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/526#issuecomment-773895881, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU2H4OFGXL7VTKCOCGE4KLS5OX2RANCNFSM4WOTTRPQ .
--
Thomas Francart -* SPARNA* Web de données | Architecture de l'information | Accès aux connaissances blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas
Vous allez plus vite que moi; j'ai pas le temps de répondre mais je voie que la discussion va dans le bon sens :-). Merci @tfrancart pour ta réactivité et @srosset81 de challenger et de faire progresser la réflexion.
Il faut certainement qu'il y ait une solution de modélisation qui ne passe pas par les associations de Membership. Je ne sais pas si ca se ferait via Group et partOf, cependant. Group a plutôt un sens de "sous-organisation", alors qu'un ensemble d'administrateurs par exemple est plutôt une notion transverse au découpage fonctionnel d'une organisation. ORG là-aussi propose une variante de modélisation : le Poste. Une organisation propose des Postes (qui sont les fonctions dans l'organigramme) et les personnes occupent des Postes; ca me semblerait plus proche de la situation recherchée.
Le ven. 5 févr. 2021 à 10:13, Sébastien Rosset [email protected] a écrit :
Cela dit, certaines instances pourraient aussi faire le choix de ne pas utiliser les rôles et de se contenter de créer des pair:Group qui sont pair:partOf des organisations.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/semapps/issues/526#issuecomment-773902053, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU2H4I4X2KZIQH3NHY3B6DS5OZEDANCNFSM4WOTTRPQ .
--
Thomas Francart -* SPARNA* Web de données | Architecture de l'information | Accès aux connaissances blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas