Relationships between GeoDCAT-AP and DCTERMS agent roles about geodcat-ap

[andrea-perego]

Original thread started in #32

Copying below the comments submitted so far:

@matthiaspalmer - #32 (comment) :

[...] I think it would makes sense to also state:

1. principalInvestigator, and processor as subproeprties of dcterms:contributor
2. originator as subproperty of dcterms:creator.
3. custodian, distributor and resourceProvider as subproperty of dcterms:publisher

At least, that is the semantics I read into these properties, do you agree?
I think it would be helpful with these statement to see when to use these properties as refinements of the more granular properties from dcterms.

@dr-shorthair - #32 (comment) :

Semantics and relationships between DC terms are traditionally rather informally defined. The canonical definitions of Dublin Core are not even RDF. So don't put too much weight on relationships to DC terms, and also don't interpolate to much back in DC.

@andrea-perego - #32 (comment) :

I think we should indeed be cautious in defining sub-property relationships with DCTERMS, unless there's a use case bringing forward this feature as a requirement.

Besides @dr-shorthair 's points, the issue is also that the generic definitions used for roles in ISO 19115:2003 do not help have a better understanding of their semantics.

@matthiaspalmer - #32 (comment) :

[...] @andrea-perego, my intention was to make implicit semantics explicit if it exists. Apparently it is not so.

Just to confirm, you are saying that there is a lack of explicit semantics in ISO 19115:2003 for these roles and that introducing the relations to DCTerms would introduce semantics that does not exist currently? That is, you are not saying that the suggested relations would go against some explicit semantics in ISO 19115:2003?

It would be interesting to know if the people involved here agree with my suggested subproperty statements and who would have the mandate to provide such an interpretation more formally.

I would also want to point out that every time this kind of non-decision is taken due to lack of semantics in clarifying what something really means, has the potential to create more confusion down the line. This confusion causes people who in many cases have less direct knowledge of how these standards came to be and what the intentions was to have long discussions and in the end make decisions. These decisions will be different in in different contexts and lead to interoperability problems. My personal experience with mapping various INSPIRE data to DCAT-AP is limited, but from what I have seen in only a few cases indicates that there is indeed a lot of confusion and the use of these roles are certainly one of these headaches.

@matthiaspalmer - #32 (comment) :

In response to @dr-shorthair, I think you are referring to the original 15 elements. The DCMI Metadata Terms on the other hand are defined formally in RDF Schema with proper subproperty relations, e.g. dcterms:creator being a rdfs:subPropertyOf dcterms:contributor. I think these are the canonical definitions since some time. Here you can find the RDF Schema www.dublincore.org/schemas/rdfs/.

The properties and classes of DCTerms have rather broad definitions though, but this is by intention as it helps to maximize their use in a wide variety of situations. However, I would not agree that they are informally defined as they are defined in RDFS.

DCAT and many other metadata specification / profiles reuse and refine DCTerms properties (and classes) as much as possible. Hence, in my opinion, the DCTerms properties are very suitable and should be the basis introducing new properties if at all possible.

@andrea-perego - #32 (comment) :

[...]

The problem is that the definitions of roles are quite vague in ISO 19115:2003 - they correspond to the ones in the mapping table in the GeoDCAT-AP spec:

https://semiceu.github.io/GeoDCAT-AP/drafts/2.0.0-draft-0.1/#table-responsible-party-roles

With such definitions, it is difficult to have a clear understanding of their semantic relationships with DCTERMS.