Guide de gestion des catalogues de métadonnées INSPIRE

Pour ce guide, le groupe Métadonnées était composé des personnes ci-dessous. Il a été animé par Marc Leobet. Le secrétariat en a été assuré par Eliane Roos. Les contributeurs ont été :
Benjamin CHARTIER Géopicardie
Chloé CHAUVEAU GIP ATGERI
Matthieu CARTOIXA ISOGEO
Laurent COUDERCY ONEMA
Carole MICHAËL ONEMA
Sylvain GRELLET Sandre OIEau
Fredéric HOUBIE Intergraph
Benoit LEFEBVRE CG92
Nicolas LESAGE IGN
Pierre NOUAILLE-DEGORCE IGN
Eliane ROOS IGN
Dimitri SARAFINOF IGN
Henri PORNON IETI Consultant
Fabrice PHUNG DREAL Bretagne
Maël REBOUX Rennes Métropole/Ville de Rennes
Etienne TAFFOUREAU BRGM
Sandrine TOUS CRAIG
Lydie VINSONNEAU CR de Bretagne
Thibaut VOISIN MEDDE/SG/CPII
Clément JAQUEMET MEDDE/CGDD/DRI/MIG
Marc LEOBET MEDDE/CGDD/DRI/MIG

La mise en application des règles de mise en œuvre INSPIRE sur les métadonnées ne se résume pas au remplissage d’un ensemble spécifié d’éléments de métadonnées, qui a fait l’objet du guide de recommandation de décembre 2011. Elle impose en amont de s’interroger sur :

1. Les données et les services entrant dans le cadre de la directive ;
2. L’identification de l’ensemble des ressources entrant dans le champ de la directive ;
3. La meilleure manière d’exposer les ressources dans le champ d’INSPIRE du point de vue :

• de la structure qui les expose ;
• de la cohérence de l’infrastructure nationale d'information géographique et de sa relation avec les infrastructures territoriales et européenne ;
• des utilisateurs potentiels de ces ressources.

Ce document s’adresse aux administrateurs de données, au sens des personnes physiques ou morales confrontées à ces interrogations, qui vont devoir établir une liste précise des ressources à documenter et orienter la saisie des éléments de métadonnées permettant leur documentation. Il accompagne et complète le guide de recommandations pour la saisie de métadonnées de données établi par le CNIG, dont la connaissance est requise pour tirer parti du présent document. En particulier, le glossaire défini à cette occasion n’est pas repris ici.

Nous utiliserons le terme de données en règle générale, sauf quand il sera question des éléments spécifiquement INSPIRE que sont les métadonnées de séries et d'ensembles de séries. Le reste du temps, le terme de données recouvre la notion de séries et d'ensemble de séries de données géographiques.
Nous rappelons que les services étant utilisés par des usagers, la stabilité de l’URL du service doit être maintenue autant que possible.

Les administrateurs nationaux ne sont pas la cible principale de ce guide vu leurs contraintes particulières.

La directive INSPIRE s’applique aux données géographiques numériques détenues par des autorités publiques concernant des données de référence et des données environnementales (annexes I, II et III de la directive). Les cartes scannées ne tombent sous le coup de la Directive que dans le cas où elles sont considérées comme des données de référence, c'est-à-dire dans le cas où elles ne sont pas dérivées de données vectorielles respectant les obligations d’INSPIRE.

Par ailleurs, toute donnée indirectement géoréférencée entrant dans le champ des annexes (par exemple, une donnée sous tableur relative à une coordonnée, à une adresse, à une parcelle ou à une unité administrative) entre dans le champ d'INSPIRE. Pour une partie d'entre elles (photographies géoréférencées de crues, par exemple), on peut considérer que leur traitement n'est pas prioritaire.

La directive INSPIRE instaure notamment l’obligation de produire et mettre à disposition du public les métadonnées décrivant les séries ou ensembles de séries de données concernées. Cette obligation entre en vigueur à dater du 3 décembre 2010 pour les données concernées par les annexes I et II et du 3 décembre 2013 pour les données de l’annexe III.

Enfin, la directive INSPIRE impose aux États européens de mettre en place des services électroniques de recherche, de consultation, de téléchargement, de transformation de données et services d’appel de services. La réponse française à cette demande consiste à développer une infrastructure nationale de services dont le Géocatalogue est un des maillons. Cette infrastructure nationale s’appuie notamment sur un ensemble de catalogues interconnectés qui sont décrits ci-dessous.

Par décision du ministère en charge de la directive INSPIRE, le Géocatalogue est le nœud privilégié de l’infrastructure de données géographique (IDG) nationale pour la recherche et la consultation des métadonnées, notamment celles relevant de la directive INSPIRE. Il contient la base de métadonnées qui sert au rapportage de la France sur la mise en œuvre de cette directive.

Les autorités publiques détenant des données et services géographiques entrant dans le cadre d’INSPIRE sont incitées à alimenter le Géocatalogue, soit en permettant le moissonnage de leur propre catalogue, soit en y ajoutant directement, par importation, des métadonnées de données et de services.

L’infrastructure de données géographiques nationale s’appuie, en pratique, sur le niveau régional pour ce qui est de la mise en œuvre d’INSPIRE sans préjuger des moyens techniques et des modalités de coordination des acteurs publics. Il se crée ainsi une infrastructure nationale composée de catalogues fédérateurs, soit au niveau régional, soit par domaine thématique. L’organisation de cette infrastructure est bâtie autour de la notion de proximité des catalogues vis-à-vis des producteurs : les producteurs nationaux alimentent directement le Géocatalogue. Les producteurs territoriaux alimentent en priorité les catalogues fédérateurs régionaux, portés par les plates-formes régionales ou d’autres structures de mutualisation thématique ou plurirégionales. Des catalogues locaux peuvent, évidemment, alimenter directement le Géocatalogue pour des raisons locales (absence de plate-forme fédératrice).

Les recommandations émises ci-après visent à assurer la cohérence de l’infrastructure nationale.

Recommandations nationales :
1. Chaque administrateur doit s’assurer que a minima les métadonnées concernées par INSPIRE dont il a la responsabilité sont remontées au Géocatalogue.

Commentaire
Ceci peut-être fait soit par moissonnage à partir d’un catalogue local, soit en important des métadonnées directement (par exemple au moyen d’un fichier Excel) sur le Géocatalogue ou sur un catalogue fédérateur (plate-forme régionale ou thématique). Ce dernier doit être déclaré au Géocatalogue pour que le moissonnage soit effectif.
Dans les deux cas :

Recommandations nationales :
2. Seule l’organisation qui produit une ressource ou l’une des organisations responsable de sa diffusion, alimente le catalogue fédérateur des métadonnées correspondantes, de façon à éviter les duplications.
3. Les organismes partageant des responsabilités vis-à-vis d’une ressource s’entendent pour qu’un seul ensemble de métadonnées soit mis en place au sein du catalogue fédérateur.
4. Lorsque c’est possible, les métadonnées locales doivent être fédérées dans un catalogue intermédiaire (plate-forme régionale ou thématique…). Dans ce cas, elles ne doivent pas être déclarées directement au Géocatalogue, c’est le catalogue intermédiaire qui s’en chargera.

Commentaires
Il est justifié pour des plates-formes fédératrices d’établir des fiches de métadonnées pour des données dont ils ne sont pas producteurs, mais pour lesquelles des licences ont été attribuées. Ces fiches de métadonnées n’ont pas vocation à être remontées au niveau du Géocatalogue (cf. IV.3). En effet, pour des raisons de qualité, de responsabilité, et pour éviter les doublons au niveau du Géocatalogue, seules les métadonnées établies par les producteurs de la donnée doivent être affichées au niveau national.
Les données auxquelles de la valeur ajoutée (informations nouvelles) a été apportée doivent être pourvues d’une nouvelle fiche de métadonnée décrivant la valeur ajoutée et faisant référence à la donnée source.

Exemples :
Par exemple, les métadonnées de séries et ensembles de séries de l’IGN sont renseignées par celui-ci. Les utilisateurs ne doivent pas fournir au catalogue fédérateur des métadonnées pour les données IGN (BD Carto®, BD Topo®) dont ils disposent.
Les données diffusées par Cartorisque1 sont issues des données produites en particulier par les DDT. Ces données locales sont homogénéisées selon une structure normalisée, ce qui justifie des métadonnées spécifiques. On a donc deux métadonnées, celle de la DDT pour la série de données originale et celle de Cartorisque pour la série normalisée.

Au sein d’un catalogue, il est important pour faciliter la recherche que les métadonnées ne soient pas redondantes, c'est-à-dire qu’on ne trouve qu’une seule fiche de métadonnées décrivant les mêmes données.

