Responsible party roles about geodcat-ap HOT 11 CLOSED

Original thread started in #16

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.

1. Concerning the metadata point of contact, as INSPIRE TG states that the only role to be considered is pointOfContact of ISO 19115 code list CI_RoleCode, only dcat:contactPoint should be used in GeoDCAT-AP without using prov:qualifiedAttribution in this case. In the example 39 both dcat:contactPoint and prov:qualifiedAttribution are instead used for the metadata contact point.

There are two aspects here:

• Whether to support or not other roles in addition to the required ones. This relates to the discussion in #23
• Whether to use prov:qualifiedAttribution also for roles that can be specified via DCTERMS and DCAT. Since its first version, GeoDCAT-AP, has been using prov:qualifiedAttribution for all roles in its extended mapping profile. One of the reasons is that, this way, the correspondence with the roles defined in ISO 19115 is made explicit. If this feature is not considered as important, any revision to the current approach should however take into account backward compatibility. Moreover, in case it will be decided to support 1-to-many mappings for roles, the correspondence with ISO 19115 roles will be ambiguous in case prov:qualifiedAttribution will be dropped.

@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.

On the use of expressing the roles both as a qualifiedAttribution and a native property, DCAT 2.0 strongly advices not to do so. But here we are expressing the ISO roles versus the native properties adopted by DCAT, it it would be coherent for me that one expresses the ISO role as a qualifiedAttribution while the same data is repeated as a native property. As example 39 shows.
The correspondence between both is given by the actual used implementation, of which the mapping table provides a first glimp.

@matthiaspalmer - #16 (comment)

Adaption / implementation report:

In the Swedish adoption of DCAT-AP2.0.0 we decided to give guidance on which roles to use. We decided to rely on the party roles from Inspire but filtered so there was only one way to express a relation. The approach is the same as listen in the table in B6.16 with one exception, we did not exclude owner as we have not recommended the use of dct:rightsHolder directly on the dataset. We did not do that as it was not included in DCAT-AP2.0.0.

The national portal (dataportal.se) have implemented support for showing the pary roles as described above but there is yet no data providers that deliver information in this way. A few dataproviders are on their way though and there is initial support for this in EntryScape (via an RDForms Template for DCAT-AP-SE v2.0.0 mixed with an upgraded version of GeoDCAT-AP which resembles in large this specification).

from geodcat-ap.

Trying to summarise:

We are discussing 3 separate - although related - issues here:

1. Whether to support 1-to-many mappings
2. Whether to keep providing support to roles not required in INSPIRE for specific resources - e.g., catalogue records
3. Whether the two alternative ways of specifying agent roles in GeoDCAT-AP should be still supported

I think we may consider the 2nd one as resolved, following what decided in #23 , and allow the specification of roles not required by INSPIRE.

@AntoRot , are you happy with this proposal?

from geodcat-ap.

I agree that the approach decided in #23 should be also followed for the second issue listed in your comment.

from geodcat-ap.

Thanks, @AntoRot .

About this point:

3. Whether the two alternative ways of specifying agent roles in GeoDCAT-AP should be still supported

I think it would be important to clarify that the purpose of having in place these 2 non-mutually-exclusive approaches is twofold:

1. Provide a mechanism to express roles not supported in DCAT and DCTERMS, in order to avoid information loss
2. Ensure compliance with the INSPIRE Metadata Regulation

It is worth noting that the use of both approaches is not mandatory. The purpose was simply to give data providers a harmonised solution for the specification of all the roles supported in INSPIRE, but it is totally up to them to decide how to use / support these approaches.

These aspects are not explicitly stated in the GeoDCAT-AP specification, so I wonder whether updating it accordingly would be beneficial for users. We could do this in §7, which is specifically devoted to agent roles.

@AntoRot , @bertvannuffelen , @matthiaspalmer , WDYT?

from geodcat-ap.

I agree in keeping both approaches and in updating the specification as you suggest, also adding a recommendation to use DCAT-AP/DCT properties for those roles for which a mapping with INSPIRE ones exists and qualifiedAttribution for all other roles.

from geodcat-ap.

First, I am ok with keeping two options in the specification.
However, 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.

from geodcat-ap.

Thanks, @AntoRot & @matthiaspalmer . I'll draft the text to be added, taking into account your suggestions.

BTW, besides providing guidance on the 2 approaches, we may consider an additional option:

As @matthiaspalmer highlighted in his first comment, the approach based on prov:qualifiedAttribution , because of its complexity, may be difficult to be used and implemented in existing catalogue platforms.

Compliance with INSPIRE is one of the requirements for GeoDCAT-AP, and therefore all the INSPIRE roles must be supported in GeoDCAT-AP (although data providers may choose to use only some of them). So, a possible solution could be to replace the approach based on prov:qualifiedAttribution with newly defined properties, complementing those already available in DCAT and DCTERMS for the specification of roles.

from geodcat-ap.

About the creation of new properties for roles, I created a separate issue to discuss this option: #32

Meanwhile, I drafted the guidance note for §7 discussed earlier - see PR #31

from geodcat-ap.

@AntoRot , @matthiaspalmer , unless you have any comments, I will proceed and merge PR #31 .

from geodcat-ap.

As there are no comments, I am going to merge PR #31 , and close this issue.

For the discussion item still open - i.e., whether to support 1-to-many mappings - I created a separate issue: #39

from geodcat-ap.

Indeed no other comments from my side. Thanks.

from geodcat-ap.