search

SEMICeu / GeoDCAT-AP

Repository of the geospatial extension to DCAT-AP (GeoDCAT-AP)
https://joinup.ec.europa.eu/solution/geodcat-application-profile-data-portals-europe
Creative Commons Attribution 4.0 International
17 stars 6 forks source link

Support 1-to-many mappings for responsible party roles #39

Open andrea-perego opened 3 years ago

andrea-perego commented 3 years ago

ℹ️ Following discussion in https://github.com/SEMICeu/GeoDCAT-AP/issues/16 & https://github.com/SEMICeu/GeoDCAT-AP/issues/30

Currently, GeoDCAT-AP defines only 1-to-1 mappings from the ISO 19115 / INSPIRE responsible party roles to the corresponding properties in DCTERMS and DCAT.

Should we consider supporting 1-to-many mappings, so to ensure a wider coverage of responsible party roles?

NB: This issue is partially related to the proposal of defining properties for the unmapped roles - see https://github.com/SEMICeu/GeoDCAT-AP/issues/32

andrea-perego commented 3 years ago

Original thread started in https://github.com/SEMICeu/GeoDCAT-AP/issues/16 & https://github.com/SEMICeu/GeoDCAT-AP/issues/30

Copying below the comments submitted so far:

@andrea-perego - https://github.com/SEMICeu/GeoDCAT-AP/issues/16#issuecomment-722641124

@AntoRot said:

  1. In the table given in the section B.6.16, listing the mappings for responsible party roles, the RDF property dct:creator could be also mapped with the role originator as well as with the role author defined in ISO 19115.

So far, GeoDCAT-AP has been using 1-to-1 mappings for responsible party roles. Before updating the mapping as you suggest, it would be important to know if there are any objections to support also 1-to-many mappings.

@bertvannuffelen - https://github.com/SEMICeu/GeoDCAT-AP/issues/16#issuecomment-723550050

[...]

Being ambiguous depends on the objective of the mapping. If the objective of this table is reflecting an implementation (e.g. of the reference XSLT transformation) then the 1-on-1 can be a choice. But if the objective is to fullfull the geoDCAT-AP constraints e.g. like having a recommended publisher, and the ISO description contains only an originator then it can be decided that this will be the publisher. I understand these kind of choices have to be made by the implementer of the mapping, and it might not be the role of this specification.

As a suggestion, to allow users of this specification to make similar decisions, we can add an extra column in the mapping table. A column 'implementation suggestion' which indicates the preferred mapping in case would like to map the ISO property.

@matthiaspalmer - https://github.com/SEMICeu/GeoDCAT-AP/issues/30#issuecomment-727653297

[...] I would prefer if it was possible to outline two clear strategies for implementors to take:

Strategy 1 is for those that prioritize a 1-1 mapping. Here the current table is ok, i.e. clearly map to DCTERMS for a few of the roles and use qualifiedAttribution for the rest.

Strategy 2 is for those that prioritize the use of direct properties (DCTERMS) even if it means loosing the 1-1 mapping and a loss of specificity. In this case it should be indicated which INSPIRE roles to map to which DCTERMS properties. Note that we have the properties dct:mediator, dct:contributor and dct:audience as well as those already mentioned (dct:publisher, dct:creator and dct:rightsHolder).

Of course, there are for sure more options, but by outlining these two clear strategies implementors are given support in how to reason and can take a more informed position.