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
19 stars 6 forks source link

Define new properties for responsible party roles? #32

Closed andrea-perego closed 3 years ago

andrea-perego commented 3 years ago

ℹ️ Following discussion in https://github.com/SEMICeu/GeoDCAT-AP/issues/30 . See also https://github.com/SEMICeu/GeoDCAT-AP/issues/16 and §7 (Agent roles) for background information.

The purpose of this proposal is to provide a simple way to specify all the ISO 19115 responsible party roles used in INSPIRE, as an alternative to the use of the approach based on the W3C PROV Ontology (prov:qualifiedAttribution).

The properties to be defined should be limited to those not supported in Dublin Core and DCAT, as shown in the relevant mapping table of the GeoDCAT-AP specification - namely:

andrea-perego commented 3 years ago

Tentative RDF definition:

<http://data.europa.eu/930/custodian>
  a rdf:Property, owl:ObjectProperty ;
  rdfs:label "Custodian"@en ;
  rdfs:comment "Party that accepts accountability and responsibility for the data and ensures appropriate care and maintenance of the resource."@en ;
  rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
  rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/custodian> .

<http://data.europa.eu/930/distributor>
  a rdf:Property, owl:ObjectProperty ;
  rdfs:label "Distributor"@en ;
  rdfs:comment "Party who distributes the resource."@en ;
  rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
  rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/distributor> ;
  skos:exactMatch <http://www.w3.org/ns/duv#hasDistributor> .

<http://data.europa.eu/930/originator>
  a rdf:Property, owl:ObjectProperty ;
  rdfs:label "Originator"@en ;
  rdfs:comment "Party who created the resource."@en ;
  rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
  rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/originator> .

<http://data.europa.eu/930/principalInvestigator>
  a rdf:Property, owl:ObjectProperty ;
  rdfs:label "Principal investigator"@en ;
  rdfs:comment "Key party responsible for gathering information and conducting research."@en ;
  rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
  rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/principalInvestigator> .

<http://data.europa.eu/930/processor>
  a rdf:Property, owl:ObjectProperty ;
  rdfs:label "Processor"@en ;
  rdfs:comment "Party who has processed the data in a manner such that the resource has been modified."@en ;
  rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
  rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/processor> .

<http://data.europa.eu/930/resourceProvider>
  a rdf:Property, owl:ObjectProperty ;
  rdfs:label "Resource provider"@en ;
  rdfs:comment "Party that supplies the resource."@en ;
  rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
  rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/resourceProvider> .

<http://data.europa.eu/930/user>
  a rdf:Property, owl:ObjectProperty ;
  rdfs:label "User"@en ;
  rdfs:comment "Party who uses the resource."@en ;
  rdfs:isDefinedBy <http://data.europa.eu/eli/reg/2008/1205/2008-12-24>, <https://www.iso.org/standard/26020.html>, <https://www.iso.org/standard/53798.html> ;
  rdfs:seeAlso <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/user> ;
  skos:relatedMatch dct:audience .
AntoRot commented 3 years ago

I agree with this very good proposal in line with what suggested in DCAT-AP section 7 related to the agent roles, i.e. "extensions to the base profile may be defined using additional properties with more specific meanings".

andrea-perego commented 3 years ago

Thanks, @AntoRot .

@matthiaspalmer , may I ask if you have any comments on this proposal?

matthiaspalmer commented 3 years ago

I think it is fine, but 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 commented 3 years ago

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 commented 3 years ago

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.

I would propose that we first add these properties in the GeoDCAT-AP namespace, and we then consider refining their definitions, if need be.

@matthiaspalmer , would this be an acceptable solution for you?

matthiaspalmer commented 3 years ago

Of course @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 commented 3 years ago

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 commented 3 years ago

@matthiaspalmer said:

Of course @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?

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.

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.

If you think it would be useful, we can also create a specific issue on this.

My point was that the priority is to decide whether to define or not these properties. If we all agree to create them, we can further refine their definition in this version of GeoDCAT-AP, or in a later one.

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.

It would important to collect all these issues and see whether and how we can address them. Besides those about the semantics of roles, do you have any other to report, @matthiaspalmer ?

andrea-perego commented 3 years ago

A full definition for these properties is in PR https://github.com/SEMICeu/GeoDCAT-AP/pull/33

Could you please check if you are happy with it?

andrea-perego commented 3 years ago

Thanks, @AntoRot .

RDF vocabulary and specification updated via PR https://github.com/SEMICeu/GeoDCAT-AP/pull/33

PROPOSED RESOLUTION: Implement changes in the current draft with the purpose of including these properties in version 2 of GeoDCAT-AP

andrea-perego commented 3 years ago

No negative vote - resolution approved.

I'm going to merge PR https://github.com/SEMICeu/GeoDCAT-AP/pull/33 and close this issue.

I have created a new issue (https://github.com/SEMICeu/GeoDCAT-AP/issues/57) for the discussion about making the newly defined agent roles subproperties of the DCTERMS ones.

@AntoRot , @matthiaspalmer , @dr-shorthair , thanks for your contributions.