Introduction
Lignes directrices
Le standard CERIF
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 IKGActuellement, 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 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.
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.
| Info | ||
|---|---|---|
| ||
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. |
Dans le cas des contributions de type "document", un nœud Document est |
relié au nœud Contribution lorsque le document |
correspondant a été moissonné. |
| Info | |
|---|---|
|
| |
|
| Info | ||
|---|---|---|
| ||
| 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é). |
| Remarque | ||
|---|---|---|
| ||
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. |
| 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 |
| serait 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. |
