Support 1-to-many mappings for responsible party roles

[andrea-perego]

ℹ️ Following discussion in #16 & #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 #32

[andrea-perego]

Original thread started in #16 & #30

Copying below the comments submitted so far:

@andrea-perego - #16 (comment)

@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 - #16 (comment)

[...]

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 - #30 (comment)

[...] 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.