La gestion des données de la recherche poursuit plusieurs objectifs: elle doit soutenir les chercheurs (les deux quadrants de gauche) et répondre aux exigences de la communauté scientifique ainsi que du grand public (les deux quadrants de droite). La gestion des données de la recherche sert la recherche en contribuant à permettre une utilisation active des données (les deux quadrants supérieurs) et assure une certaine qualité grâce à la documentation du processus de recherche (les deux quadrants inférieurs). Les objectifs prioritaires varient selon les phases du processus de recherche.

Nous nous référerons plusieurs fois, dans ce module, aux données d’Urs et Lydia sur l’utilisation de la communication mobile. Celles-ci ont été collectées par l’agence Publica Data AG. Urs et Lydia les ont réutilisées.

L’illustration montre un processus classique de la recherche. Le parcours des données traverse trois domaines:

-Private research domain (pour les chercheurs uniquement, donc dans notre cas accessible à Urs et Lydia). Les données sont stockées sur des ordinateurs privées ou sur Dropbox, GoogleDocs, Trello, etc.

-Shared research domain (accessible uniquement à un certain cercle de personnes, par ex. l’ensemble de l’Institut, ou de la haute école). Les données sont stockées dans un système de gestion tel que BSCW ou SharePoint.

-Public domain (accessible à un public plus large, voire publiquement).

Les données peuvent donc se trouver dans l’un de ces trois domaines :

• Le Private Research Domain
• Le Shared Research Domain, ou Collaboration Domain
• Le Public Domain, ou Publication Domain

Le Data Life Cycle peut lui aussi se décomposer selon les trois domaines, avec néanmoins quelques différences claires. Si l’on représente de la DDC Curation Lifecycle (ou un extrait de celui-ci) sur un axe temporel, on peut y visualiser les trois domaines. Si l’on combine les deux modèles, cela met en évidence dans quel domaine se déroulent quelles parties du cycle de vie.

Sur cette illustration, au-dessous des phases du DDC Lifecycle, apparaissent les étapes du cycle de vie, résumées sous une autre forme et représentées avec des images.

On note également que quelques points du cycle de vie ne se retrouvent dans aucun domaine. C’est le cas des points « Appraise & Select », « Ingest » et « Preservation » du DDC Lifecycle, qui sont résumés en tant que « Curation Boundary » dans le modèle du continuum.

Avec l’utilisation de nouveaux outils pour la gestion des données active, la frontière entre le Private Research Domain et le Collaboration Domain s’atténue. Les données sont stockées dans un environnement de recherche permettant de les traiter de manière active. Urs et Lydia souhaitent collaborer au moyen de SharePoint. Les données devant être mises à disposition de l’ensemble de l’Institut seront déposées dans un espace «public» spécifique.

Les objectifs d’une gestion des données active se basent avant tout sur les besoins des chercheurs. Afin de permettre l’échange au sein du cercle de chercheurs, les données doivent être documentées de telle manière à être compréhensibles pour tous les membres du groupe de recherche.

On le constate déjà durant la phase de gestion active: si les données devront servir à plusieurs chercheurs, elles doivent être saisies de la manière la plus structurée possible et bien décrites. De grands tableaux Excel sans explications des valeurs saisies ne sont utiles pour personne.

Il est tout aussi important que les décisions liées au processus de recherche soient documentées. Très souvent, les données ne sont compréhensibles que lorsque les réflexions et discussions correspondantes sont connues. La gestion des données de la recherche ne peut donc pas se limiter à la simple réception des données.

Dans le cas de projets importants, il peut être un avantage d’engager un «Embedded Data Manager», qui assistera les chercheurs dans la documentation et la gestion de leurs données.

Ce tableau met en évidence le fait que données et documents nécessitent d’être retravaillés dès le moment où ils doivent être utilisés par plusieurs personnes.

Jusqu’à présent, nous avons insisté sur le fait que les deux premiers domaines pourraient être gérés dans un seul système, avec l’utilisation d’instruments d’environnement de recherche.

Nous abordons maintenant le passage du Collaboration Domain au Publication Domain. On met dès lors les données à disposition d’un cercle encore plus large de personnes. Urs et Lydia mettent leurs données à disposition d’autres chercheurs. De cette manière, il devient possible de vérifier leur travail (les conclusions sont-elles plausibles?) et d’établir de nouvelles interprétations sur la base de ces données.

Le Publication Domain vise les objectifs des 2 quadrants de droite. Les données doivent être mises à disposition d’un cercle plus large de personnes pour réutilisation. Cela peut faciliter certaines études longitudinales. Idéalement, cela peut également épargner d’important coûts liés à la collecte de données.

