Revision to responsible party roles

[andrea-perego]

GeoDCAT-AP makes use of qualified relations from [PROV-O] to specify responsible party roles, as an alternative to the use of specific properties (e.g., dct:publisher, dcat:contactPoint).

This approach was contributed to the W3C DXWG (see Use Case 13 in DCAT-UCR), and it has been re-used and refined in DCAT 2 as one of possible ways for specifying relationships between agents and resources in a catalogue (see §13.1 Relationships between datasets and agents and Example 41). In particular, DCAT 2 defines a new property dcat:hadRole to specify the agent role, whereas GeoDCAT-AP makes use of property dct:type for the same purpose.

Property dcat:hadRole has been adopted by DCAT-AP 2 (see SEMICeu/DCAT-AP#81), and therefore GeoDCAT-AP should be updated accordingly, possibly taking into account backward interoperability (e.g., by marking dct:type as deprecated).

[AntoRot]

A couple of comments linked to this topic:

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.

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

[andrea-perego]

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

2. 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 Additional properties in GeoDCAT-AP not included in DCAT-AP #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]

There are two aspects here:

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

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]

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

[andrea-perego]

This issue was specifically related to the adoption of dcat:hadRole in the new version of GeoDCAT-AP. As the corresponding revision is now included in the current draft, I'm going to close it.

I created a separate issue for the comments triggered by #16 (comment) : #30

I suggest we move all discussion there.