Attention : vous êtes dans la page de discussion de la page Guide de saisie des éléments de métadonnées INSPIRE - Appliqué aux données
- Vous êtes ici: Accéder au Wiki GeoRezo » Accueil : Wiki GeoRezo » Les données spatiales » Documents sur Inspire » discussion » aide_a_la_saisie_des_metadonnees_inspire
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révision Les deux révisions suivantes | ||
main:donnees:inspire:discussion:aide_a_la_saisie_des_metadonnees_inspire [2012/06/14 11:28] Marc Leobet |
main:donnees:inspire:discussion:aide_a_la_saisie_des_metadonnees_inspire [2013/01/30 10:27] lmarie |
||
---|---|---|---|
Ligne 3: | Ligne 3: | ||
Pour les services de l'Etat, le guide recommande d'inscrire « aucune condition ne s'applique ». Il faut lire « aucune condition **d'accès** ne s'applique ». En effet, les conditions d'utilisation, même si elles sont légères, existent. | Pour les services de l'Etat, le guide recommande d'inscrire « aucune condition ne s'applique ». Il faut lire « aucune condition **d'accès** ne s'applique ». En effet, les conditions d'utilisation, même si elles sont légères, existent. | ||
- | La recommandation 29 devrait être : | + | La recommandation 9.2.2 devrait être : |
- | 29. Pour les services de l’État, dans le cas général, le décret n° 201-577 du 26 mai 2011 relatif à la réutilisation des informations publiques détenues par l’État et ses établissements publics administratifs conduira à retenir la valeur “aucune condition d'accès ne s’applique”. Il conviendra d'ajouter la mention "Utilisation libre sous réserve de mentionner la source (a minima le nom du producteur) et la date de sa dernière mise à jour." | + | 2. Pour les services de l’État, dans le cas général, le décret n° 201-577 du 26 mai 2011 relatif à la réutilisation des informations publiques détenues par l’État et ses établissements publics administratifs conduira à retenir la valeur “aucune condition d'accès ne s’applique”. Il conviendra d'ajouter la mention "Utilisation libre sous réserve de mentionner la source (a minima le nom du producteur) et la date de sa dernière mise à jour." |
+ | |||
+ | De Marc Leobet le 28/11/12 : Sur trois éditeurs d'outils de saisie de métadonnées que j'ai contrôlé, trois n'ont pas su interpréter correctement le guide pour la partie des conditions d'accès et d'utilisation. Concrètement, ils proposent le tableau 3 en référence et implémentent plus ou moins complètement les tableaux 1 & 2. Il semble que la présence du tableau 3 , qui reprend la typologie ISO, perturbe la prise en compte correcte des deux précédents. | ||
+ | Par ailleurs, ces éléments ne concernent pas les agents chargés de saisir des métadonnées INSPIRE et sont donc superfétatoires ici. | ||
+ | Etant donnée que ce tableau est facultatif, qu'il "n'est pas suffisant pour établir une base légale", qu'il est adapté à la Défense nationale mais que ce domaine n'est pas dans le champ de la directive INSPIRE, je propose sa suppression de ce guide. | ||
+ | Par cohérence, la colonne "Contrainte de sécurité" du tableau 1 est à supprimer. En effet, cette contrainte n'existe pas en tant que telle dans INSPIRE. Les restrictions relatives à la défense nationale sont gérées dans le cadre des restrictions légales de diffusion, Tableau 2. | ||
+ | |||
+ | De Marc Leobet le 28/11/12 : Etant donné les massives erreurs d'interprétation des rôles dans les métadonnées actuelles, il convient d'expliquer les différents rôles (ce sont les commentaires) et de recommander les plus utiles. Par exemple, le rôle de "producteur" n'existe pas alors que c'est celui qui est spontanément cité en premier lorsqu'il s'agit de données. | ||
+ | La rédaction des commentaires et recommandations est soumise évidemment à discussion. | ||
+ | |||
+ | De Marc Leobet le 4/12/12 : Ajout d'une proposition de recommandation à l'attention des éditeurs portant sur des règles de stockage des contraintes d'accès et d'utilisation INSPIRE dans l'ISO. | ||
+ | |||
+ | De Marc Leobet le 12/12/12 : Ajout d'un exemple d'emploi de l'étendue temporelle pour noter la date d'entrée en vigueur d'un texte règlementaire associé à la donnée. Ajout d'une précision sur ce qu'est une révision (dans Référence temporelles). | ||
+ | |||
+ | De Benjamin Chartier le 21/01/2012 : Voici quelques sujets que j'aimerais voir clarifier ou corriger : | ||
+ | * La manière de déclarer l’unité de la résolution (incohérence entre le guide, l’implémentation faite dans GéoSource et les exemples du guide européen). Je milite activement pour intégrer l’approche de GéoSource et des exemples du guide européen : abréviations des unités internationales plutôt que les noms en français des unités (moins de sources possibles d’erreur et plus simple à gérer par les outils) | ||
+ | * La manière de déclarer le code EPSG du référentiel de coordonnées (URI ou pas URI) | ||
+ | * Emploi du terme "top secret" (terme probablement utilisé par les anglo-saxons et dans les films d'action) au lieu de "très secret défense" (tableau 1 page 29 du § IX.1. Généralités) | ||
+ | * L'interprétation du chapitre sur les contraintes (sujet déjà évoqué par Marc plus haut dans cette page) : faire le lien entre les champs de saisie de GéoSource et les tableaux fournis me semble hors de portée du commun des mortels (dont je fais partie). J'aimerais bien qu'on évoque des cas concrets récurrents : cas des données pour lesquelles aucune contrainte n'existe, cas de données type OpenData, cas de données pour lesquels des licences s'appliquent (données de l'IGN ou de prestataires). | ||
+ | * Les exemples de noms et versions de formats (pour l’encodage des données) du guide de saisie et ceux proposés par GéoSource sont incohérents. Il faudrait que l’on harmonise cela. Par ailleurs, il faudrait préciser ce qu’il faut mettre lorsque le nom du format est connu mais la version inconnue (par exemple pour ECW). Pour ma part, j’aurais tendance à préconiser la valeur « Unknown » pour reprendre la valeur utilisée dans les exemples de fiche de métadonnées inclus dans le guide européen. Ou faudrait-il plutôt utiliser l'attribut "nilReason" pour traiter l'absence de cette information ? | ||
+ | * J’aurais également bien aimé que l'on indique comment ajouter le logo des organisations responsables. | ||
+ | * Le guide indique que le degré de conformité peut prendre les valeurs conforme, non conforme ou non évaluée. Malheureusement, je n’ai pas trouvé comme indiquer « non évalué » avec l’interface de saisie de GéoSource. Je ne sais pas si c’est une anomalie au niveau de GéoSource ou si c’est la manière de le renseigner dans les métadonnées qui est plus subtile que ce que je n’espérais. | ||
+ | * Un ou deux exemples concrets et complets de fiches de métadonnées en annexe seraient les bienvenus. | ||
+ | |||
+ | //Éléments de réponse de Marc Leobet (LBT 25.01.13): j'ai ajouté deux exemples pour Open data et données sans contraintes. Je laisse un producteur montrer un exemple de licence propriétaire. | ||
+ | Il a été acté que le guide n'était pas un manuel Géosource, mais qu'il était de la responsabilité des gestionnaires de Géosource/Géonetwork de mettre à jour leurs tutoriels et leurs outils. | ||
+ | Bonne idée, mais je n'ai pas encore vu de fiche en ligne pleinement conforme au guide, ni même à INSPIRE. Faut-il en faire une fausse sous OpenWriter?// | ||
+ | |||
+ | De Benjamin Chartier le 24/01/2012 : Quelques points complémentaires : | ||
+ | * GéoSource inclut une suggestion pour l'identificateur de ressource unique écrite comme ceci : "FR-SIREN-CODE". Les recommandations de notre guide indiquent l'emploi de minuscules. J'ai également remarqué que des fiches de métadonnées présentes dans le geocatalogue utilisent le préfixe "FRA-". Pour faciliter la diffusion de la bonne parole il serait intéressant que la prochaine version de GéoSource applique à la lettre les recommandations de notre guide et que des exemples complets et respectueux de ces règles soient intégrés à la solution (les mêmes exemples que je préconisais d'annexer au guide un peu plus haut). Cela permettrait aux rédacteurs de métadonnées de partir sur des bases correctes. | ||
+ | * Je reçois des demandes récurrentes sur la manière de faire un lien entre la fiche de métadonnées des données et leur modèle de données. Je vois deux manière de traiter ce sujet : via ISO 19110 ou en pointant vers un document de spécification (qui accompagnerait la fiche de métadonnées ou qui serait disponible en ligne). Vous parait-il souhaitable d'aborder ce sujet dans le guide national ? | ||
+ | //LBT 25.01.13 : bonne idée : j'ai vu ainsi un collègue fournir le catalogue d'attributs via un extrait d'un standard COVADIS. Cela pourrait prendre place dans le 8.1 Spécifications// | ||
+ | |||
+ | * J'ai noté la présence dans GéoSource d'un type de date particulier : Validité. Je n'ai pas trouvé de trace de ce type de date dans ISO 19115 ni dans le guide technique INSPIRE. J'ai noté son utilisation dans certaines fiches de métadonnées présentes dans le Geocatalogue. Est-ce une valeur acceptable ? Quelle est sa signification ? Faut-il préciser quelque chose à son sujet dans le guide national ? | ||
+ | //LBT 25.01.13 : j'imagine qu'il s'agit du champ "Etendue temporelle"?// | ||
+ | |||
+ | * Une question que je trouve délicate à traiter : lorsqu'une ressource est mise à jour, faut-il créer une nouvelle fiche de métadonnées avec un nouvel identificateur de ressource unique intégrant un numéro de version/millésime ou faut-il simplement mettre à jour une fiche de métadonnées existante en y ajoutant une date de révision ? Mon opinion personnelle est que les deux cas de figure peuvent s'appliquer mais j'aimerais qu'on voie ensemble si nous devrions pas faire des recommandations pour clarifier ce sujet. Par ailleurs, la question de la mise à jour n'est pas évidente pour les bases de données qui sont mises à jour en continu. Il y a peut-être quelque chose à préciser pour ce cas de figure qui me semble assez fréquent. | ||
+ | //LBT 25.01.13 : une proposition? Nous avons inclus un exemple sur les séries mises à jour en continu, au 6.1.Etendue temporelle // | ||
+ | |||
+ | |||
+ | De Benjamin Chartier le 25/01/2012 : | ||
+ | * Comment doit-on déclarer la nature de la licence applicable à la ressource. Par exemple, si je veux indiquer que les données sont disponibles sous licence ODBL, comment dois-je le faire ? | ||
+ | //LBT 25.01.13 : pareil que pour la licence ouverte : écrire le texte qui va bien dans le champ "conditions d'accès et d'utilisation". Mais comme notre analyse est qu'ODBL n'est pas conforme à INSPIRE pour une autorité publique, cela n'a pas sa place dans un guide INSPIRE.// | ||
+ | |||
+ | |||
+ | De Marie Lambois le 25/01/2013 : | ||
+ | Réponse aux différents points soulevés par Benjamin Chartier. | ||
+ | |||
+ | De façon générale, une grande partie des remarques ci-dessus concernent davantage l'implémentation que le guide de saisie. Les règles d'implémentation sont à préciser dans le "Guide de Gestion des catalogues de métadonnées INSPIRE". Je les classe donc comme ça pour faciliter le travail de mise à jour par la suite. | ||
+ | |||
+ | - > Réponses aux remarques concernant uniquement l'implémentation : | ||
+ | |||
+ | En ce qui concerne les CRS, les unités ou encore les types de formats, il est effectivement préférable d'utiliser l'identifiant d'un registre particulier pour éviter toute imprécision ou erreur d'implémentation. | ||
+ | - En ce qui concerne les CRS une solution serait d'utiliser le registre OGC et donc de renseigner les CRS sous forme d'URN OGC : urn:ogc:def:crs:EPSG::4326 [http://www.opengeospatial.org/ogcUrnPolicy] | ||
+ | - En ce qui concerne les unités pareil il existe un registre OGC pour ça, les unités ayant la forme : urn:ogc:def:uom:OGC:1.0:metre | ||
+ | - L'équivalent pour les formats est plus difficile à trouver. Une solution simple serait de faire un petit "registre" français, sous la forme d'une page wiki, ou d'une page Georezo quelque part listant les différents possibilités de format et la façon dont ils doivent être encodés. Elle serait enrichie au fur et à mesure des besoins et des nouvelles versions de formats. | ||
+ | Pour la saisie de ces valeurs, des dénominations plus "humaines" seront proposées par l'éditeur, telles que celles mentionnées dans le guide : mètre, … | ||
+ | |||
+ | La gestion par INSPIRE des contraintes est effectivement assez complexe. L'idée est donc que les éditeurs simplifient le travail en amont pour les utilisateurs. Le guide de saisie ne permet donc en aucun cas de savoir comment implémenter les contraintes en XML, il donne uniquement à l'utilisateur une liste des contraintes possibles et les cas dans lesquelles elles s'appliquent. Il est donc important de conserver tout de même la liste des "anciennes" contraintes du tableau 3 pour que l'utilisateur pense à les conserver/renseigner si elles s'appliquent. | ||
+ | |||
+ | - > Réponses aux remarques concernant l'ajout de nouveaux éléments : | ||
+ | Il est tout à fait possible d'un point de vue technique d'ajouter des éléments tels que logo si un besoin s'en fait sentir. Je ne doute pas que cela corresponde à un besoin général car ces éléments ont été ajoutés à la révision d'ISO 19115. techniquement il y a deux solutions pour implémenter ces ajouts : contourner l'usage d'un élément existant ou étendre la norme avec un élément nouveau, la seconde méthode étant plus lourde à mettre en œuvre. Dans tous les cas, il faudra également documenter cet ajout dans le guide d'implémentation. | ||
+ | Je pense qu'il ne faut les mentionner dans le guide que si ça correspond à un besoin pour le Géocatalogue. Dans le cas contraire rien n'interdit à chacun d'enrichir sa métadonnée. | ||
+ | |||
+ | Concernant le lien vers la description de la donnée pour des données compatibles INSPIRE il est assez simple grâce à la mention du thème INSPIRE, qui permet de retrouver les spécifications associées. | ||
+ | |||
+ | Il me semble être une bonne idée effectivement d'ajouter un exemple de métadonnée "réelle". Une vue "utilisateur" (html) de cette métadonnée pourrait figurer dans le Guide de saisie et une vue "technicien" (xml) de la même métadonnée pourrait figurer dans le guide d'implémentation. | ||
+ | |||
+ | - > Réponses concernant Géosource : | ||
+ | La valeur de conformité "non évalué" est renseignée par l'absence de l'élément degré, ce qui n'est effectivement apparemment pas possible à faire dans Geosource. Ce fonctionnement est explicité dans le guide d'implémentation. Dans le guide de saisie on ne rentre pas dans ce détail d'implémentation. | ||
+ | |||
+ | Je n'ai pas trouvé le type "validité" dans la dernière version de Geosource. Dans INSPIRE ce type doit effectivement être remplacé plutôt pas les éléments d'étendue temporelle. | ||
+ | |||
+ | Concernant la forme de l'identifiant il me semblait avoir vu des exemples dans le guide de saisie. Sinon effectivement il faudrait en ajouter. | ||
+ | |||
+ | - > Réponses Autres : | ||
+ | |||
+ | "Très secret" est effectivement la formulation d'usage. | ||
+ | |||
+ | Le principe de révision est à distinguer en 2 cas : | ||
+ | - On fait une nouvelle version mais la version précédente est conservée en parallèle. Les 2 versions cohabitent donc, elles doivent toutes les 2 avoir leur propre métadonnée et donc il faut un nouvel identifiant pour la nouvelle version. | ||
+ | - On fait une nouvelle version qui vient "écraser" la version précédente, qui à ce moment disparait du catalogue, des services … A ce moment là on conserve l'identifiant de la métadonnée et on change uniquement la date de révision dans la métadonnée. C'est en général ce cas de figure pour de la mise à jour en continue, sinon la donnée elle-même deviendrait encore plus ingérable que la métadonnée. | ||
+ | |||
+ | De Etienne Taffoureau le 29/01/2013 : | ||
+ | |||
+ | Le type de date "validité" du champ étendue temporelle est un ajout dans le profil France de la norme ISO 19115 (tout comme "péremption") qui est encore géré dans Géosource. Cette valeur n'est pas utilisable dans le cas d'une métadonnée INSPIRE et n'est pas exportée vers le Géocatalogue. Je pense donc qu'il ne faut pas la mentionner dans le guide, même s'il s'agit d'une information utile dans certains cas. | ||
+ | |||
+ | Comme l'indique Marie, dans le cas d'une donnée INSPIRE la référence au modèle se fait indirectement au travers du thème et du champ spécification (à condition que la conformité ait été évaluée) et le guide indique clairement que l'on peut référencer d'autres spécifications (par exemple COVADIS). Je pense qu'il faudrait ajouter dans le guide une recommandation pour indiquer l'URL d'accès au document de spécification s'il est disponible en ligne. | ||
+ | Dans Géosource la fonctionnalité permettant d'associer un modèle de données au format ISO19110 à une fiche de métadonnées est très utilisée et a encore fait l'objet d'évolutions dans la dernière version. Je pense qu'il faudrait simplement mentionner dans le guide l'existence de cette norme. | ||
+ | |||
+ | Je confirme que la présence d'un logo dans les métadonnées répond à un besoin dans le Géocatalogue puisque c'est aujourd'hui le seul moyen d'afficher le logo du producteur, si celui-ci ne correspond pas à l'adhérent déclaré dans le Géocatalogue (cas des plateformes régionales par exemple). cela rejoint également la proposition de Marc sur le rôle du contact et la notion de "producteur". | ||
+ | Le champ dans lequel est stocké le logo (sous forme d'une URL ) est dans contactInstruction dans les contacts. @Marie : je suis preneur d'informations l'ajout de cet élément dans la révision de l'ISO 19115. | ||
+ | Marie : //Ce serait sous forme d'un élément logo du contact. Je voulais surtout dire par là que ce besoin semble grandissant et partagé... Le mieux est de le conserver dans ContactInstructions en attendant. Est-ce qu'il y a des contraintes techniques sur le logo à mentionner dans le guide (taille, format, ...) ? // | ||
+ | |||
+ | Sur le champ version du format, qui est obligatoire dans l'ISO 19115 lorsque le format est renseigné, je préconiserais plutôt l'emploi d'un attribut "nilReason", comme c'est l'usage dans Géosource dans d'autres cas. Mais je ne suis pas opposé à utiliser la valeur "unknown" (ou "inconnue" en français) puisqu'il s'agit d'un champ texte libre. | ||
+ | |||
+ | Je suis entièrement d'accord avec Benjamin sur l'emploi des abréviations des unités internationales pour la distance de résolution, en tout cas pour le stockage. A charge ensuite des éditeurs de logiciels d'afficher les unités en toute lettre. | ||
+ | |||
+ | Sur la manière de déclarer les CRS il faut indiquer clairement dans le guide ce qu'il faut remplir et s'y tenir, car l'impact au niveau des logiciels n'est pas négligeable. L'utilisation du registre OGC me paraît être une bonne solution. |