search

cnigfr / metadonnee

5 stars 3 forks source link

Mapping - Identification de la ressource #9

Closed MarieLambois closed 1 year ago

MarieLambois commented 2 years ago

Commentaires sur la page https://github.com/cnigfr/metadonnee/blob/main/MappingINSPIRE-DCAT/Identification.md

yvanlebras commented 1 year ago

Maybe change Format / Encoding by Format and notably on the mermaid as "encoding" seems to me to give potentially other definition...

yvanlebras commented 1 year ago

Concerning "Type de représentation", it appears to me this is "Type de représentation géographique" in INSPIRE isn't it? And thus, this is not the same than adms:representationTechnique isn't it?

MarieLambois commented 1 year ago

Modifications faites. Le mapping avec adms:RepresentationTechnique est effectivement à discuter. Pour mémoire et discussions je met la def ici : image

versus : image

alhyss commented 1 year ago

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.

Propriété ou chemin de propriétés
dcat:distribution / dcat:accessURL

Je ne sais pas s'il existe un formalisme reconnu pour faire également figurer les classes. J'ai eu tendance à faire ça :

Propriété ou chemin de propriétés
[dcat:Dataset] dcat:distribution / [dcat:Distribution] dcat:accessURL

Option 2 : Faire simplement correspondre chaque information INSPIRE avec une propriété et un domaine.

Domaine Propriété
dcat:Distribution dcat:accessURL

L'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:distribution qui permettra de rattacher les objets dcat:Distribution correspondants, foaf:isPrimaryTopicOf pour l'objet dcat:CatalogRecord qui pourrait porter les métadonnées sur les métadonnées, etc.

alhyss commented 1 year ago

Nous pouvons maintenant représenter les "ensembles de séries de données" (dataset series) avec la nouvelle classe dcat:DatasetSeries de DCAT v3 - sous classe de dcat:Dataset - et utiliser la propriété dcat:inSeries (domaine dcat:Dataset, portée dcat:DatasetSeries) pour spécifier les relations entre l'ensemble et les jeux de données associés. Cf. partie 12. Dataset series du standard.

Il y a une propriété réciproque, dcat:seriesMember, qui peut être utilisée en complément pour lister les jeux de données associés sur l'objet dcat:DatasetSeries. Garder uniquement dcat:inSeries aurait cependant une certaine cohérence avec la recommandation pour l'implémentation suivant INSPIRE, qui était de faire porter la relation par les enfants avec identificationInfo.citation.serie ?

Avec DCAT v2, tout serait effectivement du dcat:Dataset, comme à date dans le tableau. Et il faudrait faire avec dct:isPartOf / dct:hasPart pour les relations.