Skip to main content

GeoDCAT-AP - How to express the different responsible party roles supported in ISO 19115 / INSPIRE

Portal Admin
Published on: 13/04/2015 Discussion Archived

Issue raised by Andrea Perego: http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2015-April/000021.html

 

What are the alternatives to encode the different responsible party roles supported in ISO 19115 / INSPIRE?

 

The 1st WG Draft of the GeoDCAT-AP (based on the INSPIRE+DCAT-AP alignment work done earlier) proposes to:

  • Represent responsible organisations by using the PROV ontology (prov:qualifiedAttribution)
  • If suitable candidates exist from widely used vocabularies, use them to represent the corresponding responsible parties and their roles, based on an agreed definition of 1-to-1 mappings.

 

INSPIRE Metadata Regulation [1]

Responsible party role

Description

Proposed RDF mapping

Mapping status

Part B §10.1

Metadata point of contact

This is the description of the organisation responsible for the creation and maintenance of the metadata.

dcat:contactPoint

Stable

Part B §6.1

Resource provider

Party that supplies the resource.

N/A

 

Part B §6.2

Custodian

Party that accepts accountability and responsibility for the data and ensures appropriate care and maintenance of the resource.

N/A

 

Part B §6.3

Owner

Party that owns the resource.

dct:rightsHolder

Stable

Part B §6.4

User

Party who uses the resource.

N/A

 

Part B §6.5

Distributor

Party who distributes the resource

N/a

 

Part B §6.6

Originator

Party who created the resource.

dct:creator

Stable

Part B §6.7

Point of contact

Party who can be contacted for acquiring knowledge about or acquisition of the resource.

dcat:contactPoint

Stable

Part B §6.8

Principal investigator

Key party responsible for gathering information and conducting research

N/A

 

Part B §6.9

Processor

Party who has processed the data in a manner such that the resource has been modified.

N/A

 

Part B §6.10

Publisher

Party who published the resource

dct:publisher

Stable

Part B §6.11

Author

Party who authored the resource.

N/A

 

 

MODIFIED: 15 May - fixed type dcat:creator into dct:creator

Component

Code

Category

support

Comments

stijngoedertier (not verified) Wed, 15/04/2015 - 13:11

Makx Dekkers suggested using dct:contributor for the roles for which no other property is found.

 

"The current, 'simple' proposal on the table in DCAT-AP revision is to only distinguish between the responsible agent (dct:creator) and the publisher (dct:publisher). I think those two roles are quite common and have some legal importance; other roles could maybe be shoehorned into dct:contributor?"

Andrea PEREGO
Andrea PEREGO Fri, 17/04/2015 - 02:04

Thanks for the clarification and for your proposal, Makx.

Squeezing a number of roles into a single one (e.g., dct:contributor) can be an option to be discussed by the GeoDCAT-AP WG. Of course, an objection can be that this will result in a semantic loss, which would raise the question whether we'd better keep those roles "un-mapped". The only advantage of this many-to-one mapping is to keep in the target metadata record the list of responsible organisations included in the original one, but would this be useful if their actual role is lost?

This also gives me the opportunity to explain the rationale behind the approach proposed in the current draft, which is basically the following one:

  1. suggest a general way to model in the target metadata record the original role (the current proposal is to use the PROV ontology)
  2. suggest alternative mappings for those role supported in DCAT-AP or in popular vocabularies (in particular, Dublin Core)

About point (1), the proposal is to use the following pattern:

[] a dcat:Dataset; 
  prov:qualifiedAttribution [ a prov:Attribution ;
    dct:type a:role ;
      prov:agent a:Agent ] .

where:

  • a:role is the role URI of the relevant code list in the INSPIRE Registry;
  • a:Agent is the class instance (e.g., foaf:Agent, vcard:Kind) corresponding to the responsible party.

Note that options (1) and (2) are not mutually exclusive. They can co-exist. Moreover, we can have mutual mappings for those roles in point (2). E.g., the following statement:

[] a dcat:Dataset;
  dct:rightsHolder [ a foaf:Organization ;
    foaf:name "European Union"@en ] .

is meant to be equivalent to:

[] a dcat:Dataset; 
  prov:qualifiedAttribution [ a prov:Attribution ;
    dct:type <http://inspire.ec.europa.eu/metadata-codelist/ResponsiblePartyRole/owner/> ;
      prov:agent [ a foaf:Organization ;
        foaf:name "European Union"@en ] ] .

The mapping between the two can also be modelled (and implemented) by using SPARQL CONSTRUCT queries, as done in the W3C Dublin Core to PROV Mapping specification.

Finally, since there's a related issue in the scope of DCAT-AP, it is worth noting that this solution is not domain specific. It can be re-used across domains to address the same issue, just by changing, if needed, the role code list. In this case, interoperability can be ensured by specifying alignment across role code lists, e.g., by using SKOS matching relations.

Antonio ROTUNDO
Antonio ROTUNDO Mon, 27/04/2015 - 12:49

In the Organization Ontology there is a specific class (org:Role) to denote the role of an Agent in an organization. The proposal is to use that class for all the roles that are not yet mapped to DCAT-AP elements and denote the roles by using the role code list operated by the INSPIRE Registry. The use of ORG is recommended also in DCAT-AP if an Agent is an organization (concerning spatial dataset and services, in most cases).

Andrea PEREGO
Andrea PEREGO Tue, 28/04/2015 - 15:59

Thanks, Antonio.

The problem I see with property org:role is that its scope is too specific.

As you say, org:role denotes the role played by an individual as a member of an organisation or as a holder of a specific post.

On the other hand, we need a property able to specify the role played by an individual wrt a generic resource (specifically, a dataset or a service). Based on the current GeoDCAT-AP proposal, the domain should then be prov:Attribution, whereas the domain of org:role is formally defined as the union of org:Membership and org:Post.

stijngoedertier (not verified) Fri, 15/05/2015 - 09:34

During the 3rd WG meeting of 29 April 2015, it was decided by vote that

  • GeoDCAT-AP Core: The proposed alignments for responsible party roles metadata elements in GeoDCAT-AP Core (dct:creator, dct:publisher, dcat:contactPoint) are accepted by the Working Group.
  • GeoDCAT-AP Extended: The proposed syntax binding for the Responsible Party Role using prov:qualifiedAttribution in combination with a dct:type assertion pointing to the code list for ResponsiblePartyRole in the INSPIRE registry in the GeoDCAT-AP Extended is accepted.