General assembly (Prometheus-X)
General Assembly of Prometheus-X association
Apports de INOKUFU SAS (une fois les financements BPI validés, le calendrier et la licence décidée) :
- Code source des plugins déja développés (Google chrome, Moodle), publié en libre sur le github de Prometheus-X
- Savoir-faire en développement d'architecture microservice et serverless
Inokufu est une jeune entreprise innovante, fondée en 2019. Elle propose un moteur de recherche de learning objects basée sur une technologie d'indexation et d'enrichissement de metadata éducatives. Inokufu propose sa technologie sous différentes formes : en accès API (Learning Object API), extension Chrome, plugin moodle, webapp Becomino, etc
Merci de commenter cette proposition ici, en amont de la réunion. Le vote aura lieu pendant l'AG. Il n'y aura pas de débat pendant l'AG
This proposal has been accepted because:
Related meetings:
General Assembly december 2021
Cette AG a comme but de :
- Présenter les avancées depuis notre dernière AG du 12/10
- Acter les apports en code source des partenaires positionnés dans le dossier sur les services
- Acter les premiers cas d'usage sur lesquels travailler pour les démonstrateurs
- Feuille de route 2022
Différents sujets ont pu être lancés dans la continuation du dépôt de notre projet, qu'on a hâte de vous présenter. Les choses devenant plus concrètes, il est nécessaire de pouvoir valider certaines choses afin d'avancer et maintenir notre avance. Les apports des partenaires vont permettre de montrer des choses concrètes, tout comme les cas d'usage. Il nous faut pouvoir les valider car c'est une condition essentielle de notre projet de garder un bon rythme et de montrer une valeur et une avancée pour notre écosystème. Valider les apports en code et ainsi avoir des premiers éléments d'infrastructure ainsi que les premiers cas d'usage sur lesquels nous allons nous concentrer permettra cela.
Premiers cas d'usage
Dans le dossier BPI nous indiquons travailler sur des cas d'usage précis d'échange de données afin de montrer la valeur de l'infrastructure avec des premiers utilisateurs. Certains cas d'usage se précisent, il est important de les valider pour pouvoir avancer avec ces utilisateurs dans la définition plus précise du cas d'usage et dans l'operationnalisation par les services.
Un premier appel aux soutiens Prometheus-X a été fait, différentes organisations se sont positionnées sur ce document en détaillant les données qu'elles souhaitent mettre à disposition et celle qu'elles souhaitent recevoir. Le 15/11 nous avons fait un atelier et les participants ont précisé par petit groupes des cas d'échanges de données entre eux.
Nous détaillons les participants ainsi que les finalités du cas d'usage afin de pouvoir les montrer comme cas d'usage pilote et avancer dans les discussions. Nous proposons également une méthodologie pour avancer. Ces cas d'usage ne sont que les premiers et ne seront pas les seuls dans le cadre du projet BPI, nous avons cependant besoin de les valider officiellement comme étant ceux qui pourront utiliser les services Prometheus-X dans le cadre du projet BPI.
Les propositions des premiers case d'usage sont consultables ici
Apports des partenaires
Validation des apports du membre positionné sur la brique consentement dans le cadre du projet BPI
Voici les communs à développer dans le cadre du projet BPI qui incluent un apport en code source ainsi que les membres positionnés pour le développement et l'apport :
- Identité décentralisée : Blockchain Certified Data
- Service de contractualisation : Visions SAS
- Service de consentement : Visions SAS
- Service de catalogue de données et de services : Visions SAS
- Service d'interopérabilité des données de compétences : Mindmatcher
- Service d'interopérabilité des données de traces d'apprentissage : Inokufu SAS
- Cadriciel de plugin universel : Inokufu SAS
- Service d'enrichissement de learning objects en compétences : Inokufu SAS
L'AG Constitutive du 12/10/2021 a validé le dossier BPI avec les communs à développer et les membres positionnés, cette AG valide les apports de chacun sur ces communs. Ces apports permettront de rapidement mettre du code et des services à disposition depuis le github Prometheus-X pour la communauté et pour leur utilisation dans les cas d'usage par la communauté.
Ils permettront également de montrer notre avancée au niveau de notre écosystème national et européen et de commencer concrètement des discussions de réutilisation de ces communs ou de leur interopérabilité avec d'autres systèmes en cours de développement.
Les propositions d'apport sont consultables ici
Report inappropriate content
Is this content inappropriate?
Comment details
You are seeing a single comment
View all comments
Conversation with Jean-Marie Gilliot
bonjour,
je trouve très bien de proposer un cadriciel / SDK de plugin et de l'instancier pour les cas majeurs coté LMS, à savoir LTI. Je me demande par contre en quoi le plugin Moodle est spécifique.
Concernant le développement préalable vers les outils Google et MS, je me demande :
1) l'opportunité de s'interfacer avec ces outils dans le cadre d'une démarche européenne
2) les use case pour s'interfacer avec les outils mentionnées (pour classroom, j'imagine équivalent aux LMS - pour chrome, je serai intéressé - pour Teams, je ne vois pas)
Jean-Marie
Moodle est dans une position ambiguë puisqu'il est possible de faire des plugins selon deux approches :
1. des plugins spécifiques à Moodle (non LTI) https://docs.moodle.org/dev/Plugintypes
2. des plugins LTI compatible avec Moodle https://docs.moodle.org/311/en/LTIand_Moodle
L'idée serait d'inciter les développement des plugins de l'approche 2 car cela permet ensuite un interopérabilité avec les autres LMS compatible LTI (Blackboard https://help.blackboard.com/Learn/Administrator/SaaS/Integrations/LearningToolsInteroperability, Canvas https://community.canvaslms.com/t5/Canvas-Basics-Guide/What-are-External-Apps-LTI-Tools/ta-p/57, etc)
L'objectif étant de ne développer qu'un seul plugin tout en garantissant qu'il sera compatible avec un maximum de LMS et autres plateformes/apps/outils éducatifs
Concernant MS Teams et Google classroom, vu leur utilisaltion dans les institutions éducatives européennes, il semble compliqué de les ignorer. Actuellement de nombreuses entreprises Edtech européenne font le choix de développer des plugins compatibles avec MS teams (https://docs.microsoft.com/en-us/microsoftteams/platform/overview). Ces "MS Teams apps" ne sont pas compatible avec LTI. En même temps, Microsoft propose des plugins compatible LTI permettant par contre d'intégrer MS Teams dans un autre LMS via LTI. Cette non réciprocité est problématique. Sans un stratégie de plugin permettant de garantir un interopérabilité réelle (dans les deux sens), les edtechs vont privilégier le développement de plugins spécifiques à la plateforme avec le plus d'utilisateurs, renforçant ainsi les monopoles existants et le vendor lock in.
Ceci n'est d'ailleurs pas spécifiques à Microsoft car l'approche est la même avec Google (https://edu.google.com/products/classroom/apps/) ou avec Zoom (https://marketplace.zoom.us/docs/guides/build). Toutes les grandes plateformes proposent des développements de plugins propriétaires. Cela permet d'enrichir les fonctionnalités de leur plateformes grace à des développeurs externes tout en créant un vendor lock in car les plugins développer ne sont pas réutilisable pour d'autres plateformes.
Loading comments ...