MIWP 4a: Set up sub-group on Persistent Identifiers (PID)
|Status:||Closed||Start date:||25 Nov 2014|
|Assignee:||Christian Ansorge||% Done:|
|Proposed change or action:|
During the MIG-T meeting in London, 30/09/2014 - 1/10/2014 it was decided to address the topic of Persistent Identifiers separately (originally MIWP4 covers both, PID and RDF), as it present on obstacle to the implementation of INSPIRE, and to establish a subgroup dealing with identified issues.
#2 Updated by Michael Lutz almost 6 years ago
- File ARE3NA_PID_study_GOFA_model.jpg added
Thanks for starting on the ToR for MIWP-4a.
I think the description of the issues and tasks are still too general - we should make them more specific, where we can.
For example, in the scope description, it should be stated what kind of ids (for what kinds of entities) the group should address - only external object ids (inspireIds, identifying spatial objects) or also thematic ids (identifying real-world entities) and/or ids for information items (e.g. code lists, themes, vocabulary elements, ...). Also it is unclear whether the development of tools is in or out of scope.
Other aspects that I think should be considered are:
- the organisational aspects of ensuring persistence (as was suggested in the ARE3NA PID study)
- use cases for PIDs (e.g. coming from e-reporting pilots)
Maybe the GOFA model from the ARE3NA PID study could be useful for defining the scope (which aspects are in and which are out).
Finally, the timeline may be too short for this work (depending of course on what we define as the scope).
#4 Updated by Christian Ansorge almost 6 years ago
- To work out the issues and use cases more specifically it was decided to identify them in a small working group
- Scope: More specific ToR available until the next MIG-T meeting 18/12/2014
- EEA takes the lead as facilitator until the ToR are developed
#6 Updated by Christian Ansorge almost 6 years ago
Find attached the updated version of the Terms of Reference for MIWP-4a: Persistent Identifiers (PID). Any comments are welcome.
Special thanks to Morten Borrebæk, Chris Schubert, Markus Seifert and Andrea Perego for their contribution in the process of specifying the the issues and tasks for this particular working group.
#7 Updated by Michael Lutz almost 6 years ago
Thanks, Christian and all, for the updated proposal.
I must say that I still find it quite generic, and the scope and the concrete problems this action is going to solve are still not clear to me. For example, will the scope be on
- only external object ids, or also other ids?
- better guidelines or best practices or just an overview where to find what in the existing TGs?
- on an overview of existing tools or also on tool development?
The proposed outputs also stay at a very generic level:
- Propose measures ...
- Implement selected measures ...
Overall, I have the feeling that this activity still needs some further elaboration and deeper investigation. In my view, all tasks listed in group A should be done as an analysis before proposing this as an MIWP action and before setting up a sub-group, in particular:
- Specify the use case for the usage of identifiers
- Identify inconsistencies between INSPIRE documentation and legal or technical implementation
Maybe we should do a further survey among the MS (and other stakeholders) for concrete descriptions of problems that implementers had with regard to PIDs.
#8 Updated by Christian Ansorge almost 6 years ago
Thanks for the quick reply, but I am afraid I have to disagree with the points you made.
Scope: As written in the ToR it is proposed to focus within A on a group of identifiers (not all, but to go broader than just the INSPIRE ID), while part B clearly is focusing on INSPIRE Spatial Object Identifiers. Furthermore it is written, that the subgroup is focusing on developing common guidelines for INSPIRE Spatial Object Identifiers (Part B). In order to develop the common guidelines we have to get an overview of what is going on and available in the countries. Tool development is not mentioned in the tasks.
Proposed outcomes: Indeed this needs an update. Sorry, this article I overlooked and an update comes after the MIG-T webex.
Why do you see block A not as a task for the MIWP? In my point of view this is more than a short analysis and especially the PID use cases development is in my point of view a clear task for MIWP.
Let's discuss that.
#9 Updated by Michael Lutz almost 6 years ago
the main point I was trying to make is that where we already know more precisely the use cases, requirements and existing problems, we should write them down explicitly. For example, possible use cases include:
- I am a data user accessing an INSPIRE data set with links to spatial objects in other data sets (e.g. Addresses to Buildings or Cadastral Parcels). The link is expressed through the inspireId. I want to be able to use the inspireId to access the remote object.
- To implement this use case, there needs to be some mechanism to resolve/dereference the inspireId to a representation of the object. This can e.g. be done through a namespace register as is currently I believe beinhg set up in Germany that re-directs from spatial object ids to the corresponding direct download service request.
- I am a data publisher and need to manage persistent and unique identifiers. This leads to the questions of how to ensure
- uniqueness --> this can simply be ensured by using resolvable http URIs (because uniqueness is ensured by the DNS system)
- persistence --> this is a more tricky question, because it is related to organisational aspects of organisations. This could also involve a discussion on URI patterns
Possible problems could include:
- Information on ids in INSPIRE is distributed in different documents, and some of the examples are inconsistent (but we already seem to know which ones)
- This could simply be solved through an overview document summarising the most important points and corrigenda of the inconsistent examples
I would like to see the "problem description" at this level (where we can already be more precise).
#10 Updated by Michael Lutz almost 6 years ago
Comment from Norway (sent by Arvid):
From our point of view we should focus on “best practise” for implementation. The use cases described in the INSPIRE generic conceptual model is OK for me. I see no reason to discuss again whether the directive states that the PID’s should be traceable or not (we need traceability to ensure that the data are authoritative).
So, with full respect for EEA and other agencies or member nations that wish a more comprehensive approach, my proposal would be to:
- Not initiate package A (or do a quick research in advance on inconsistencies between the legal text and technical guidance documents regarding PID’s). I do not think we need a sub-group to do this.
- Initiate package B. Immediately (if possible) work on URI (http), but not exclude other implementations if required. Separate generic governance rules from the governance rules related to the chosen technology for implementation (for example URI).
- Not initiate package C, but add the tool support/descriptions to the work in package B.
This was also my message during the telecons, but as we state earlier we fully respect that others may have a more comprehensive approach.
If we the work on existing documents like:
- INSPIRE Generic Conceptual Model
- ARE3NA PID Governance
- ISA publication " D7.1.3 - Study on persistent URIs, with identification of best practices and recommendations on the topic for the MSs and the EC"
- ELF PID governance
It should not need to be a large project.
The work on PID is very special. When you first have chosen a solutions (for example a URI pattern), you should not change it, even if the chosen solution is not optimal (because it is persistent and should not be changed in the lifetime of the object). So any additional best practise is urgent.
#11 Updated by Marc Leobet almost 6 years ago
- File ToR of French GT URI.doc added
at last I found some time to translate in English the Term of reference of the French Working Group "URI". The FR version is here.We decided it last Summer after some debates writing the Technical guidelines for services (in FR only).
We are late, so I am not in position to share with you a French proposal. Perhaps these ToR could be usefull as a use case.