Skip to content

Recommandations ISO DCAT

Jump to bottom
streino edited this page Feb 4, 2025 · 7 revisions

Adaptation des métadonnées ISO 19139 pour faciliter la transformation en DCAT.

Introduction

Le présent document vise à établir une liste de préconisations sur la structuration des fiches de métadonnées ISO 19139 permettant d'assurer que leur transformation en DCAT par le XSLT GeoDCAT-AP v2.0 préserve les métadonnées essentielles pour data.gouv.fr.

Ces préconisations s'appuient autant que possible sur les règles et recommandations du guide technique INSPIRE et du guide de saisie du CNIG. Des restrictions supplémentaires peuvent cependant découler de la transformation GeoDCAT-AP v2.0 elle-même, qui ne prend pas toujours en considération toutes les possibilités offertes par le guide technique.

Les préconisations sont minimalistes, c'est-à-dire qu'elles ne reprennent pas les contraintes qui ne sont pas absolument nécessaires au bon déroulé de la transformation, quand bien même leur respect s'impose et présente une utilité par ailleurs. Pour l'heure, seul un petit nombre d'éléments de métadonnées jugés prioritaires a été considéré. De nouvelles préconisations sont susceptibles d'être ajoutées à mesure de l'avancée des travaux pour l'intégration des métadonnées INSPIRE dans data.gouv.fr.

Recommandations

Veiller à ce que les jeux de données soient reconnaissables comme tels

➡️ XSLT (doc).
➡️ Discussion.

Préconisations

La fiche de métadonnées doit contenir un élément gmd:hierarchyLevel/gmd:MD_ScopeCode avec un attribut codeListValue valant "dataset", "series" ou "nonGeographicDataset".

Exemple :

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd">
  ...
  <gmd:hierarchyLevel>
    <gmd:MD_ScopeCode codeListValue="dataset" codeList="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_ScopeCode">dataset</gmd:MD_ScopeCode>
  </gmd:hierarchyLevel>
  ...
</gmd:MD_Metadata>

Références

Le guide technique INSPIRE impose la présence de cet élément, avec la valeur "dataset" ou "series" pour codeListValue.

TG Requirement 1.1: metadata/2.0/req/datasets-and-series/resource-type

The resource type shall be declared as "dataset" or "series" using the first gmd:hierarchyLevel child element of gmd:MD_Metadata. The gmd:hierarchyLevel shall contain a gmd:MD_ScopeCode element.

Cette obligation est reprise dans le guide de saisie du CNIG.

Présenter des identifiants de jeux de données exploitables

➡️ Discussion.

Préconisations

Il est conseillé de représenter les identifiants de ressource unique avec un élément gmd:citation/gmd:CI_Citation/gmd:identifier/gmd:MD_Identifier/gmd:code/gco:CharacterString.

Exemple :

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco">
  ...
  <gmd:identificationInfo>
    <gmd:MD_DataIdentification>
      <gmd:citation>
        <gmd:CI_Citation>
          ...
          <gmd:identifier>
            <gmd:MD_Identifier>
              <gmd:code>
                <gco:CharacterString>https://registry.gdi-de.org/id/de.ni.land.geobasisdaten/a6ff0d48-a557-4267-930d-a5b646e4787b</gco:CharacterString>  
              </gmd:code>
            </gmd:MD_Identifier>
          </gmd:identifier>
          ...
        </gmd:CI_Citation>
      </gmd:citation>
      ...
    </gmd:MD_DataIdentification>
  </gmd:identificationInfo>
  ...
</gmd:MD_Metadata>

Si un élément gmd:citation/gmd:CI_Citation/gmd:identifier/RS_Identifier est utilisé, alors la concaténation des valeurs de ses propriétés gmd:code et gmd:codeSpace doit produire une URI valide.

Exemple :

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco">
  ...
  <gmd:identificationInfo>
    <gmd:MD_DataIdentification>
      <gmd:citation>
        <gmd:CI_Citation>
          ...
          <gmd:identifier>
            <gmd:RS_Identifier>
              <gmd:code>
                <gco:CharacterString>a6ff0d48-a557-4267-930d-a5b646e4787b</gco:CharacterString>
              </gmd:code>
              <gmd:codeSpace>
                <gco:CharacterString>https://registry.gdi-de.org/id/de.ni.land.geobasisdaten</gco:CharacterString>
              </gmd:codeSpace>
            </gmd:RS_Identifier>
          </gmd:identifier>
          ...
        </gmd:CI_Citation>
      </gmd:citation>
      ...
    </gmd:MD_DataIdentification>
  </gmd:identificationInfo>
  ...
