Version du 6 février 2007 à 18:03

Pour ouvrir dans de bonnes conditions l’observatoire au public des visiteurs et aux évaluateurs et pour assurer une vraie possibilité de collaboration entre projets : il faut organiser la gestion des métadonnées.

Essai de formalisation du problème

D’abord préciser les concepts et donner des définitions.

Modèle de l’observatoire : système d’information, trois éléments :

• bases de données
• interfaces
• utilisateurs

Il y a plusieurs bases de données définies par des ensembles de clés (et plusieurs modèles pour ces bases). Il y a toutefois une clé universelle qui est le référentiel communal INSEE/IGN 1999 (cette mention devrait être rajoutée sur les cartes). Il y a ensuite une différence entre les tables importées ou créées dans les bases. Il y a plusieurs types d’interfaces, ne serait-ce que chaque projet et plusieurs utilisateurs avec des profils (attributs définissant les droits d’utilisation) différents

Le modèle du système d’information est constitué par les relations fonctionnelles entre les trois éléments : données/interfaces/utilisateurs.

Les métadonnées concernent :

• les bases de données primaires et les données « internes » (concept à préciser)
• les fonctionnalités de l’application, c’est-à-dire des interfaces (ce qui passe notamment par des menus explicites et l’accès à la définition des termes clés des menus), mais aussi par des « guides »
• les utilisateurs.

Métadonnées sur les bases de données

Pour décrire les bases de données, il y a plusieurs types d’entités à renseigner (des fournisseurs de données aux « variables »…). Il a des besoins d’accès à l’information différents selon le type d’utilisateur et le moment.

Selon le type d’utilisateur et le moment, différentes formes d’accès aux métadonnées relatives à certaines entités sont proposées. Il s’agit de formaliser la présentation de ce qui existe déjà et de compléter les fonctionnalités pour améliorer ces accès.

Je propose de distinguer 7 types d’entités (ci-après à discuter), 3 types d’utilisateurs et 3 « moments » (terme à voir, cf. ci-dessous).

Types utilisateurs :

• visiteur « libre » (enregistrement après connexion LDAP) ayant accès au projet « visite de l’observatoire », on peut distinguer première visite et visites ultérieurs (EX : LDAP INRA),
• visiteur spécifique ayant accès à un projet spécifique (thèmes) et non au projet général « visite » (EX : interface tableau de bord pour la région ou pour une chambre),
• utilisateur titulaire

Moments de la navigation carto :

• accueil lors de l’entrée,
• menu général
• menu projet pour visiteur (thèmes, navigation)
• menu projet pour membre du projet
• menu projet pour responsable de projet
• menu traitement

(à préciser)

Les formes d’accès :

• affichage direct
• affichage « bulle » (contextuel)
• aide et autres liens internes
• liens externes

Pour formaliser il faut lier ces éléments dans des tableaux pour en discuter.

Quelles sont les entités à renseigner ?

(En italique termes qui figurent dans le glossaire, cf. article 2 de la convention, qui peut être amélioré ou complété si nécessaire…)

• les fournisseurs de données (Ils peuvent être : partenaires de l’observatoire, tiers agréés, ou simple utilisateurs titulaires), autres sources de données (non présentes dans l’observatoire, c’est-à-dire documentation externe).
• les ensembles de données (« enquêtes » dans carto), classées par fournisseurs de données,
• les tables de données au sein de ces ensembles (dans carto ces tables sont importées dans des zones de dépôts créées par les fournisseurs de données),
• les géo-index : (1) communes et divers échelons administratifs et opérationnels, (2) autres géo-index (captages, STOC…)
• les index d’ensembles de données « individuelles » (plusieurs par géocodes)
• les attributs (une « variable » est une valeur d’un attribut pour une valeur de l’index), ceci par table
• les indicateurs (résultats sauvegardés comme item d’un thème)

Est-ce que j’en oublie ???

