Lignes directrices
Le standard CERIFIntroduction
L’Institutional Knowledge Graph (IKG), développé par le consortium CRISalid, est implémenté sous la forme d'un graphe Neo4j et conçu en conformité avec le standard international international CERIF 2 d’euroCRIS (euroCRIS). Ce Ce choix vise à garantir l’interopérabilité du graphe des données ainsi que sa leur compatibilité avec les standards du web sémantique.
La récupération des information depuis l'application OSCAR
L'application OSCAR est
Objectifs
Priorité = intégrer données OSCAR GRAPHE
OSCAR réprésente l'info sous cette forme :
L'existant dans le grapheActuellement, les publications des chercheurs et chercheuses sont intégrées dans IKG. Un travail approfondi a également été mené sur la gestion des affiliations associées à ces publications, ainsi que sur la modélisation des structures de recherche. L’étape suivante vise à intégrer les projets de recherche. L'application OSCAR, développée par l'université de Caen, est utilisée par certains établissements pour gérer le montage des projets et le suivi des contrats de recherche. Elle constitue dès lors une source de données sur les projets. Il s'agira par la suite de récupérer les informations présentes dans OSCAR pour les ajouter au graphe de connaissance.
Les projets dans CERIF
Dans le modèle CERIF, un projet peut contenir des sous-projets et
il est structuré autour de ressourcesmobilisées et
de contributions. Les ressources engagées dans le cadre des projets sont
mobilisées sous la forme de Fundings. C’est autour de ces
entités que s’organisent les informations relatives aux financements, aux appels à projets et aux candidatures.
Les appels à projet (Call for Applications/ Call for Funding Application) sont des Resource Offers et les candidatures aux appels à projet (Application / Funding Application) sont des Resource Requests. Ces deux entités sont reliées à un agent. Dans le cas d’une candidature (Application), l’agent peut en être le requester lorsqu’il demande un financement, ou l’addressee lorsqu’il est destinataire de la candidature. Par ailleurs, une organisation peut lancer un appel à projets, ce qui correspond à la relation de type solicits. Enfin, les candidatures et les appels à projet peuvent être décrits dans des documents.
Le projet peut par ailleurs avoir plusieurs contributions,
qui existent aussi pour les documents et évènements. Dans le cas des projets, il existe des Contribution to Project, qui sont un sous-type de Contribution et d'Activity. Ces dernières sont définies par des Contribution Statements. Des Agents (personnes, groupes ou organisations) peuvent apporter des contributions de type Expertise+Time+Effort, Infrastructure ou Document. Par exemple, un chercheur ou une chercheuse peut publier un article dans le cadre d'un projet, y dédier quelques heures, ou bien une organisation peut mettre à disposition des serveurs GPU dans le cadre d'un projet.
En ce qui concerne les financements, les appels à Projets (Call for Applications / Call for Funding Application) sont des Resource Offers et les candidatures aux appels à projet (Application/Funding Application) sont des Resource Requests. Ces deux entités sont reliées à un agent qui peut demander un financement, il est donc "requester", ou bien l'offrir, il est alors "adressee". Enfin, les candidatures ou les appels à projet peuvent être décrits dans des documents.
Proposition de modélisation
La proposition de modélisation présentée ci-
dessus s’appuie sur la norme CERIF décrite précédemment, tout en introduisant certaines simplifications.
Explications et remarques
Les
Contributions
De la même manière que les documents, les projets
sont reliés à un nœud
Contribution. Une propriété "type" ("work", "infrastructure" ou "document
") est introduite sur ce nœud : il s'agit d'une simplification des Contribution
StatementsCERIF précédemment décrits
.
| title | Décisions |
|---|
Les décisions
Une propriété status a été ajoutée sur le nœud Application, elle simplifie la représentation CERIF des décisions. En effet, elles sont modélisées par l'entité Decision et
portent sur l'Application. La décision peut être reliée à un Agent (qui prend la décision), un Document ou un Evaluation Outcome
(ensemble des conclusions produites à l’issue d’un processus d’évaluation, sans constituer encore la décision finale). Ce choix permet par ailleurs de suivre
plus facilement l’état d’une candidature entre son dépôt et la décision finale
, par exemple : candidature déposée, dossier en cours de montage, dossier abandonné, etc., sans avoir à parcourir toutes les décisions associées.De la même manière, une propriété status est également ajoutée sur le Projet lui-même. La raison est similaire : elle permet de connaître rapidement le statut propre au projet (par exemple : en montage, en cours, terminé).
Propriétés ajoutées
- Les projets n'ayant pas forcément les mêmes dates de début et de fin que leur financement et pouvant avoir plusieurs financements, une date de début et un date de fin ont été ajoutées sur le nœud Project.
- Les appels à projet ont non seulement des deadlines, mais il est possible aussi d'obtenir leur type, leur nom ainsi que l'URL sur le site web du financeur, ces propriétés ont été ajoutées sur le nœud "Call for Applications"
| Remarque | ||
|---|---|---|
|
rrrr
- Organisations
- Ajouts par rapport à CERIF :
- dans OSCAR → concepts
- Présent dans HAL parfois → publications dans les projets → potentielle modélisation
- Disciplines
- Problématiques des champs libres d'OSCAR → quels champs on peut reprendre vs points d'attention
Il existe plusieurs types d'organisations dans IKG : les organisations issues du référentiel de l'institution, les Source Organisations issues du moissonnage des publications et les Authority Organisations qui sont une version consolidée des Source Organisations. Se pose alors la question du type d'organisation à choisir pour celles qui seront liées aux projets soit via les contributions, soit via les financements, d'autant plus que l'application OSCAR a son propre référentiel d'organisations. Réponse : Si les organisations proviennent du référentiel interne (ex. de l'annuaire LDAP), ce sont des Authority Organisations, sinon, ce sont des Organisations. |
| Remarque | ||
|---|---|---|
| ||
| OSCAR permet d'associer des disciplines à des projets, toutefois, les administrateurs de l'application peuvent ajouter n'importe quelle discipline ou vocabulaire de disciplines. A l'université Paris 1 Panthéon-Sorbonne, le vocabulaire des disciplines ERC a été choisi, il est dès lors possible de lier les projets à des nœuds Concept issus de ce vocabulaire, de la même manière que pour les publications. Ces Concepts seront reliés aux projets avec la relation "HAS_DOMAIN". |
| Avertissement | ||
|---|---|---|
| ||
1. Existence du projet et candidatures multiplesDans CERIF, le lien entre projet, appel et candidature semble principalement structuré via l’entité Funding. Or, lorsqu’aucune décision n’a encore été prise, il n’existe pas nécessairement de financement formalisé, ce qui rend ambiguë l’association entre une Application et un Project. Cela soulève deux interrogations :
2. Documents : preuve ou production ?Dans CERIF, un projet peut être "evidenced" par des Documents, ce qui renvoie à des pièces justificatives (dossier, contrat, rapport). Cependant, un projet produit également des documents scientifiques (articles, thèses, rapports finaux). CERIF ne distingue pas explicitement, au niveau du modèle générique, les documents comme éléments de preuve et ceux comme résultats. |
Projet exemple
Cet exemple est basé sur les informations accessibles via ce lien :
reprendre un projet ANR