On adresse par ailleurs aussi les objectifs d’assurance qualité. Les données doivent être publiquement accessibles, afin que les résultats de la recherche puissent être validés. La documentation des résultats de la recherche adopte un rôle plus important, notamment via la mise à disposition des données.

C’est dans le Curation Boundary que les données sont traitées pour la publication.

Il faut reconnaître que certaines points du cycle de vie ne se retrouvent dans aucun domaine. C’est le cas des points «Appraise & Select», «Ingest» et «Preservation» du DCC Life Cycle.

Dans cette phase, à savoir durant ces trois étapes caractérisées par une limite (boundary) que l’on franchit, on fait en sorte que les données soient compréhensibles et accessibles à long terme (les modules 2.2 et 2.3 donne plus de détails à ce sujet) par des tiers (personnes externes ou non impliquées dans le projet). Ce processus complexe peut d’ailleurs également être considéré comme un domaine à part entière (Curation Domain).

Infrastructure de Discovery (recenser les données) vs. infrastructure de stockage (enregistrer les données)

Le modèle du data continuum contient déjà des représentations de dépôts de données et de métadonnées.

Chaque domaine possède (théoriquement) une infrastructure de discovery ainsi qu’une infrastructure de stockage. Alors qu’un container comporte les données physiques (telles qu’un fichier SPSS, un document PDF, un script Python, etc.), un autre container comporte les métadonnées, ou plus exactement la partie des données de la recherche permettant la recherche des jeux de données. Il peut s’agir d’un système unique disposant d’un espace de stockage ainsi que d’une fonctionnalité de recherche, ou alors de deux systèmes séparés, par exemple un catalogue référençant au moyen de liens des fichiers se trouvant sur un serveur externe.

Attention : il s’agit ici d’une représentation simplifiée : il ne faut en principe pas considérer données et métadonnées séparément, en deux groupes distincts.

Alors que le transfert du domaine privé dans le domaine collaboratif est en général un procédé simple, le transfert dans le domaine public est plus exigeant. Les données doivent (ou devraient !) passer à travers un processus de migration, représenté ici en tant que « curation boundary » et plus haut en tant que « curation domain ». Les données sont traitées de sortes qu’elles soient accessibles et compréhensibles à long terme (les traitements exacts sont présentés dans le module 2-3).

Le métacatalogue openresearchdata.ch, encore en développement, est un exemple de portail pour données de recherche.

Les données pouvant être publiées dans un catalogue ne suffisent pas à rendre le jeu de données utilisable. Des descriptions plus détaillées sont nécessaires. C’est pourquoi un catalogue en ligne comporte généralement une page dite d’atterrissage (anglais: landing page): elle regroupe de plus amples informations sur un jeu de données précis. Sur l’illustration apparaît la landing page du jeu de données «Sicherheit 2014» dans le dépôt pour données de la recherche en sciences sociales FORS.

Ce graphique part du principe que toutes les données peuvent être publiées. Mais ceci est bien souvent impossible, par exemple pour des raisons de protection des données. Les données sont alors mises sous embargo (embargoed data), ce dernier étant généralement de durée illimitée mais pouvant également être restreint dans le temps. De telles données sont enregistrées dans des « data vaults » (en français coffres-forts de données). Il s’agit donc ici de données sous curation qui ne sont pas mises à disposition du public. Elles sont néanmoins recensées dans le catalogue de métadonnées normal avec les autres jeux de données publics. Leur existence est donc signalée, même si elles ne sont pas accessibles.

Les données de la recherche et leurs métadonnées peuvent se trouver dans l’un des quatre quadrants suivants :

• Les données accessibles au grand public (public data)
• Les données non accessibles par tous, mais par un cercle restreint de personnes (private data)
• Les métadonnées accessibles au grand public (public metadata)
• Les métadonnées non accessibles par tous, mais par un cercle restreint de personnes (private metadata)

Catalogue et dépôt maison vs. externes

Une fois que les données sont passées par le domaine de la curation, la question du stockage et du catalogue se pose.

Il faut distinguer essentiellement :

• Un stockage et un catalogue maison, donc qui se trouvent au sein de sa propre institution

Un stockage et un catalogue externes, donc qui se trouvent dans le cloud, auprès d’autres institutions, organisations ou entreprises.

Contrairement à d’autres domaines, il est possible voire habituel dans le domaine public de déposer les données et métadonnées à différents endroits. Ainsi, les métadonnées (et plus rarement les données elles-mêmes) peuvent être disponibles dans plusieurs catalogues (voir « Métacatalogues pour métadonnées »).