Quels renseignements fournir et à quels moments selon les types d’entités à renseigner

• les fournisseurs de données
• les ensembles de données (« enquêtes » dans carto), classées par fournisseurs de données
• les tables de données
• les géo-index
• les index d’ensembles de données « individuelles »
• les attributs (tables de données primaires et tables de données secondaires obtenues par transformation)
• Les indicateurs

Annexes

Fiche pour agrément de tiers

Nom et adresse de l’organisme demandant l’agrément :

Représenté par :

• personne habilitée à représenter l’organisme :
• personne(s) contact(s) de l’observatoire :

(tél, email)

Présentation rapide des activités de l’organisme et de l’utilisation souhaitée de l’observatoire

• thématiques,
• type de données fournies ou utilisées (à détailler en annexe le cas échéant, ou par projet),
• types de résultats souhaités,
• modes de collaboration avec le groupe opérationnel ou les partenaires de l’observatoire (y compris financement le cas échéant)

(de ½ page à 2 pages)

Si déjà prévu :

• liste des personnes qui disposeront d’un accès à l’observatoire, comme titulaires ou comme visiteurs
• liste et présentation de « projets » à créer par des titulaires liés à l’organisme demandeur (annexer les fiches projets à la demande).

Fiche pour validation de projets INRA et agrément de projet tiers

1.Nom, adresse, tél, mail de la personne demandant l’agrément comme utilisateur titulaire de l’observatoire (ou étant déjà titulaire) :

Si déjà enregistré comme visiteur (via LDAP), login :

Si déjà titulaire, login : Le projet est-il déjà créé sur le serveur ?

2. Organisme partenaire ou agréé de rattachement :

3. Titre du projet dont la personne est ou serait responsable :

Nom du projet sur le serveur :

Autres utilisateurs prévus dans le cadre de ce projet :

• Titulaires :
• Visiteurs :

4. Objectifs scientifiques ou opérationnels du projet (5 à 20 lignes) :

5. Liste de données spécifiques déposées par le demandeur

Préciser s’il s’agit de :

• données propres au projet (non communicables à l’extérieur du projet) : il n’est pas nécessaire de détailler ce type de données,
• « publiques » : communicables à tout autre projet,
• « réservées » : communicables à certains projets qui pourraient en faire la demande.

NB. Si des données partageables (« publiques » ou « réservées ») sont déposées par l’utilisateur celles-ci devront être documentées selon les règles définies pour la gestion des bases de données de l’observatoire. Le responsable du dépôt de ces données sera

6. Liste de données « réservées » dont la communication est demandée

La documentation des données « réservées » disponibles pour des projets est disponible sur le serveur.

Préciser la demande selon les sources de données souhaitées (CNASEA, MSA….), indiquer la nature des données.

NB. Une base de données est créée pour le projet en fonction de la demande. Le modèle de cette base doit être entièrement spécifié avec l’équipe qui administre le serveur pour que techniquement parlant les données puissent être transférées au projet, soit avant l’établissement de la demande (et dans ce cas être annexé à la demande), soit après. Pour ce faire, la demande doit être précise : données individuelles ou données géographiques, niveau d’agrégation géographique, désignation des variables demandées selon les codes des dictionnaires ou description des indicateurs demandés…

7. Type de traitements projetés

Soit :

• Traitements externes, après exportation de données depuis le serveur (dans ce cas, le projet sur le serveur est essentiellement une interface d’exportation et peut être géré par l’équipe administratrice)
• Traitements utilisant l’application carto.

8. Publications projetées

Soit :

• Publications externes, revues scientifiques, rapports, journaux professionnels…

• Publication sur l’observatoire

  mise à disposition pour des visiteurs spécifiques : lesquels ?
  mise à disposition de tout utilisateur via la « visite de l’observatoire » 
  (transfert sous contrôle administrateur).

Charte de l’utilisation de l’observatoire du développement

A signer par les utilisateurs titulaires.

--gilles