search

assemblee-virtuelle / semapps

A toolbox to create semantic web applications
https://semapps.org
Apache License 2.0
87 stars 8 forks source link

Réorganiser les données du meetup #335

Closed srosset81 closed 3 years ago

srosset81 commented 4 years ago

Comme les données du meetup sont amené à devenir les données de référence de l'AV, il est utile de penser à une structure de containers cohérente qui aidera les différentes interfaces à se brancher dessus.

Nous avons actuellement 5 types de données:

<http://virtual-assembly.org/ontologies/pair#Person>
<http://virtual-assembly.org/ontologies/pair#Organization>
<http://virtual-assembly.org/ontologies/pair#Project>
<http://virtual-assembly.org/ontologies/pair#Thema>
<http://virtual-assembly.org/ontologies/pair#Skill>

Ma proposition

Ping @simonLouvet @GuillaumeAV @ReX-AV-Gab

simonLouvet commented 4 years ago

ok sur le principe Toutes les classes utilisée sont celle du OWL pour info. 2 sujets à arbitrer pour moi :

srosset81 commented 4 years ago
  • réconciliation des users : je pense qu'il faut dissocier les acteur au sens PAIR des profils utilisateur au sens identification/authentification. Un user authentifier pourrait rapprocher son profil d'un acteur PAIR ou en créer un

Les deux seraient des pair:Person non ? Pour moi ça compliquerait passablement la gestion des données, on repartirait sur une distinction utilisateur / profil qu'on n'avait écarté lors de nos discussions sur WebID. En plus je ne vois pas l'usage: je ne pense pas qu'on aura des personnes qui vont remplir le profil de quelqu'un d'autre (on est pas Wikipedia non plus, l'intérêt est limité...), du coup tous les profils présents seront forcément liés à un utilisateur authentifié.

  • réconciliation des thèmes/skills/tag. ok de pouvoir utiliser les entité de wikidata/dbpedia mais comment ne pas mettre à la poubelle les entités existantes et les liens?

Il suffira de mettre à jour les liens. Et les entités existantes, qui sont juste un simple label, pourront aller à la poubelle effectivement...

simonLouvet commented 4 years ago

Si il y a 2 notions distinct entre le compte de connexion et les Personnes comme donnée de la bdd, je pense qu'il faudra 2 classes distincts mais c'est à réfléchir.

bouviermullerp commented 4 years ago

@simonLouvet this is done, correct ?

simonLouvet commented 4 years ago

non, il s'agit ici de distinguer un container par classe ce qui n'est pas actuellement le cas (mais facile à faire). par contre la discussion à soulevé une discutions sur les users que nous devons arbitrer (développeurs+ designers).

simonLouvet commented 4 years ago
  • Le mot Thema n'existant pas en anglais, je proposerai d'utiliser un container /themes ou /tags (l'idée de tag ayant l'avantage d'être plus ouverte), sachant qu'à terme on se basera sans doute sur DbPedia ou Wikidate pour ces données, et donc qu'on aura pas besoin de les stocker avec notre propre URI.
  • Même remarque DbPedia/Wikidata pour pair#Skill, qu'on peut mettre pour le moment dans un container /skills

J'ai suivi l'ontologie et je pense qu'il ne faut pas s'en éloigner. Si il a des problèmes dans l'ontologie, il me semble qu'il faut corriger l'ontologie et non le logiciel qui doit rester cohérent avec celle-ci.

simonLouvet commented 4 years ago

curl --request GET \ --url http://virtual-assembly.org/ontologies/pair/ \ --header 'accept: application/rdf+xml'

simonLouvet commented 4 years ago

@GuillaumeAV : @srosset81 me dit que tu es au courant et que tu devait corriger la faute d'orthographe sur "Thema". Cela n'est pas encore fait et provoque des tensions entre moi qui dit qu'il faut coller à l'ontologie et @srosset81 qui pense que nous pouvons nous permettre des divergences entre les containers de semapps/coographie. Peux tu corriger l'ontologie pour éviter cela stp.

srosset81 commented 4 years ago

J'ai suivi l'ontologie et je pense qu'il ne faut pas s'en éloigner. Si il a des problèmes dans l'ontologie, il me semble qu'il faut corriger l'ontologie et non le logiciel qui doit rester cohérent avec celle-ci.

Corriger l'ontologie prend du temps... Cela ne justifie pas de garder des fautes d'orthographe comme /themas (ou /persons, que tu as voulu garder) qui ne font pas sérieux auprès des anglophones.

Plus généralement, poser une objection après avoir réalisé une issue n'est pas correct. Cela ne me donne plus envie de mettre par écrit des propositions complètes, puisqu'elles sont ignorées...

bouviermullerp commented 4 years ago

@simonLouvet est-ce que ça te convient si dans l'état, on conserve les propositions de @srosset81 puissqu'elles sont développées et on crée une issue liée pour corriger le problème quand la nouvelle version de l'ontologie sera livrée ? On peut considérer cette issue comme un workaround, le temps que l'ontologie soit livrée, n'est ce pas ? (je ne me rends pas compte de l'impact sur la suite du développement).

D'après ce que je comprends, il y a aussi une tension sur la méthodo ? N'hésitez pas à faire appel au rôle produit et/ou facilitation dans ce cas. Besoin de clarif : tu écris que l'issue est réalisée, mais je la vois toujours dans le backlog.

simonLouvet commented 4 years ago

J'ai suivi l'ontologie et je pense qu'il ne faut pas s'en éloigner. Si il a des problèmes dans l'ontologie, il me semble qu'il faut corriger l'ontologie et non le logiciel qui doit rester cohérent avec celle-ci.

Corriger l'ontologie prend du temps... Cela ne justifie pas de garder des fautes d'orthographe comme /themas (ou /persons, que tu as voulu garder) qui ne font pas sérieux auprès des anglophones.

Plus généralement, poser une objection après avoir réalisé une issue n'est pas correct. Cela ne me donne plus envie de mettre par écrit des propositions complètes, puisqu'elles sont ignorées...

Je suis d'accord que j'aurais du vérifier l'ontologie, exprimer a divergence d'opinion, écrire l'issue, trouver un consensus et développer après. Le probleme c'est que je n'ai pas trouvé le temps de faire cela avant le rdv de startin'blox qui a accéléré les choses, que cela devenait une tache urgente et que je dépile plein de projets avant mes vacances. J'ai donc vérifié l'ontologie au moment de réaliser l'issue et pris le parti de suivre l'ontologie. Je vous présente donc mes excuses pour le manque de rigueur méthodologique. Je considère que cette issue est en review et non terminée. il reste également l'arbitrage sur les pair:person / users à réaliser.

bouviermullerp commented 4 years ago

Le rôle produit suggère qu'on suivre les spécifications, et d'utiliser user - c'est imoortant aussi de faire évoluer l'issue dans le kanban. Le rôle facilitation suggère qu'on prenne le temps de privilégier la méthodo qui permet de prendre soin de notre petit collectif, plutôt que l'urgence de livrer quelque chose. :)

