MarieLambois
commented
2 years ago Réunion du 27/09/2022 :
Cette question est liée à celle de la structuration finale de la métadonnée. Les utilisations actuelles sont plutôt faites avec dcat:Dataset comme racine. Néanmoins il semble intéressant de ne pas trop imposer cette structuration pour ne pas trop contraindre les usages. Les mapping seront donc faits de manière générique (sans préciser le lien entre les composants) et un guide/exemple viendra ensuite compléter le mapping en proposant une structuration avec dcat:Dataset comme élément racine.
Commentaire de @alhyss : Deux suggestions alternatives pour représenter le mapping dans le tableau :
Option 1 : Prendre comme référence le jeu de données. Dans ce cas, le mapping est un chemin de propriétés dont la première a nécessairement pour domaine
dcat:Dataset.dcat:distribution / dcat:accessURLJe ne sais pas s'il existe un formalisme reconnu pour faire également figurer les classes. J'ai eu tendance à faire ça :
[dcat:Dataset] dcat:distribution / [dcat:Distribution] dcat:accessURLOption 2 : Faire simplement correspondre chaque information INSPIRE avec une propriété et un domaine.
dcat:Distributiondcat:accessURLL'inconvénient de ça est qu'on se retrouve avec des bouts de métadonnées rattachés à différents objets non connectés entre eux. Mais c'est peut-être le plus propre si on ne veut pas restreindre la portée du mapping en le focalisant entièrement sur les jeux de données.
Dans ce cas, il faudra compléter le mapping par des recommandations sur la manière d'organiser les métadonnées selon la classe prise comme référence. Concrètement, ça peut être de dire que si on part d'un jeu de données, alors c'est la propriété
dcat:distributionqui permettra de rattacher les objetsdcat:Distributioncorrespondants,foaf:isPrimaryTopicOfpour l'objetdcat:CatalogRecordqui pourrait porter les métadonnées sur les métadonnées, etc.