Comments (11)
Original thread started in #16
Copying below the comments submitted so far:
@andrea-perego - #16 (comment)
@AntoRot said:
- 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 roleoriginator
as well as with the roleauthor
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.
- 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, onlydcat:contactPoint
should be used in GeoDCAT-AP without usingprov:qualifiedAttribution
in this case. In the example 39 bothdcat:contactPoint
andprov: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 usingprov: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 caseprov: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:
- Whether to support 1-to-many mappings
- Whether to keep providing support to roles not required in INSPIRE for specific resources - e.g., catalogue records
- 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:
- 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:
- Provide a mechanism to express roles not supported in DCAT and DCTERMS, in order to avoid information loss
- 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.
Related Issues (20)
- Remove example for Media Type as it is confusing
- Improve notes on using embedded objects vs. references HOT 2
- Relation of various Agent classes used throughout the specification
- Revise usage of Licenses and Rights HOT 2
- DataService protocol mapped to `dct:conformsTo`
- Dataservice protocol list HOT 3
- Info: licenses in Flanders
- Access rights codelist issue
- Shared codelist for spatial concepts
- Format Publications Office HOT 1
- Info: on distribution / dataservice mapping rules HOT 1
- Info: entity conformity
- Info: mapping lineage statements
- pitfalls for metadata providers regarding expected mapping of distributions , digitaltransfers from ISO19115/19139 metadata to GeoDCAT-AP HOT 1
- Mapping of ISO metadata datestamp to DCAT HOT 4
- Mapping ISO dates to GeoDCAT-AP HOT 1
- The representation of the spatialResolution should be clearer specified and explained HOT 5
- The new GeoDCAT-AP should be defined as profile of the upcoming OGC GeoDCAT Specification HOT 2
- Mapping of metadataStandardName HOT 1
- applicableLegislationrequired for geospatial HVD´s HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from geodcat-ap.