simonLouvet commented 4 years ago

@simonLouvet est-ce que ça te convient si dans l'état, on conserve les propositions de @srosset81 puissqu'elles sont développées et on crée une issue liée pour corriger le problème quand la nouvelle version de l'ontologie sera livrée ? On peut considérer cette issue comme un workaround, le temps que l'ontologie soit livrée, n'est ce pas ? (je ne me rends pas compte de l'impact sur la suite du développement).

Je peux changer les containers (suppression des datas, reconfiguration, redéploiement, réinjection des datas) quand Sébastien me donnera le feux vert (il bosse dessus en ce moment).

Je ne suis pas d'accord mais je ne fait pas objection. Pour information, les changement de nommage de container change également tous les @id des sujets contenus dans ces containers et c'est une opération à risque si on le fait en SPARQL et je préfère donc refaire l'injection de data depuis une base vierge en passant par le bus mais cela implique une indisponibilité de la base qqn minutes. Concernant le container /person, choisir entre /people et /user revient à arbitrer sur la distinction entre user (le user connecté) et people (la base de donnée des personnes) et je suis convaincu que nous devons échanger de vive voie sur ce sujet (ou que je prenne 2h pour mettre sur le papier les avantage/inconvénient de la décision et j'en ai pas vraiment le temps). Je suis donc pour garder /person tant que nous n'avons pas traité ce sujet.

ReX-AV-Gab commented 4 years ago

J'espère qu'un échange de vive voix vous permettra de trouver une solution convenable.

simonLouvet commented 4 years ago

Il y a qqc qui me dérange dans notre méthodo. Dans ma manière de fonctionner, faire une issue ne veut pas dire créer une spécification. Cela veut dire proposer une spécification qui peut être amendé, modifiée, bonifiée, améliorée, refusée, retravaillée.. ou bien sur accepté tel quel. Il me semble que les rôles / Personnes qui valide les issues ne sont pas clairement identifiés. Je pense aux rôle produit, au rôle développement et au role devx mais c'est flou.

ReX-AV-Gab commented 4 years ago

J'ai hâte que l'on puisse aborder ce sujet de vive voix. En l'occurrence, cela pourrait être à l'occasion d'une réunion de gouvernance où il pourrait être question de pilotage et d'une revue des rôles. Je ferai des propositions concrètes au plus tard pour la deuxième réunion sprint à venir.

bouviermullerp commented 4 years ago

Suite au sprint de ce jour, il a été convenu qu'on ne dissociait pas la donnée "utilisateur" de l'utilisateur enregistré et authentifié. C'est une manière simple et agile d'avancer. Le sujet est très complexe et entraine vers considérations qui mériteront certainement d'être exploré par un groupe de travail spécifique.

bouviermullerp commented 4 years ago

lié à #116

srosset81 commented 4 years ago

Suite au sprint de ce jour, il a été convenu qu'on ne dissociait pas la donnée "utilisateur" de l'utilisateur enregistré et authentifié. C'est une manière simple et agile d'avancer. Le sujet est très complexe et entraine vers considérations qui mériteront certainement d'être exploré par un groupe de travail spécifique.

Très bien ! Pour corriger les fautes d'orthographes, il faudrait donc renommer:

Tu pourras t'en occuper @simonLouvet ?

srosset81 commented 3 years ago

Fait