</gmd:MD_Metadata>

Références

Le guide technique INSPIRE requiert que l'identifiant du jeu de données soit une URI encodée sous la forme d'un élément gmd:citation/gmd:CI_Citation/gmd:identifier/MD_Identifier/gmd:code ou, comme le permet ISO 19139, d'un élément gmd:citation/gmd:CI_Citation/gmd:identifier/RS_Identifier/gmd:code.

TG Requirement 1.3: metadata/2.0/req/datasets-and-series/dataset-uid

A unique identifier shall be given for each described dataset or data sets series. This identifier shall be a URI consisting of a namespace uniquely identifying a naming context governed by an identifier authority, and a code unique within this namespace.

The identifying URI shall be encoded using gmd:citation/gmd:CI_Citation/gmd:identifier/*/gmd:code element with a Non-empty Free Text Element content.

The multiplicity of this element is 1..*.

Il recommande cependant fortement d'utiliser la première forme et ainsi de ne pas séparer l'espace de nommage du reste de l'URI.

TG Recommendation 1.2: metadata/2.0/rec/datasets-and-series/use_md_identifier

It is strongly recommended to use the MD_Identifier instead of the the RS_Identifier type and to encode the complete URI in the code element.

Le guide de saisie du CNIG recommande également la première forme.

L'encodage de la valeur de gmd:code avec un élément gco:CharacterString et non gmx:Anchor est une restriction imposée par la seule transformation GeoDCAT-AP v2.0.

Rendre les distributions identifiables

➡️ XSLT (doc).
➡️ Discussion.

Préconisations

Pour qu'une distribution ISO soit traitée comme une distribution DCAT (propriété dcat:distribution) et non comme un document (propriété dcat:landingPage ou foaf:page) lors de la transformation, il faut :

  • Soit qu'elle soit reconnue comme un service, c'est-à-dire que la valeur de l'élément gmd:url contienne 'request=getcapabilities'. Dans ce cas, l'objet dcat:Distribution aura une propriété dcat:accessService dont l'objet dcat:DataService portera l'essentiel des informations sur le service.
  • Soit qu'un élément gmd:function soit présent, avec l'une des valeurs 'download', 'offlineAccess' ou 'order'.

Exemple avec la première forme, pour un service WMS :

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco">
  ...
  <gmd:distributionInfo>
    <gmd:MD_Distribution>
      ...
      <gmd:transferOptions>
        <gmd:MD_DigitalTransferOptions>
          <gmd:onLine>
            <gmd:CI_OnlineResource>
              <gmd:linkage>
                <gmd:URL>https://ogc.geo-ide.developpement-durable.gouv.fr/wxs?map=/opt/data/carto/geoide-catalogue/1.4/org_4942761/23811dae-62cc-439c-bcf2-9159fe92cba2.internet.map&amp;service=WMS&amp;request=GetCapabilities</gmd:URL>
              </gmd:linkage>
              ...
              <gmd:name>
                <gco:CharacterString>Service WMS sur internet</gco:CharacterString>
              </gmd:name>
              ...
            </gmd:CI_OnlineResource>
          </gmd:onLine>
          ...
        </gmd:MD_DigitalTransferOptions>
      </gmd:transferOptions>
      ...
    </gmd:MD_Distribution>
  </gmd:distributionInfo>
  ...
</gmd:MD_Metadata>

Exemple avec la seconde forme, pour un service de téléchargement ATOM :

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco">
  ...
  <gmd:distributionInfo>
    <gmd:MD_Distribution>
      ...
      <gmd:transferOptions>
        <gmd:MD_DigitalTransferOptions>
          <gmd:onLine>
            <gmd:CI_OnlineResource>
              <gmd:linkage>
                <gmd:URL>https://atom.geo-ide.developpement-durable.gouv.fr/atomArchive/GetResource?id=90dd3756-8b73-4dbc-a99f-01503b507228&amp;dataType=dataset</gmd:URL>
              </gmd:linkage>
              ...
              <gmd:name>
                <gco:CharacterString>Téléchargement simple (Atom) du jeu et des documents associés via internet</gco:CharacterString>
              </gmd:name>
              ...
              <gmd:function>
                <gmd:CI_OnLineFunctionCode codeList="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_OnLineFunctionCode" codeListValue="download"/>
              </gmd:function>
            </gmd:CI_OnlineResource>
          </gmd:onLine>
          ...
        </gmd:MD_DigitalTransferOptions>
      </gmd:transferOptions>
      ...
    </gmd:MD_Distribution>
  </gmd:distributionInfo>
  ...
</gmd:MD_Metadata>

Références

Les préconisations ci-avant sont déduites des critères utilisés par la transformation GeoDCAT-AP v2.0 pour reconnaître les distributions des données, qui sont plus restrictifs que les standards.

L'usage de gmd:function est néanmoins recommandé par le guide technique INSPIRE :

TG Recommendation 1.9: metadata/2.0/rec/datasets-and-series/resource-locator-additional-info

The gmd:name, gmd:description, and gmd:function/gmd:CI_OnLineFunctionCode child elements of gmd:CI_OnlineResource element containing the given gmd:linkage element should also be provided, if possible, to give additional information about the provided URL link. The gmd:name and the gmd:description elements should contain Non-empty Free Text Elements.

If provided, the gmd:CI_OnLineFunctionCode element should point to one of the values of the ISO 19139 code list CI_OnLineFunctionCode.

Séparer la licence des conditions d'accès

➡️ XSLT (doc).
➡️ Discussion.

Préconisations

Les éléments de métadonnées INSPIRE correspondant aux "limitations d'accès" d'une part et aux "conditions applicables à l’accès et à l’utilisation" d'autre part devraient être représentés par deux éléments gmd:resourceConstraints/gmd:MD_LegalConstraints distincts.

L'élément gmd:resourceConstraints/gmd:MD_LegalConstraints qui représente les limitations d'accès INSPIRE contient :

  • Un élément gmd:accessConstraints.
  • Au moins un élément gmd:otherConstraints qui définit la limitation d'accès en utilisant le vocabulaire Limitations on public access du registre INSPIRE.

Exemple d'un jeu de données sans restriction d'accès :

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmx="http://www.isotc211.org/2005/gmx" xmlns:xlink="http://www.w3.org/1999/xlink">
  ...
  <gmd:identificationInfo>
    <gmd:MD_DataIdentification>
      ...
      <gmd:resourceConstraints>
        <gmd:MD_LegalConstraints>
          <gmd:accessConstraints>
            <gmd:MD_RestrictionCode codeListValue="otherRestrictions" codeList="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_RestrictionCode">otherRestrictions</gmd:MD_RestrictionCode>
          </gmd:accessConstraints>
          <gmd:otherConstraints>
            <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess/noLimitations">Pas de restriction d'accès public selon INSPIRE</gmx:Anchor>
          </gmd:otherConstraints>
          <gmd:otherConstraints>
            <gco:CharacterString>Aucun des articles de la loi ne peut être invoqué pour justifier d'une restriction d'accès public.</gco:CharacterString>
          </gmd:otherConstraints>
        </gmd:MD_LegalConstraints>
      </gmd:resourceConstraints>
      ...
    </gmd:MD_DataIdentification>
  </gmd:identificationInfo>
  ...
</gmd:MD_Metadata>

L'élément gmd:resourceConstraints/gmd:MD_LegalConstraints correspondant aux "conditions applicables à l’accès et à l’utilisation" contient :

  • Soit un élément gmd:accessConstraints (si la métadonnée décrit les modalités d'accès à la donnée), soit un élément gmd:useConstraints (obligatoirement si la métadonnée spécifie une licence).
  • Au moins un élément gmd:otherConstraints qui explicite les conditions applicables.

Exemple de représentation d'une licence :

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmx="http://www.isotc211.org/2005/gmx" xmlns:xlink="http://www.w3.org/1999/xlink">
  ...
  <gmd:identificationInfo>
    <gmd:MD_DataIdentification>
      ...
      <gmd:resourceConstraints>
        <gmd:MD_LegalConstraints>
          <gmd:useConstraints>
            <gmd:MD_RestrictionCode codeListValue="otherRestrictions" codeList="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_RestrictionCode">otherRestrictions</gmd:MD_RestrictionCode>
          </gmd:useConstraints>
          <gmd:otherConstraints>
            <gmx:Anchor xlink:href="https://www.etalab.gouv.fr/licence-ouverte-open-licence">Licence Ouverte / Open Licence Version 2.0</gmx:Anchor>
          </gmd:otherConstraints>
        </gmd:MD_LegalConstraints>
      </gmd:resourceConstraints>
      ...
    </gmd:MD_DataIdentification>
  </gmd:identificationInfo>
  ...
</gmd:MD_Metadata>

Un même élément gmd:resourceConstraints/gmd:MD_LegalConstraints ne doit jamais contenir à la fois un élément gmd:accessConstraints et un élément gmd:useConstraints.

Associer plusieurs éléments gmd:otherConstraints, comme dans le premier exemple ci-dessus, ne pose pas de difficulté.

Voir aussi Faciliter la reconnaissance des licences et Le cas des restrictions d'usage.

Références

La représentation des limitations d'accès d'une part et des conditions applicables à l’accès et à l’utilisation d'autre part est très précisément spécifiée par le guide technique INSPIRE, qui insiste notamment sur le fait que ces deux métadonnées doivent être portées par des éléments gmd:resourceConstraints/gmd:MD_LegalConstraints séparés. Les préconisations susmentionnées correspondent à une version simplifiée, et donc moins contraignante, des règles de ce guide.

TG Requirement C.17: metadata/2.0/req/common/limitations-on-public-access

Limitations on public access (or lack of such limitations) for the described resource shall be described using exactly one gmd:resourceConstraints/gmd:MD_LegalConstraints element. This element shall not be the same one as used for describing conditions applying to access and use.

The limitations on public access (or lack of such limitations) based on reasons referred to in point (a) or in points (c) to (h) of Article 13(1) of INSPIRE Directive quoted above, the gmd:resourceConstraints/gmd:MD_LegalConstraints element shall include a combination of

  • one instance of gmd:accessConstraints/gmd:MD_RestrictionCode element with code list value "otherRestrictions" and
  • at least one instance of gmd:otherConstraints/gmx:Anchor pointing to one of the values from the code list for LimitationsOnPublicAccess. If there are no limitations on public access, the element shall point to the code list value "noLimitations".

TG Requirement C.18: metadata/2.0/req/common/conditions-for-access-and-use

Conditions for access and use of the described resource shall be described using exactly one gmd:resourceConstraints/gmd:MD_LegalConstraints element. This element shall not be the same used for describing limitations on public access.

The gmd:resourceConstraints/gmd:MD_LegalConstraints element for conditions for access and use shall be encoded as follows: One instance of either gmd:accessConstraints or gmd:useConstraints element shall be given. In both cases this element shall contain a gmd:MD_RestrictionCode element with code list value "otherRestrictions".

Additionally at least one instance of gmd:otherConstraints shall be given describing the actual conditions.

If no conditions apply the gmd:otherConstraints shall include a gmx:Anchor element pointing to the value "noConditionsApply" in the code list ConditionsApplyingToAccessAndUse.

If the conditions are unknown gmd:otherConstraints shall include a gmx:Anchor element pointing to the value "conditionsUnknown" in the code list ConditionsApplyingToAccessAndUse.

In other cases gmd:otherConstraints shall include a Non-empty Free Text Element with a textual description of the conditions in the language of the metadata. This text shall include descriptions of terms and conditions, including where applicable, the corresponding fees or an URL pointing to an online resource where these terms and conditions are described.

Le guide de saisie du CNIG consacre une quinzaine de page au sujet, avec de nombreux exemples.

Faciliter la reconnaissance des licences

➡️ XSLT (doc).
➡️ Discussion.

Préconisations

Représenter les licences avec un élément gmx:Anchor dont l'attribut xlink:href prend pour valeur l'une des URL de licences mentionnées dans la liste officielle des licences utilisables par les administrations françaises.

Exemple :

<gmx:Anchor xlink:href="https://spdx.org/licenses/ODbL-1.0">ODC Open Database License (ODbL) version 1.0</gmx:Anchor>

Références

Le guide technique INSPIRE recommande de fournir un lien vers la licence, mais sans expliciter sa formalisation.

TG Recommendation C.10: metadata/2.0/rec/common/licences

For detailed information about the licensing of the resource it is recommended to provide a link to a license type (e.g. http://creativecommons.org/licenses/by/3.0), a website or to a document containing the necessary information.

Pour autant, il permet bien de représenter n'importe quelle valeur textuelle via un élément gmx:Anchor, et l'encourage dans le cas où - comme pour les licences - la valeur est définie par une source externe à laquelle il est possible de se référer.

The ISO 19139 XML Schemas allow using alternative ways of encoding free text. The basic element for providing text of unrestricted length with no internal XML structure is gco:CharacterString. This element is appropriate when the text does not refer to a specific external resource or registry, and it is not necessary to highlight the fact that the text is provided using a particular natural language or locale. [...] When the provided text is a term or code referring to an externally defined explanation or registry value, gmx:Anchor element is recommended over gco:CharacterString. It contains and additional attribute group enabling linking the provided piece of text with an external describing resource. The most important of these attributes in this context is xlink:href, which contains the actual reference in URI format.

Faciliter la reconnaissance des formats

➡️ Discussion.

Préconisations

Encoder les formats avec des éléments gmx:Anchor au lieu de gco:CharacterString, en utilisant si possible les URI des types de média de l'IANA ou celles du vocabulaire INSPIRE media-types/application. Ce dernier regroupe les URI IANA des formats de données géographiques les plus courants, et ajoute des URI du registre INSPIRE pour les autres formats de données géographiques fréquemment utilisés mais qui n'ont pas d'URI IANA.

Exemple pour le format Shapefile :

<gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmx="http://www.isotc211.org/2005/gmx" xmlns:xlink="http://www.w3.org/1999/xlink">
  ...
  <gmd:distributionInfo>
    <gmd:MD_Distribution>
      <gmd:distributionFormat>
        <gmd:MD_Format>
          <gmd:name>
            <gmx:Anchor xlink:href="http://publications.europa.eu/resource/authority/file-type/SHP">ESRI Shapefile</gmx:Anchor>
          </gmd:name>
          <gmd:version gco:nilReason="unknown"></gmd:version>
        </gmd:MD_Format>
      </gmd:distributionFormat>
      ...
    </gmd:MD_Distribution>
  </gmd:distributionInfo>
  ...
</gmd:MD_Metadata>

L'élément gmd:distributionFormat/gmd:MD_Format devrait être utilisé pour exprimer le format d'encodage du jeu de données et non celui de l'archive qui l'encapsule.

Références

Le guide technique INSPIRE ne dit pas explicitement que les formats de jeu de données doivent être encodés avec des éléments gmx:Anchor, mais les explications et l'exemple qu'il donne suggèrent qu'il s'agit d'une bonne pratique et incitent à l'emploi du vocabulaire INSPIRE media-types/application.

[Au sujet de l'exemple 3.18] Data set has been declared to be available both in the INSPIRE Addresses GML Application Schema (encoded in XML) and in Esri Shapefile format. The gmx:Anchor is used to describe the latter, as the format is included in the code list for supported INSPIRE media types.

💬 Discussions

💬 Veiller à ce que les jeux de données soient reconnaissables comme tels

➡️ Recommandation.

Les éléments gmd:hierarchyLevel paraissent présents sur la plupart des catalogues. Mais il y a des exceptions, notamment les fiches de métadonnées de data.naturefrance.fr.

NB : Le XSLT assimile pour l'heure les "series" à des objets dcat:Dataset, mais la future prise en compte de DCAT v3 conduira certainement à les représenter par des dcat:DatasetSeries. Aucune différence notable n'est faite entre "dataset" et "nonGeographicDataset".

💬 Présenter des identifiants de jeux de données exploitables

➡️ Recommandation.

Le catalogue Géo-IDE utilise aujourd'hui des éléments gmd:identifier/RS_Identifier, avec séparation de l'espace de nommage dans un élément gmd:codeSpace.

Exemple :

            <gmd:identifier>
              <gmd:RS_Identifier>
                <gmd:code>
                  <gco:CharacterString>7f54a3aa-fc3e-4c35-b8d2-724a426388f5</gco:CharacterString>
                </gmd:code>
                <gmd:codeSpace>
                  <gco:CharacterString>http://descartes-dev.cete-mediterranee.i2</gco:CharacterString>
                </gmd:codeSpace>
              </gmd:RS_Identifier>
            </gmd:identifier>

Dans ce cas, l'identifiant n'est pas considéré comme un URI, et la transformation utilise un noeud anonyme comme sujet du dcat:Dataset. Pour reconstituer une valeur pour la propriété dct:identifier, elle concatène assez brutalement l'espace de nommage et l'identifiant.

[] dcterms:identifier "http://descartes-dev.cete-mediterranee.i2/7f54a3aa-fc3e-4c35-b8d2-724a426388f5"^^xsd:anyURI ;

À noter que tant pour déterminer l'URI du dcat:Dataset que pour la valeur de dct:identifier, le XSLT ne reconnaît que les URI exprimés sous la forme d'un élément gmd:code/gco:CharacterString, excluant les URI représentées par un élément gmd:code/gmx:Anchor. La substitution de gmx:Anchor à gco:CharacterString est pourtant permise par le guide technique INSPIRE dans le cas général, et tout à fait naturelle dans le cas d'une URI. L'exemple donné par le guide technique sur l'encodage des identifiants de ressource unique utilise d'ailleurs justement un élément gmx:Anchor. Les catalogues INSPIRE du périmètre MTECT ayant généralement peu recours à gmx:Anchor, il est probable que le problème ne se pose pas en pratique, néanmoins il paraîtrait préférable de demander la modification du XSLT sur ce point.

À titre d'illustration, test de représentation d'un même identifiant :

💬 Rendre les distributions identifiables

➡️ Recommandation.

GeoDCAT-AP v2.0 détaille la correspondance entre les termes de la liste de codes CI_OnLineFunctionCode et les propriétés DCAT.

La différentiation entre distributions des données et documentation est faite à la ligne 1373 du XSLT. C'est la ligne 4147 du XSLT qui base la reconnaissance des services sur la présence de la chaîne 'request=getcapabilities' dans l'URL.

Les catalogues qui utiliseraient l'élément gmd:function comme attendu seraient, s'il y en a, des cas exceptionnels. gmd:function n'était pas mentionné dans le guide de saisie du CNIG et les définitions des termes sont soumises à interprétation. Par exemple, il n'est pas forcément intuitif qu'un lien de téléchargement direct relève de download quand la définition de ce code est "online instructions for transferring data from one storage device or system to another".

La méthode de reconnaissance des services est très restrictive. Même quand l'élément gmd:url pointe bien sur la description du service comme le demande le guide technique INSPIRE pour les services de visualisation et de téléchargement, encore faut-il que le protocole considéré prévoie un paramètre request valant alors GetCapabilities.

Cela signifie notamment que les services de téléchargement ATOM ne seront jamais reconnus comme des services, même s'ils ont été référencés comme prévu par le guide technique INSPIRE, avec :

  • gmd:url qui pointe sur le document XML Atom listant les flux et non sur un lien de téléchargement direct (élément atom:link d'un flux).
  • gmd:protocol qui indique ATOM Syndication Format.
  • gmd:applicationProfile qui confirme qu'il s'agit d'un service de téléchargement.

Cf. exemple 8.7 du guide pour une illustration.

Je suis preneuse d'une contre-analyse, mais je ne trouve pas ce dernier point très satisfaisant. La méthode mise en oeuvre par le XSLT pour calculer la propriété dcat:endpointURL requise pour le dcat:DataService consiste simplement à retirer le '?' et tous les paramètres qui suivent si l'URL contient '?', ou à conserver l'URL telle quelle sinon. Elle paraît applicable à d'autres services que WMS et WFS. Il semblerait possible de considérer également qu'une distribution peut et doit être créée et porter une propriété dcat:accessService dès lors qu'un élément gmd:protocol est présent avec comme valeur un terme du vocabulaire INSPIRE Protocol values et/ou qu'un élément gmd:applicationProfile est présent avec la valeur view ou download du vocabulaire INSPIRE Type de service de données géographiques.

Dans les faits, même les services WMS/WFS ne seront pas identifiés pour un bon nombre de catalogues, faute de requête GetCapabilities dans les URL. Ci-après quelques exemples de distributions mises à disposition par des services WMS.

Extrait d'une fiche de métadonnées de Sextant :

          <gmd:onLine>
            <gmd:CI_OnlineResource>
              <gmd:linkage>
                <gmd:URL>https://sextant.ifremer.fr/services/wms/environnement_marin</gmd:URL>
              </gmd:linkage>
              <gmd:protocol>
                <gco:CharacterString>OGC:WMS</gco:CharacterString>
              </gmd:protocol>
              ...
            </gmd:CI_OnlineResource>
          </gmd:onLine>

Extrait d'une fiche de métadonnées de Géo-IDE :

            <gmd:onLine>
              <gmd:CI_OnlineResource>
                <gmd:linkage>
                  <gmd:URL>https://ogc.geo-ide.developpement-durable.gouv.fr/wxs?map=/opt/data/carto/geoide-catalogue/1.4/org_38058/7f54a3aa-fc3e-4c35-b8d2-724a426388f5.internet.map</gmd:URL>
                </gmd:linkage>
                <gmd:name>
                  <gco:CharacterString>URL de base des services wms/wfs sur internet</gco:CharacterString>
                </gmd:name>
              </gmd:CI_OnlineResource>
            </gmd:onLine>

Extrait d'une fiche de métadonnées de datARA :

               <gmd:onLine>
                  <gmd:CI_OnlineResource>
                     <gmd:linkage>
                        <gmd:URL>https://catalogue.datara.gouv.fr/geosource/consultationWMS?IDT=54206683</gmd:URL>
                     </gmd:linkage>
                     <gmd:protocol>
                        <gco:CharacterString>WWW:LINK-1.0-http--link</gco:CharacterString>
                     </gmd:protocol>
                     <gmd:name>
                        <gco:CharacterString>Accès à la visualisation des données</gco:CharacterString>
                     </gmd:name>
                     <gmd:applicationProfile>
                        <gco:CharacterString>MAP</gco:CharacterString>
                     </gmd:applicationProfile>
                  </gmd:CI_OnlineResource>
               </gmd:onLine>

💬 Séparer la licence des conditions d'accès

➡️ Recommandation.

La transformation GeoDCAT-AP est bien plus permissive que ce que prévoit le guide technique. En ce qui la concerne, il suffit d'un élément gmd:otherConstraints accompagné d'un élément gmd:accessConstraints pour reconnaître une condition d'accès à transformer en objet de la propriété dct:accessRights. Le contenu de l'élément gmd:accessConstraints n'est pas considéré. En parallèle, tous les éléments gmd:otherConstraints accompagnés d'un élément gmd:useConstraints et (pour peu d'avoir configuré la transformation pour autoriser les formes obsolètes) tous les éléments gmd:useLimitation sont convertis en objets de la propriété dct:license.

L'une des implications est qu'un élément gmd:otherConstraints accompagné à la fois par un élément gmd:accessConstraints et un élément gmd:useConstraints sera mappé deux fois, sur dct:accessRights et sur dct:license.

Le guide technique INSPIRE indique très clairement que les éléments gmd:resourceConstraints/gmd:MD_LegalConstraints représentant les limitations d'accès et les conditions applicables à l’accès et à l’utilisation doivent inclure un élément gmd:accessConstraints ou gmd:useConstraints portant obligatoirement le terme "otherRestrictions"du vocabulaire ISO 19139 MD_RestrictionCode. La manière dont cette règle est rédigée ("one instance", tandis que pour les éléments gmd:otherConstraints il est indiqué "at least one instance") suggère qu'il s'agit à la fois d'un minimum et d'un maximum, mais ce n'est pas l'interprétation qu'en a fait le guide de saisie du CNIG, qui suggère d'ajouter des éléments gmd:accessConstraints / gmd:useConstraints porteurs d'autres termes pertinents du vocabulaire MD_RestrictionCode. Par exemple "license" dans le cas de données sous licence. Dans le contexte d'une conversion en DCAT, la plus-value de cette information supplémentaire est discutable, d'autant que la valeur de l'attribut codeList est ignorée lors de la transformation. Mais elle ne pose pas de difficulté tant qu'un même élément gmd:resourceConstraints/gmd:MD_LegalConstraints ne contient jamais à la fois un élément gmd:accessConstraints et un élément gmd:useConstraints, ce qui n'est pas le cas dans les exemples du guide de saisie.

💬 Faciliter la reconnaissance des licences

➡️ Recommandation.

Le guide de saisie du CNIG ne donne pas de consigne précise pour la représentation de la licence, mais l'exemple fourni sur ce point montre non un élément gmx:Anchor mais un lien inclus dans un élément gco:CharacterString qui indique aussi le nom de la licence.

<gco:CharacterString> Licence ODbL mai 2013 (basée sur ODbL 1.0)
https://data.rennesmetropole.fr/pages/licence/</gco:CharacterString>

Si la liste de data.gouv.fr sert de référence pour les URI de licences à privilégier, il faudrait s'assurer que les URL qu'elle présente sont satisfaisantes.

Pour le moment, ce sont essentiellement des URL SPDX, sauf pour la licence ouverte.

Le principe d'utiliser le registre SPDX est tout à fait pertinent du point de vue de l'interopérabilité, mais les URL pourraient être simplifiées pour correspondre à de vraies URI. Par exemple, https://spdx.org/licenses/ODbL-1.0 serait préférable à https://spdx.org/licenses/ODbL-1.0.html#licenseText.

Pour la licence ouverte, l'URL https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf pointe sur un document PDF. Dans le cadre du groupe de travail Métadonnées du CNIG, il avait été évoqué de privilégier https://www.etalab.gouv.fr/licence-ouverte-open-licence.

Il faudra par ailleurs considérer le cas des fiches de métadonnées contenant des licences exprimées sous forme textuelle qu'il n'aura pas été possible d'assimiler à une licence connue. Par exemple (source) :

         <gmd:resourceConstraints>
            <gmd:MD_LegalConstraints>
               <gmd:useLimitation>
                  <gco:CharacterString>Utilisation libre sous réserve de mentionner la source (a minima le nom du producteur) et la date de sa dernière mise à jour</gco:CharacterString>
               </gmd:useLimitation>
               <gmd:useConstraints>
                  <gmd:MD_RestrictionCode codeList="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_RestrictionCode"
                                          codeListValue="otherRestrictions"/>
               </gmd:useConstraints>
            </gmd:MD_LegalConstraints>
         </gmd:resourceConstraints>

Une telle mention constitue juridiquement une licence, mais celle-ci ne fait clairement pas partie des licences utilisables par les administrations française.

💬 Faciliter la reconnaissance des formats

➡️ Recommandation.

Le guide de saisie du CNIG ne rappelle pas la possibilité d'utiliser des éléments gmx:Anchor. L'exemple qu'il donne montre un élément gco:CharacterString.

Le XSLT GeoDCAT-AP représente autant que possible les formats des distributions sous forme d'URI, sinon il utilise dct:format / rdfs:label. Il cherche à reconnaître les formats exprimés sous forme de chaînes de caractères, mais cette méthode ne fonctionne pas toujours. Par exemple, les éléments <gco:CharacterString>ESRI Shapefile (SHP)</gco:CharacterString> de Géo-IDE sont retranscrits sous forme d'étiquette et non d'URI. Exemple : XML source (modifié pour que les distributions soient reconnues comme telles) vs. résultat de la transformation.

L'objectif est d'augmenter les chances que data.gouv.fr reconnaisse et affiche correctement les formats de données, en normalisant au maximum leur représentation. Les URI utilisées sont susceptibles d'appartenir à trois vocabulaires, que data.gouv.fr devrait maîtriser :

GeoDCAT-AP v2.0, de même que DCAT v2 et DCAT v3, prévoit des propriétés dcat:packageFormat et dcat:compressFormat distinctes de dct:format (ou dcat:mediaType pour les URI IANA) pour représenter les formats de fichiers qui servent à regrouper ou compresser les fichiers de données. La transformation ne les considère cependant pas. Pour elle, gmd:distributionFormat/gmd:MD_Format équivaut toujours à dct:format, même pour des formats tels que ZIP et tar.

Le guide technique INSPIRE ne dit pas explicitement que gmd:distributionFormat/gmd:MD_Format ne peut pas indiquer un format d'archive. Par contre, mentionner uniquement un format d'archive ne paraît pas suffisant pour répondre aux exigences exprimées. Or cela arrive en pratique - exemple d'une fiche de métadonnées de datARA.

         <gmd:distributionFormat>
            <gmd:MD_Format>
               <gmd:name>
                  <gco:CharacterString>ZIP</gco:CharacterString>
               </gmd:name>
               <gmd:version gco:nilReason="unknown">
                  <gco:CharacterString/>
               </gmd:version>
            </gmd:MD_Format>
         </gmd:distributionFormat>
Clone this wiki locally