Le « moissonnage » est une opération du service de catalogage qui permet d’importer les métadonnées (c'est-à-dire le contenu XML ISO 19139 dans son intégralité) contenues dans un catalogue vers un autre catalogue. Ce mécanisme risque d’engendrer mécaniquement des doublons dans les catalogues fédérateurs, et notamment dans le Géocatalogue, dans le cas où un catalogue moissonne des métadonnées qu’il a déjà « en stock ».

En théorie, le mécanisme de moissonnage utilise l’élément de métadonnées « identificateur de ressource unique » (ou URI, cf. guide de saisie des métadonnées, §II.5) pour éviter les doublons, c'est-à-dire qu’une métadonnée qui a le même URI qu’une métadonnée déjà « en stock » ne sera pas moissonnée. La comparaison des dates des métadonnées permet de distinguer les mises à jour et de les moissonner.

Dans le cas d’une donnée versionnée, les identificateurs de ressource unique des ressources sont différents.

Recommandation nationale sur l’identificateur unique de ressource
1. Un identificateur de ressource unique ne doit pas être modifié par le catalogue moissonneur sauf justification impérieuse.

Commentaire
En pratique, le bon fonctionnement de ce mécanisme est très dépendant de la façon dont les métadonnées sont renseignées et des outils actuels. Quelques règles d’organisation recommandées dans ce document visent à s’assurer de ne pas dépendre uniquement de ce mode de fonctionnement.
Même si cette question est pour le moment secondaire pour les administrateurs, elle est indispensable pour la gestion du réseau de services national, qui comprend également les échanges inter-régionaux.

La cohérence des contenus des catalogues est au moins autant une question d’organisation que de technique. Un dialogue entre les deux administrateurs (le moissonné et le moissonneur) s’avère, en pratique, nécessaire.2

Il arrive que certaines ressources soient documentées dans un catalogue interne à une organisation, mais que l’on ne souhaite pas qu’elles soient moissonnées et diffusées au public. Ceci est notamment le cas pour les données dont l’organisation n’est pas directement responsable. Par exemple, pour les données du système d’information sur l’eau détenues par les services locaux, mais bancarisées nationalement : il est normal qu’un agent du service local ait accès à toutes les métadonnées du patrimoine local de données, mais il n’est pas de bonne pratique que le service local fasse remonter des métadonnées locales sur les produits du système d’information sur l’eau dans un catalogue fédérateur de rang supérieur, alors que la banque nationale fait l’objet de métadonnées nationales. Voir aussi la recommandation 2 sur les métadonnées de séries et ensemble de séries pour un autre cas de figure.

Recommandations nationales
1. Un administrateur de données doit s’assurer, au sein de son entrepôt de métadonnées, que seules les métadonnées devant être rediffusées seront moissonnées par le catalogue fédérateur.

Commentaire
En pratique, il n’est pas possible pour un service de catalogage moissonné de distinguer un ensemble de métadonnées ne devant pas être moissonnées. Pour éviter de diffuser les métadonnées que l’on souhaite garder en interne, il est donc possible de créer deux nœuds CSW3 : un qui sera moissonné par le catalogue fédérateur, et l’autre qui servira en interne. Les deux nœuds peuvent attaquer le même entrepôt de métadonnées.

En complément, le catalogue « moissonneur » peut définir des filtres pour « trier » les métadonnées à importer. Les filtres possibles du catalogue « moissonneur » ne sont pas du ressort de l’administrateur.

Ceux-ci ne doivent donc pas influencer la manière de renseigner les métadonnées, d’autant que des catalogues moissonneurs différents peuvent définir des filtres différents.

L’interface graphique d’une application de catalogage offre une vue sur les métadonnées en « choisissant » les éléments à afficher à l’usager. Il n’est pas incohérent qu’un catalogue n‘affiche qu’un sous-ensemble des métadonnées descriptives d’une ressource, tandis qu’un autre affichera la totalité. En effet, les différents catalogues jouent potentiellement des rôles différents au sein de l’infrastructure nationale et les attentes des utilisateurs de ces catalogues peuvent varier. Par exemple, dans le Géocatalogue, seuls les éléments de métadonnées INSPIRE et quelques éléments ISO sont affichés à l’heure actuelle. En revanche, l’ensemble des informations de description sont accessibles dans le flux XML téléchargeable.

Au-delà d’INSPIRE, que ce soit au niveau régional ou national, les besoins d’échanges et de mutualisation s’accroissent. Les catalogues fédérateurs doivent donc pouvoir jouer leur rôle de nœud pour l’accès aux données. L’affichage de tous les détails des métadonnées des ressources disponibles sera fonction des catalogues.

Recommandations nationales :
1. Le besoin en métadonnées minimales pour le bon fonctionnement des IDG est celui documenté dans le guide de recommandation de saisie du CNIG.
2. L'usage interne exige parfois des métadonnées plus riches en information. Il est possible de gérer des métadonnées plus exhaustives pour une ressource au sein d’un catalogue local et d’utiliser les métadonnées de ce catalogue pour alimenter le catalogue fédérateur. Cependant, les éléments supplémentaires ne seront pas obligatoirement affichés dans le catalogue fédérateur.

La maintenance des métadonnées d’une ressource doit idéalement être centralisée, c’est-à-dire assurée au travers d’un unique catalogue puis répercutée sur les catalogues répliquant les métadonnées. Cela s’opère typiquement par moissonnage (la détection des mises à jour d’une fiche de métadonnées est alors réalisée grâce à la combinaison « même identificateur de ressource unique (URI), date des métadonnées différente »). La date des métadonnées mentionnée ici est bien la date de la métadonnée elle-même, et non de la ressource.

INSPIRE définit une classification thématique (les 34 thèmes des annexes I, II et III).

La concordance entre les thèmes INSPIRE et la manière d’organiser les séries en ensembles de séries de données diffusés n’est pas évidente à atteindre, notamment dans la phase initiale d’INSPIRE pour laquelle l’objectif est de répertorier les données existantes. Il faut donc préciser à quel niveau de regroupement des données il convient d’exprimer les métadonnées, avec un objectif à terme d’une concordance optimale avec les thèmes INSPIRE. L'objectif est de recourir sans ambigüité à la notion de « thème dominant », notamment pour faciliter la recherche des données existantes sur des critères thématiques.

Recommandations nationales :
1. Dans le cas de données (séries ou ensemble de séries) couvrant plusieurs thématiques INSPIRE, il est recommandé de les diviser en plusieurs ressources regroupant dans la mesure du possible les classes d’objets appartenant à un même thème.
2. La diffusion de métadonnées par thèmes INSPIRE est suffisante. Il n’est pas obligatoire de fournir des métadonnées par classe d’objets.

Exemples :
Pour la BD Carto® de l’IGN, qui est un produit multi-thème, l’IGN fournit une fiche de métadonnée BD Carto® thème Hydro, une fiche BD Carto® thème Administratif, etc…
Autre exemple : le plan parcellaire devrait séparer le PCI en 2 thèmes : parcelles cadastrales et bâtiments. Il n’est pas obligatoire de fournir des métadonnées différentes pour les éléments de mitoyenneté, les calvaires, etc…

Seuls trois types de ressources sont dans le champ de la directive INSPIRE :
1. Les séries de données géographiques,
2. Les ensembles de séries de données géographiques,
3. Les services de données géographiques.

Des métadonnées peuvent être fournies aux catalogues fédérateurs pour d’autres types de ressources. Dans ce cas, ces métadonnées ne seront pas incluses dans le rapportage INSPIRE.

Ces trois types de ressources peuvent être utilisés pour des ressources n’entrant pas dans le champ de la directive INSPIRE, puisqu’un autre élément de métadonnées (le thème INSPIRE, cf. guide de recommandations pour la saisie de métadonnées de données) permet de distinguer les ressources entrant dans le champ INSPIRE, de celles n’en faisant pas partie.

Les métadonnées de services seront traitées dans un guide particulier en raison de leur complexité particulière.

Un ensemble de séries de données est le résultat d'un « effort de production » particulier. Les données partagent des caractéristiques communes, par exemple grâce à des spécifications formalisées dans un document de type CCTP. Nota : nous préférons ce terme « effort de production » à la référence à une « spécification de produit », notamment parce qu'il n'y a pas toujours de telles spécifications pour les séries des thèmes de l'annexe III.

La série de données matérialise la diffusion du résultat l'effort de production. Une série de données est une unité de diffusion (un lot de données de diffusion) du résultat de l'effort de production. On trouvera ainsi les classes d'objets d’une base de données, la diffusion à une date de référence d'une base de données mise à jour en continu (édition 2011 de telle base), voire d’un thème ou sous-thème INSPIRE (ex : la couche Réseau de transport ferré).

La série de données a un caractère très concret pour l'utilisateur des données : c'est un ensemble cohérent de fichiers qui lui est mis à disposition sur un support informatique ou sur un espace de téléchargement. L'ensemble de séries correspond plus à une logique de gestionnaire qui veut maîtriser l'information géographique qui existe dans sa globalité (contenu, système de coordonnées, modalités de diffusion, mise à jour, …).

Il y a une complémentarité entre métadonnées de niveau « série » et « ensemble de séries ». Les métadonnées de niveau « ensemble de séries » permettent de rapidement identifier les principaux ensembles de données disponibles sur le territoire national. Les métadonnées de niveau « séries » permettent de confirmer la disponibilité de données à un niveau local.

Cette complémentarité peut se traduire au niveau de l’organisation des catalogues et des relations entre eux : on peut imaginer des situations où il est pratique que les métadonnées de niveau « ensemble de séries » soient disponibles sur le Géocatalogue, tandis que les métadonnées des séries individuelles sont répertoriées sur un catalogue local.

Exigence INSPIRE :
L’existence de données dans le champ d’INSPIRE peut être rapportée au niveau « série de données » et/ou au niveau « ensemble de séries de données ». (C'est-à-dire que l’on peut trouver
un ensemble de séries et les séries s’y rapportant,
une série ne se rapportant pas à un ensemble de séries,
ou un ensemble de séries sans série.)

Recommandations nationales :
1. Lors de la mise en place d’un effort de production, il est recommandé d’établir une métadonnée d’ensemble de série, puis, selon les besoins, d’en décliner les métadonnées de séries correspondant aux besoins de diffusion (classes d’objets, période temporelle, etc.)
2. Dans les cas où les deux niveaux de métadonnées cohabitent au sein d’un catalogue local, il est possible de faire remonter au catalogue fédérateur uniquement les métadonnées de niveau « ensemble de séries », à la condition de pouvoir opérer les services de visualisation et de téléchargement sur toutes les données de l’ensemble de séries, c'est-à-dire, qu’il existe des métadonnées de service associées à la métadonnée d’ensemble de série.
3. Lorsque des métadonnées sont créées dans un catalogue local pour des données futures, il est recommandé de ne pas les faire remonter au catalogue fédérateur.
4. Il est recommandé d’éviter de créer des métadonnées pour une granularité spatiale inférieure à celle de la production ou de la diffusion. Par exemple, il n’est pas utile de mettre en place et de publier des métadonnées par commune si les données sont produites et diffusées en bloc départemental.

Commentaire
La recommandation 2 implique que si l’on a les deux niveaux de métadonnées et que les services de visualisation et téléchargement ne peuvent pas être opérés sur le niveau « ensemble de séries », on doit alors faire remonter les métadonnées de séries de données au catalogue fédérateur. Dans ce cas les deux niveaux de métadonnées peuvent être remontés au catalogue fédérateur.

Le CRAIG a réalisé une orthophotographie pour couvrir les agglomérations de l'Allier en 2009.

• une prise de vues pour l'agglomération de Montluçon,
• une prise de vues pour l'agglomération de Vichy,
• une prise de vues pour l'agglomération de Moulins,

Les spécifications sont identiques : même résolution, même dévers, même avion, même caméra …

Compte-tenu des recommandations établies, le CRAIG devrait-il saisir :

• une métadonnée « ensemble de série de données » pour l'orthophotographie agglomérations 2009 ?
• une métadonnée « série de données » pour chaque campagne de prise de vues: une pour l'agglomération de Moulins, une pour l'agglomération de Vichy et une pour l'agglomération de Montluçon. ?

Réponse : Les métadonnées de séries existant déjà pour la couverture de chaque agglomération, on ne demande pas, dans ce cas-là, de créer des métadonnées d’ensemble de séries pour l’ortho « agglomérations 2009 ». Pour les futures campagnes, il est recommandé de créer les métadonnées de l’ensemble des séries, puis d’en dériver les métadonnées de séries selon les diffusions.

L'orthophotographie, bien que diffusée également au niveau communal, ne fera pas l'objet de métadonnées de série de données pour les communes des agglomérations.

Réponse : Nous rappelons que chaque série diffusée devrait être accompagnée de métadonnées adaptées. Le catalogage de ces métadonnées de séries diffusées n’est pas nécessaire car elles n'apportent pas d'informations supplémentaires par rapport aux métadonnées de séries ou d’ensemble de séries déjà existantes.

Actuellement, nous n'avons pas saisi de métadonnées d'ensemble de série de données, nous ne comprenons pas l'intérêt de produire cette métadonnée « ensemble de séries de données ».

Réponse : L’intérêt de cette notion est notamment une factorisation de l’effort fourni par l’administrateur : l’intérêt des métadonnées d’ensemble de séries est de les créer d’abord, puis d’en dériver des métadonnées des séries. Cela représente une économie de saisie, améliore la cohérence en limitant les interventions manuelles. De plus, cela devrait également être une aide pour l’utilisateur du catalogue/moteur de recherche : le moteur de recherche pourrait présenter dans un premier temps les métadonnées d’ensemble de séries disponibles de sorte à ne pas noyer l’utilisateur avec la totalité des métadonnées de séries.

Interrogation supplémentaire, doit on établir une relation parent/enfant entre une métadonnée « ensemble de série de données » et une métadonnée de série de données ?

Réponse : C’est recommandé. Le lien enfant–>parent se fait en utilisant le champ identificationInfo.citation.series de la norme ISO 19115 dans les métadonnées de séries et en y fournissant l’identifiant de ressource unique de la métadonnée d’ensemble de série. Le lien parent-enfant est réalisé en faisant une requête sur les métadonnées d’ensembles de série qui ont pour identifiant de ressource unique celui inscrit dans le champ identificationInfo.citation.series de l’enfant.

Ce terme recouvre principalement la gestion des métadonnées devant accompagner la diffusion d’une extraction réalisée selon un découpage territorial inférieur à celui de l’effort de production.
Les pratiques étant diverses, il n’a pas été possible d’obtenir un consensus au sein du Groupe métadonnées sur les recommandations relatives à ces métadonnées. Il est simplement rappelé que, dans l’idéal, chaque subdivision d’un produit existant devrait être accompagnée des métadonnées adaptées.

Recommandations nationales :
1. Il est recommandé de limiter au maximum le nombre de services mis en œuvre.
2. Dans la mise en œuvre de la recommandation précédente, il est recommandé de tenir compte de la capacité du service à s’adapter à certains usages, s’ils sont ciblés. Ainsi, mettre un grand nombre de couches dans un seul service augmente la taille du GetCapabilities du service, ce qui peut entrainer des difficultés liées à des débits ou des ressources limités pour certains clients (applications mobiles par exemple).

Commentaire :
La maintenance d’un service par couche est plus consommatrice de ressource et plus chère. En particulier dans le cas d’un service de téléchargement simple (HTTP/GET), il est recommandé de mettre en place une seule métadonnée de service pour l’ensemble des données téléchargeables.

Cette annexe explicite la mise en œuvre du gabarit français de métadonnées INSPIRE pour les séries et ensemble de séries de données géographiques établi dans le guide de recommandations pour la saisie de métadonnées de données du CNIG conformément à la norme ISO 19115. Elle est destinée aux administrateurs de métadonnées, ainsi qu’aux organisations possédant déjà des métadonnées existantes conformes à ISO 19115 et voulant s’assurer de leur compatibilité avec les recommandations françaises.

Elle complète le guide de saisie des métadonnées selon le gabarit français des métadonnées INSPIRE.

ISO 19115 autorise la description de plusieurs ressources différentes au sein d’un jeu de métadonnées (c'est-à-dire plusieurs instances de la propriété identificationInfo, et de manière corollaire plusieurs instances de la propriété hierarchyLevel, de MD_Metadata). La mise en œuvre d’INSPIRE peut s’envisager en utilisant cette possibilité offerte par ISO 19115, mais cette pratique n’est pas recommandée.

Recommandations nationales :
1. Une seule ressource (série ou ensemble de séries) est documentée dans un jeu de métadonnées ISO 19115, ce qui induit la présence d’une seule instance des propriétés identificationInfo et hierarchyLevel de MD_Metadata).
2. En termes d’interopérabilité, si un jeu de métadonnées ISO 19115 décrit plusieurs ressources, seule la première est prise en compte (typiquement, seule la première occurrence des instances des propriétés identificationInfo et hierarchyLevel de MD_Metadata est prise en compte).

Pour quelques-uns des éléments de métadonnées INSPIRE, une liste de valeurs est prédéfinie. Pour chacune de ces listes, INSPIRE donne un nom dans la langue du document, un nom en « langage neutre » et la définition.

Le « langage neutre » est à utiliser pour la valeur qui doit être fournie dans le fichier de métadonnée ISO 19115, afin de permettre une interopérabilité, notamment avec les pays voisins. La casse et l’orthographe sont très importantes pour ce langage neutre, qui doit être interprétable par une machine.

En revanche, il est souhaitable que lors de la saisie de nouvelles métadonnées, les éditeurs de métadonnées puissent proposer le nom de la valeur dans la langue de l’utilisateur (p.e., français) au moyen d’un menu déroulant par exemple et un mécanisme permettant à l’utilisateur d’accéder à la définition de chaque valeur dans cette langue.

Exemple : les types de services de métadonnées :

Les différents encadrés ci-dessous précisent, pour chaque section de ISO 19115, les propriétés à remplir et leur correspondance avec les éléments INSPIRE. Les éléments dont l’implémentation nécessite des précisions supplémentaires sont détaillés dans la partie suivante.

Un jeu de métadonnées est une instance de la classe MD_Metadata (ISO 19115) ou d’une de ses spécialisations.

Cette instance doit présenter au moins les propriétés suivantes :
+ language [1] : LanguageCode…………………………………Langue des métadonnées, par défaut « fre ». cf. C.4.5.1
+ characterSet [1] : MD_CharacterSetCode…………………………Jeu de caractères des métadonnées
+ hierarchyLevel [1] : MD_ScopeCode …………………………….Type de la ressource. Cf. C.1.1
+ contact [1..*] : CI_ResponsibleParty ………………………….Point de contact des métadonnées cf. C.3.4.2
+ dateStamp [1] : Date ………………………………………..Date des métadonnées
+ identificationInfo [1] : MD_Identification …………………….cf. C.3.2 et C.4.1
+ distributionInfo [0..*] : MD_Distribution………………………Cf. C.3.6
+ dataQualityInfo [0..*] : DQ_DataQuality ……………………….Cf. C.3.3
+ referenceSystemInfo [0..*] : MD_ReferenceSystem…………………Système de référence de coordonnées et système de référence temporel
+ referenceSystemIdentifier [1] : RS_Identifier
+ code [1] : Anchor……………………………………………Le code du système de référence
+ href [1] : URI………………………………………………L’URL vers le registre de systèmes de référence
+ codeSpace [1] : CharacterString……………………………….L’espace de nommage du code

Note : le jeu de caractères des métadonnées n’est pas demandé par INSPIRE, mais c’est un élément obligatoire dans ISO 19115. Il devrait donc être rempli par défaut par les outils éditeurs de métadonnées.

Si le type de la ressource est « série » ou « ensemble de série », une instance de MD_DataIdentification doit être fournie pour la propriété identificationInfo (cf 2.3.1).
+ citation [1] : CI_Citation
+ title [1] : CharacterString…………………………………………………..Intitulé de la ressource
+ date [0..*] : CI_Date…………………………………………………………Cf. note 1
+ date [1] : Date……………………………………………………………Date de publication
+ dateType [1] : CI_DateTypeCode ………………………………..publication
+ date [0..1] : CI_Date ………………………………………………………..Cf. notes 1 et 2
+ date [1] : Date……………………………………………………………Date de dernière révision
+ dateType [1] : CI_DateTypeCode ………………………………..revision
+ date [0..1] : CI_Date ………………………………………………………..Cf. note 1
+ date [1] : Date……………………………………………………………Date de création
+ dateType [1] : CI_DateTypeCode ………………………………..creation
+ identifier [1..*] : RS_Identifier ……………………………………………Identificateur de ressource unique. Cf.C.4.1.1
+ code [1] : CharacterString …………………………………………..Ceci est l’identificateur
+ codeSpace [0..1] : CharacterString……………………………….Ceci est l’espace de noms (optionnel)
+ abstract [1] : CharacterString ………………………………………………….Résumé de la ressource
+ pointOfContact [1..*] : CI_ResponsibleParty ……………………………..Organisation responsable (Cf. C.3.4.1)
+ descriptiveKeywords [1..*] : MD_Keywords
+ keyword [1..*] : CharacterString………………………………………….Valeur du mot clé (Cf. C.4.2)
+ thesaurusName [0..1] : CI_Citation …………………………………….Vocabulaire contrôlé d’origine (Cf. C.4.2)
+ title [1] : CharacterString ……………………………………………..Titre du vocabulaire contrôlé d’origine
+ date [1] : CI_Date ……………………………………………………….Date de référence
+ date [1] : Date ………………………………………………………Date
+ dateType [1] : CI_DateTypeCode…………………………….Type de date (publication, revision ou creation)
+ resourceConstraints [1..*] : MD_Constraints …………………………….Contraintes en matière d’accès et d’utilisation (Cf. C.3.5 et C.4.4).
+ spatialResolution [0..*] : MD_Resolution……………………………………Résolution spatiale cf.Note 3
+ distance [0..1] : Distance ………………………………………………….distance de résolution
+ spatialResolution [0..*] : MD_Resolution……………………………………Résolution spatiale cf. Note 3
+ equivalentScale [0..1] : MD_RepresentativeFraction
+ denominator [1] : Integer……………………………………………..dénominateur de l’échelle équivalente
+ language [1..*] : LanguageCode ……………………………………………..Langue de la ressource (cf. C.4.1.2)
+ characterSet [1..*] : MD_CharacterSetCode …………………………….Jeu de caractère utilisé dans la ressource cf. D
+ extent [1] : EX_Extent ……………………………………………………………cf. Note 4
+ geographicElement [1..*] : EX_GeographicBoundingBox ……..Rectangle de délimitation géographique
+ westBoundLongitude [1] : Decimal
+ eastBoundLongitude [1] : Decimal
+ southBoundLatitude [1] : Decimal
+ northBoundLatitude [1] : Decimal
+ temporalElement [0..*] : EX_TemporalExtent
+ extent [1] : TM_Primitive …………………………………………….Etendue temporelle
+ topicCategory [1..*] : MD_TopicCategory ………………………………..Catégorie thématique

Notes:
1. Il peut y avoir plusieurs instances de la propriété date (publication création ou révision…). L’ordre de ces instances n’est pas déterminé.
2. Des métadonnées existantes peuvent présenter plusieurs dates de révision. Dans ce cas, la date la plus récente est la date de dernière révision INSPIRE.
3. MD_Resolution est un type de donnée “union”, ce qui veut dire qu’il contient soit une propriété “distance”, soit une propriété “echelle équivalente”, mais pas les deux à la fois. Il est possible de fournir les deux informations en ayant deux instances de spatialResolution.
4. Dans le cas de métadonnées existantes, il peut y avoir plusieurs instances de extent. L’instance définissant le rectangle de délimitation géographique n’est pas nécessairement la première. Elle peut contenir également l’étendue temporelle.

ISO 19115 permet la définition de plusieurs ensembles d’information de qualité (c'est-à-dire plusieurs instances de DQ_DataQuality), concernant chacune une partie ou la totalité de la ressource, et pouvant chacune fournir des informations de généalogie et des résultats d’évaluation de la qualité. Ce cas de figure peut donc apparaitre quand on manipule des métadonnées antérieures à l’application d’INSPIRE.
INSPIRE ne prend cependant en compte qu’une seule information de généalogie, qui doit donc concerner l’ensemble de la ressource décrite par les métadonnées, sans restrictions spatiale.

Recommandations nationales :
1. Une seule instance de DQ_DataQuality doit présenter un champ d’application (scope) fixé à l’ensemble de la ressource. Cette instance doit présenter un élément généalogie obligatoire, et un élément conformité si la conformité a été évaluée seulement.

Les propriétés de cet élément sont décrites ci-dessous :
+ scope [1] : DQ_Scope
+ level [1] : MD_ScopeCode…………………………………….. series pour un ensemble de séries, dataset pour une série,
+ extentl [0] : EX_Extent………………………………………….. Il ne doit pas y avoir de restriction sur l’étendue de la ressource, donc pas d’instance de cet élément
+ lineage [1] : LI_Lineage.
+ statement [1] : CharacterString……………………………… Généalogie
+ report [0..*] : DQ_Element……………………………………………Conformité Cf. C.4.3
+ measureIdentification[0..1] : MD_Identifier………………….. See note 3
+ result[1] : DQ_ConformanceResult
+ specification [1] : CI_Citation ………………………….. Spécification
+ explanation [1] : CharacterString …………………….. Cf. Note 2
+ pass [1] : Boolean …………………………………………. Degré (Cf. C.4.3.1)
+ report [0..*] : DQ_TopologicConsistency…………………………Cohérence Topologique
+ result[1] : DQ_ConformanceResult ou DQ_QuantitativeResult

Notes:
1. DQ_Element est une classe abstraite. Elle peut être instanciée au travers de l’une des sous-classes non abstraites. La classes à utiliser dépend du critère qualité concerné par la mesure. Par défaut, DQ_DomainConsistency peut être utilisé.
2. ISO 19115 exige une explication quant à la signification de la conformité pour le résultat exprimé. Une explication par défaut, du type « cf. la spécification citée » peut-être utilisée.
3. Cet élément de métadonnées contient l’identificateur de la mesure. Cet identificateur sera utilisé pour différencier les mesures qualité INSPIRE les unes par rapport aux autres ainsi que par rapport à des mesures qualité sortant du cadre d’INSPIRE.

Cette information est fournie dans ISO 19115 au travers de la classe CI_ResponsibleParty, qui décrit les informations nécessaire pour l’identification de l’organisation responsable. Les propriétés exigées par INSPIRE sont les suivantes :
+ organisationName[1] : CharacterString……………………….Nom de l’Organisation Responsable
+ contactInfo[1] : CI_Contact
+ address[1..*] : CI_Address
+ electronicEmailAddress [1..*] : CharacterString.. Au moins une adresse e-mail
+ role[1] : CI_RoleCode …………………………………………….. Le rôle joué par l’organisation vis à vis de la ressource

Le point de contact des métadonnées est également fourni au travers une instance de la classe MD_ResponsibleParty :
+ organisationName[1] : CharacterString………………………..Nom du point de contact pour les Métadonnées
+ contactInfo[1] : CI_Contact
+ address[1..*] : CI_Address
+ electronicEmailAddress [1..*] : CharacterString… Au moins une adresse e-mail
+ role[1] : CI_RoleCode ……………………………………………….Requis par Iso 19115 – valeur par défault : « pointOfContact »

ISO 19115 fait la distinction entre des contraintes générales, des contraintes légales et des contraintes de sécurité, implémentées selon trois classes: MD_Constraints, MD_LegalConstraints et MD_SecurityConstraints.

Des instances de ces trois classes peuvent être rencontrées. Voir C.4.4 pour plus de détails sur l’implémentation recommandée au niveau national et des exemples.
+ resourceConstraint [1..*] : MD_LegalConstraints
+ useLimitation [0..*] : CharacterString ……………………………Conditions applicable à l’accès et l’utilisation
+ accessConstraints [1] : MD_RestrictionCode………………….otherRestrictions (Pour pouvoir utiliser le champ otherConstraints)
+ accessConstraints [0..1] : MD_RestrictionCode……………..restricted (si restriction il y a) sinon cette instance de accessConstraint n’est pas implémentée
+ accessConstraints [0..*] : MD_RestrictionCode……………….renseignements complémentaires de type « brevet ». Valeurs possibles : la codelist du Tableau 3 du guide de recommandations nationales sauf « restricted »
+ otherConstraints [1..*] : CharacterString………………………….une des valeurs proposées par le Tableau 2 du guide de recommandations nationales

+ resourceConstraint [0..*] : MD_SecurityConstraints
+ useLimitation [0..*] : CharacterString …………………………………..Conditions applicable à l’accès et l’utilisation
+ classification[1] : MD_ClassificationCode……………………………..les valeurs proposé dans le tableau 1 dans le cas de contraintes de sécurité
+ resourceConstraint [0..*] : MD_Constraints
+ useLimitation [0..*] : CharacterString …………………………………..Conditions applicable à l’accès et l’utilisation

Note : L’ordre des instances de « accessConstraints » est indifférent.

Le localisateur de la ressource ainsi que l’encodage sont fournis à travers une instance de la classe MD_DistributionInfo :
+ transferOptions [1..*] : MD_DigitalTransferOptions
+ online [1..*] : CI_OnlineResource
+ linkage [1]: URL ……………………………………Localisateur de la ressource. Cf. Note
+ distributionFormat [0..*] : MD_Format…………………….Encodage
+ name [1] : CharacterString……………………………Nom de l’encodage
+ version [1]: CharacterString …………………………Version de l’encodage

Note : Bien que la multiplicité de la propriété linkage soit fixé à 1 par l’ISO 19115, il est possible de fournir plusieurs Localisateur de la Ressource (comme proposé par INSPIRE) en utilisant la cardinalité multiple des propriétés distributionInfo, transferOptions ou online.

Si seul un code est fourni (et pas d’espace de noms) alors il est possible d’utiliser le type de donnée MD_Identifier, au lieu de RS_Identifier.

Recommandations nationales :
1. Le domaine de valeur pour cet élément est la liste de codes « LanguageCode » définie par ISO 19139.

Recommandations nationales :
1. Lorsque plusieurs mots-clés proviennent de la même version du même thésaurus, ceux-ci devraient être groupés dans une seule instance de la propriété descriptiveKeywords.

Exemple :
+ descriptiveKeywords : MD_Keywords
+ keyword : CharacterString………………………………………………….forêts
+ keyword : CharacterString………………………………………………….landes
+ thesaurusName : CI_Citation
+ title : CharacterString ………………………………………………….GEMET- Concepts version 2.4
+ date : CI_Date
+ date : Date …………………………………………………………..2010-01-13
+ dateType : CI_DateTypeCode…………………………………publication
+ descriptiveKeywords : MD_Keywords
+ keyword : CharacterString………………………………………………….occupation des terres
+ thesaurusName : CI_Citation
+ title : CharacterString ………………………………………………….GEMET- INSPIRE themes version 1.0
+ date : CI_Date
+ date : Date ……………………………………………………………2008-06-01
+ dateType : CI_DateTypeCode…………………………………publication

La norme ISO 19115 ne permet de fournir une information sur la conformité de la donnée que si celle-ci a été évaluée, ce qui induit une gestion particulière du niveau « pas évalué » du règlement sur les métadonnées INSPIRE.

Recommandations nationales :
1. Si la conformité est évaluée, l’information peut être conservée en ISO 19115 conformément à l’implémentation décrite en 2.3.3.
2. Si la conformité n’a pas été évaluée, l’information ne doit pas être renseignée ! Cette absence d’information équivaut dans ISO 19115 à dire que la conformité n’a pas été évaluée. Dans ce dernier cas, il serait souhaitable que les visualisateurs de métadonnées affichent l’information de non-évaluation de la conformité aux spécifications listées à l’annexe A du guide de recommandation.

L’élément de métadonnées Degré est implémenté sous la forme d’un booléen dans ISO 19115.

Recommandations nationales :
1. Le degré de conformité peut être « conforme » ou « non conforme », ce qui correspond aux valeurs « true » et « false » de l’attribut « pass » de ISO 19115.

Les informations de contraintes prévues par ISO 19115 ont une sémantique différente, plus générale, et offrant plus de possibilités, que celles demandées par INSPIRE.

Un problème se pose lorsqu’une organisation a déjà des métadonnées existantes utilisant les différentes possibilités fournies par l’ISO 19115, mais aussi lorsqu’une organisation veut fournir plus d’informations que celles demandées par INSPIRE.

Par exemple, ISO 19115 permet de fournir des informations formalisées exprimant que le produit concerné est sous license, sous copyright ou sous brevet ou fait l’objet de droit de propriété intellectuelle.

Or un des cas de restrictions de l’accès public INSPIRE est justifié par les droits de propriété intellectuelle, ce qui implique que si quelqu’un a indiqué dans une métadonnée ISO 19115 « intellectualPropertyRights », cela risque d’être interprété immédiatement dans le contexte INSPIRE comme une restriction de l’accès public, ce qui n’est pas forcément l’intention de base.

Recommandations nationales :
1. Une instance de l’élément de métadonnées INSPIRE – Restrictions de l’accès public sera identifiée par la combinaison de :

• la propriété accessConstraints fixée à restricted,
• la propriété otherConstraints avec l’utilisation d’une des valeurs de la liste du Tableau 2.

Commentaires :
Si des métadonnées existantes présentent l’un ou l’autre de ces éléments, ceux-ci ne pourront être considérés comme une instance de l’élément INSPIRE « Restrictions concernant l’accès public ».

Le Tableau 1 du guide du guide de recommandations nationales définit 3 cas correspondant à ces trois types de contraintes. Ces trois cas sont déclinés ci-dessous.

Le champ « conditions applicables à l’accès et l’utilisation » explicite les conditions dans lesquelles il est possible d’obtenir la ressource (frais éventuels etc.).

L’élément INSPIRE « restriction d’accès public » grâce à la combinaison de la valeur « restricted » dans le champ « accesConstraint » et de la référence à l’article de loi précisant la raison de la restriction dans le champ « otherConstraint ». La liste des valeurs possibles pour ce champ est fournie dans le Tableau 2 du guide de recommandations nationales.

En pratique :
+ resourceConstraint [1..*] : MD_LegalConstraints
+ useLimitation [0..*] : CharacterString ……………………………Conditions applicable à l’accès et l’utilisation
+ accessConstraints [1] : MD_RestrictionCode………………….otherRestrictions (Pour pouvoir utiliser le champ otherConstraints)
+ accessConstraints [0..1] : MD_RestrictionCode……………….restricted (si restriction il y a) sinon cette instance de accessConstraint n’est pas implémentée
+ accessConstraints [0..*] : MD_RestrictionCode……………….renseignements complémentaires de type « brevet ». Valeurs possibles : la codelist du Tableau 3 sauf « restricted »
+ otherConstraints [1..*] : CharacterString………………………….une des valeurs proposées par le Tableau 2

Une instance de resourceConstraint de type SecurityConstraint doit être implémentée si le niveau de classification est différent de « unclassified ».

En pratique :
+ resourceConstraint [0..*] : MD_SecurityConstraints
+ useLimitation [0..*] : CharacterString …………………………………..Conditions applicable à l’accès et l’utilisation
+ classification[1] : MD_ClassificationCode……………………………..les valeurs proposé dans le tableau 1 dans le cas de contraintes de sécurité

Dans le troisième cas, seule une information de type conditions d’usage (ex : donnée impropre à la navigation) est proposée au travers du champ « condition d’accès et d’utilisation ».

En pratique :
+ resourceConstraint [0..*] : MD_Constraints
+ useLimitation [0..*] : CharacterString …………………………………..Conditions applicable à l’accès et l’utilisation

Cas simple
Il n’y a pas de restriction d’accès public à la donnée. L’élément INSPIRE « Conditions applicable à l’accès et l’utilisation » est fixé à « aucune condition ne s’applique » et on indique qu’il n’y a pas de restriction à l’accès public en ajoutant la valeur correspondante du Tableau 2 du guide de recommandation (« Pas de restriction d’accès public selon INSPIRE »).

+ resourceConstraint : MD_LegalConstraints
+ useLimitation : CharacterString ………………………………….aucune condition ne s’applique
+ accessConstraints : MD_RestrictionCode……………………otherRestrictions.
+ otherConstraints : CharacterString………………………………Pas de restriction d’accès public selon INSPIRE

Ici, la propriété accessConstraint est implémentée (valeur « other ») afin de pouvoir renseigner le champ otherRestriction, dans lequel la mention « Pas de restrictions de l’accès public » est fournie.

A cet exemple, on peut ajouter une instance de accessConstraint, permettant de préciser que le produit est sous licence :

+ resourceConstraint : MD_LegalConstraints
+ useLimitation : CharacterString ………………………………….La donnée est accessible selon les conditions décrites sur le site http://...
+ accessConstraints : MD_RestrictionCode……………………license
+ accessConstraints : MD_RestrictionCode……………………otherRestrictions.
+ otherConstraints : CharacterString………………………………Pas de restriction d’accès public selon INSPIRE

On peut également ajouter un élément de type contrainte d’usage :

+ resourceConstraint : MD_Constraints
+ useLimitation : CharacterString ………………………………….La donnée est impropre à la navigation
+ resourceConstraint : MD_LegalConstraints
+ useLimitation : CharacterString ………………………………….La donnée est accessible selon les conditions décrites sur le site http://...
+ accessConstraints : MD_RestrictionCode……………………license
+ accessConstraints : MD_RestrictionCode……………………otherRestrictions.
+ otherConstraints : CharacterString………………………………Pas de restriction d’accès public selon INSPIRE

Cas de l’existence d’une restriction d’accès public de type « légal » :

Il y a une restriction d’accès public en raison de la protection de l’environnement :

+ resourceConstraint : MD_LegalConstraints
+ useLimitation : CharacterString ………………………………….Seules les conditions suivantes peuvent permettre l’accès à la ressource : <conditions>
+ accessConstraints : MD_RestrictionCode……………………restricted
+ accessConstraints : MD_RestrictionCode……………………otherRestrictions.
+ otherConstraints : CharacterString……………………………..L124-4-I-2 du code de l’environnement (Directive 2007/2/CE (INSPIRE), Article 13.1.h)

Cas de l’existence d’une contrainte de sécurité :

Il y a une restriction d’accès public à la donnée (ce cas est théorique et ne devrait la plupart du temps pas être rencontré) :

+ resourceConstraint : MD_SecurityConstraints
+ useLimitation : CharacterString ………………………………….. Seules les conditions suivantes peuvent permettre l’accès à la ressource : <conditions>
+ classification : MD_ClassificationCode………………………….confidential
+ resourceConstraint : MD_LegalConstraints
+ accessConstraints : MD_RestrictionCode……………………..restricted.
+ accessConstraints : MD_RestrictionCode……………………..otherRestrictions.
+ otherConstraints : CharacterString……………………………….L124-5-II-1 du code de l’environnement (Directive 2007/2/CE (INSPIRE), Article 13.1.b)

Cas particulier de la propriété intellectuelle.

Une clause de propriété intellectuelle est renseignée, sans pour autant que celle-ci implique une restriction d’accès public à la donnée :

+ resourceConstraint : MD_LegalConstraints
+ useLimitation : CharacterString …………………………………La donnée est accessible selon les conditions décrites sur le site http://...
+ accessConstraints : MD_RestrictionCode……………………intellectualPropertyRights
+ accessConstraints : MD_RestrictionCode……………………otherRestrictions.
+ otherConstraints : CharacterString……………………………..Pas de restriction d’accès public selon INSPIRE

Il y a une restriction de l’accès public, justifiée uniquement par des droits de propriété intellectuelle :

+ resourceConstraint : MD_LegalConstraints
+ useLimitation : CharacterString …………………………………La donnée est accessible selon les conditions décrites sur le site http://...
+ accessConstraints : MD_RestrictionCode……………………restricted.
+ accessConstraints : MD_RestrictionCode……………………intellectualPropertyRights
+ otherConstraints : CharacterString……………………………..L124-5-II-3 du code de l’environnement (Directive 2007/2/CE (INSPIRE), Article 13.1.e)

Il y a une restriction de l’accès public, justifiée par une autre raison que des droits de propriété intellectuelle (par exemple, la protection de l’environnement). Une clause de propriété intellectuelle est également renseignée (sans que ce soit elle qui justifie la restriction d’accès public) :

+ resourceConstraint : MD_LegalConstraints
+ useLimitation : CharacterString …………………………………La donnée est accessible selon les conditions décrites sur le site http://...
+ accessConstraints : MD_RestrictionCode……………………intellectualPropertyRights
+ accessConstraints : MD_RestrictionCode……………………restricted.
+ accessConstraints : MD_RestrictionCode……………………otherRestrictions.
+ otherConstraints : CharacterString……………………………..L124-4-I-2 du code de l’environnement (Directive 2007/2/CE (INSPIRE), Article 13.1.h)


Il y a une restriction de l’accès public, justifiée à la fois par des droits de propriété intellectuelle et une autre raison. Dans ce cas, il est recommandé d’utiliser la valeur proposée dans le tableau ci-dessus, afin de se distinguer du cas précédent :

+ resourceConstraint : MD_LegalConstraints
+ useLimitation : CharacterString …………………………………La donnée est accessible selon les conditions décrites sur le site http://...
+ accessConstraints : MD_RestrictionCode……………………restricted.
+ accessConstraints : MD_RestrictionCode……………………intellectualPropertyRights
+ accessConstraints : MD_RestrictionCode……………………otherRestrictions.
+ otherConstraints : CharacterString……………………………..L124-4-I-2 du code de l’environnement (Directive 2007/2/CE (INSPIRE), Article 13.1.h)
+ otherConstraints : CharacterString……………………………..L124-5-II-3 du code de l’environnement (Directive 2007/2/CE (INSPIRE), Article 13.1.e)

Recommandations nationales :
1. Le domaine de valeur pour cet élément est la liste de codes « LanguageCode » définie par ISO 19139.

Cet élément de métadonnées précise le jeu de caractère utilisé pour l’encodage (numérique) de la ressource. ISO 19115 stipule que cet élément est obligatoire dès lors que la norme ISO/IEC 10646-1 n’est pas utilisée. Cet élément peut alors être choisi parmi la liste de codes suivante :
(insérer tableau)

Ces recommandations devraient être suivies par les logiciels permettant l’édition des métadonnées.

1. Les outils doivent permettre de gérer correctement le moissonnage à partir des URI renseignés dans les balises identificationInfo.citation.identifier/MD_Identifier des fichiers XML ISO 19139. (Le guide de recommandations pour la saisie de métadonnées de données recommande la mise en place d’une URL pour l’identifiant unique de la ressource).
2. Au sein d’un catalogue, les outils doivent donner la possibilité de signaler les métadonnées destinées à être moissonnées
3. Les éditeurs doivent permettre le lien enfant→parent en exploitant le champ identificationInfo.citation.series.
4. Les outils doivent permettre le paramétrage de plusieurs services de catalogage (c'est-à-dire plusieurs nœuds CSW au sein du même outil).

1. Quand la directive INSPIRE ou les recommandations nationales fournissent une liste de valeurs possibles pour un champ libre ISO, un logiciel éditeur de métadonnées devrait proposer un menu déroulant listant les valeurs possibles.
2. Pour une liste de code, les valeurs proposées à l’utilisateur dans l’interface de saisie doivent être en français. En revanche, les valeurs stockées dans les métadonnées ISO 19115 doivent correspondre au code ISO ou à la valeur neutre INSPIRE.
3. Les logiciels permettant la visualisation des métadonnées INSPIRE doivent permettre l’affichage de tous les éléments de métadonnées INSPIRE, y compris les champs facultatifs définis dans les spécifications de données des Annexes 15.

4. Il est recommandé que les outils d’édition des métadonnées mettent à disposition des utilisateurs un choix de formats pour lesquels les informations de nom et de version soient remplies automatiquement.

5. Il est recommandé que les outils d’édition des métadonnées mettent à disposition des utilisateurs un ensemble pertinent de thésaurus (vocabulaires contrôlés d’origine) et pour chaque thésaurus une liste de valeurs possibles applicables de manière à simplifier la saisie et l’usage des métadonnées

6. La saisie suit la coutume française de signifier les nombres décimaux à l’aide d’une virgule. Le stockage suivra la norme ISO 19139.

7. Il est recommandé que les outils d’édition des métadonnées mettent à disposition des utilisateurs un menu déroulant présentant la liste des codes EPSG, afin de faciliter la saisie des métadonnées.

8. L’élément “maintenant” est une valeur indéterminée définie par la norme ISO 19108 et ayant pour code “now”. Ce code devra pouvoir être utilisé par les utilisateurs.
9. Le calendrier grégorien doit être rempli grégorien par défaut comme valeur du système de référence temporelle.

10. Le gabarit de saisie sera simplifié en proposant la liste des modèles de données d’INSPIRE (voir en Annexe A et Annexe B du guide de recommandations pour la saisie de métadonnées de données).
11. En pratique, la valeur « non évaluée » n’est pas stockée dans les métadonnées. L’absence d’indication de conformité par rapport aux spécifications INSPIRE implique la non-évaluation, dans le cadre de métadonnées INSPIRE (c'est-à-dire métadonnées citant le thésaurus GEMET-INSPIRE themes). Cf. le guide administrateur et le mapping INSPIRE/ISO 19115 pour plus de détails.