Nouveaux profils et conventions rédactionnelles

Quels profils sont à prévoir ? (ne pas oublier de prévoir les hyerachylevel(name) correpondants)

• Données géographiques + INSPIRE (?)
• Services géographiques + INSPIRE (?) (Faut-il spécifier le type de services ? view, download... Faut-il spécifier l'accès ? internet, intranet, sécurisé...)
• Carte dynamique / application géographique (Faut-il spécifier l'accès ? internet, intranet, sécurisé...)
• Carte statique (pdf, image, papier...)
• Données localisées
• Données non-géographiques
• Map contexts (mxd)

Besoins et questions du géoportail

• Voir projet de refonte graphique

Besoins et questions INSPIRE

• Identification d'une fiche in scope
• Utilisation des mots-clés INSPIRE pour des ressources hors scope
• Métadonnées pour l'interopérabilité

Besoins et questions DGO3

• Feature dataset et feature class : comment implémenter les relations (agrégation ? quel type d'initiative utiliser ?), comment récupérer/transmettre et mettre à jour l'info entre les fiches
• Besoins liés au tableau de bord
• Besoins liés à l'inventaire des bases de données
• Documenter le modèle de données

Questions liées aux services

• Documenter un service qui propose plusieurs protocoles (REST, WMS, Inspire-view...)
• Nommer un service : commencer par "service" ou par le nom de la donnée ?

Questions liées aux conditions d'accès et d'utilisation et à la distribution

• Où placer les infos liées à la distribution ? a l'intérieur ou à l'extérieur d'un élément "distributeur" ? un mix des deux
• Formaliser les clauses prédéfinies pour les conditions d'accès et d'utilisation
• Renseigner un service WMS dans la distribution : racine du service ou requête GetCapabilities ?
• Faut-il systématiquement renseigner WalOnMap quand la donnée ou le service est disponible par ce canal ?
• Comment renseigner la distribution d'une donnée qui n'est disponible que sous forme de service ou à travers une application ?

Présentation d'une métadonnée dans une application

• Documenter une donnée telle qu’elle est consultable dans une application : par rapport à une donnée ‘brute’ la donnée consultable peut être une vue spécifique sur cette donnée : l’IR des orthos, les bâtiments publics venant du PICC, les routes de niveaux 1-2-3 de Navteq,… Renvoyer vers une fiche ‘générique’ de la donnée sous-jacente n’est pas toujours le plus pertinent. Il faut pouvoir par exemple expliquer pourquoi l’ortho est dans les tons rouges,… que ce n’est pas toutes les rues, que la symbologie se base sur une combinaison de champs,… (la liaison sera parfois 1-1).
• Par rapport aux autres champs (contacts, contraintes, copie,…) voir si cela a aussi des répercussions. Le titre peut être ? ce serait pas mal que le nom dans l’appli corresponde au nom dans la fiche. Résumé devrait parfois changer, généalogie aussi.
• Une feuille de style particulière aux (données des) appli peut aussi être envisagée, l’information première recherchée n’est pas nécessairement la même que dans un catalogue de data.
• Pour ce point de lien entre appli et data, clarifier aussi une métadonnée pour un service (qui lui donne une data ?, un jeu de donnée ?, un ensemble thématique ?) et/ou une MD par élément du service (couches visibles/ cliquables/cochables) dans l’application ? Si l’utilisateur peut interagir à un bas niveau, il devrait facilement pouvoir savoir sur quoi il joue, donc avoir un ‘i’ pas trop loin… et qui lui dit facilement sur quoi il travaille à ce niveau.
• Pouvoir lier cette nouvelle fiche avec celle de la donnée de base.

Métadonnée de donnée et service

• Indiquer ce qui est servi, et ce qu’on peut en faire. Comme lors de l’incorporation d’un service dans une app on peut choisir de tout garder, n’afficher que certaines couches, faire des query,… ceci n’est pas nécessairement équivalent au point précédent.

Métadonnées pour la gestion

• Pouvoir tirer un inventaire/état des lieu d’une DB : savoir ce qu’il y a dedans, comprendre les données, savoir dans quels services/app elles sont utilisées

Autres questions

• Open data
• Définition claire des rôles des parties prenantes : gestionnaire en particulier
• Dénomination des contacts : acronymes, niveau de détail hiérarchique, etc.
• Conditions d'accès et d'utilisation de la MD + autorisation d'édition par le gestionnaire du catalogue
• Identification des ressources : structuration, lien avec un emplacement physique, etc
• Vignettes : Autoriser uniquement le format carré ? Autoriser 2 formats différents (applications) ?