-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Responsible party roles #30
Comments
Original thread started in #16 Copying below the comments submitted so far: @andrea-perego - #16 (comment)
@bertvannuffelen - #16 (comment)
@matthiaspalmer - #16 (comment)
|
Trying to summarise: We are discussing 3 separate - although related - issues here:
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? |
I agree that the approach decided in #23 should be also followed for the second issue listed in your comment. |
Thanks, @AntoRot . About this point:
I think it would be important to clarify that the purpose of having in place these 2 non-mutually-exclusive approaches is twofold:
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? |
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. |
First, I am ok with keeping two options in the specification. 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. |
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 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 |
@AntoRot , @matthiaspalmer , unless you have any comments, I will proceed and merge PR #31 . |
- Remove EDNOTE in §1.2 - Revision done. - Remove EDNOTE in §1.3 - Revision done. - Update EDNOTEs in §2: - A definition for data service has been included. - A definition for deprecated classes and properties has been included. - A diagram has been created. - Remove EDNOTE in §2: - A paragraph for deprecated classes has been included. - Add NOTE in §2: - To make explicit that the diagram is not exhaustive - Add link to issue #35 in §2. - Add link to issue #36 in §3 - Add link to issue #30 in §7. - Remove EDNOTE in §B: - This section has been updated and revised. - Remove EDNOTE in §C: - The changelog has been revised. - Remove links to closed issues. - Editorial fixes.
Indeed no other comments from my side. Thanks. |
Review originally submitted in #16 (comment) by @AntoRot
The text was updated successfully, but these errors were encountered: