...
| # | Question | Comments |
|---|
| 1.1 | What would be a minimum level of harmonization/standardization? | - This always depends on the use case.
- I assume the question means “minimum level of harmonisation done by the data provider. In that case, I would say “none”, because the necessary ETL steps needed to use data in an application will need to be done by the application developer (i.e. the data user) anyway.
- What is necessary as a minimum of course is that enough information on the structure and semantics of the data is well documented (ideally also in English and/or some machine-readable format), so that the application developer is able to do that transformation easily.
- Also, the use of well-established vocabularies for category-based attributes is helpful.
- Rules for identifiers, location information (CRS etc.)
|
| 1.2 | What would be the consequence of abandoning the one-size-fits-all approach to harmonization of data? | - A simplification could still mean a common approach/common requirements for all data sets, but at a much lower level of ambition (documentation up-front or even only on-demand rather than harmonisation up-front – see comment above)
- The consequence would be a shift of the burden from the data provider to the application developer (but e.g. the attempts of ESTAT to build pan-EU data sets has already shown that even now there is considerable effort involved at the application developer side).
- Removing the obligation to harmonise all data upfront would potentially also remove the duplicate implementations in some (most?) MS that is done only to meet the INSPIRE requirements, i.e. the same “as-is” data that is available in the national SDI would also be made available under INSPIRE (together with documentation on how to use it).
|
| 1.3 | What issues do you see related to interoperability when simplifying the technical provisions? | - It would also mean that more effort would need to be spent on documenting data structures and semantics.
- Potentially, data providers would use well-established vocabularies (unless INSPIRE put a requirement that part of the documentation would be a mapping to well-established vocabularies when sharing data).
|
| 1.4 | What would this mean in terms of cost reductions for data providers? | - This could mean considerable cost reductions, if data no longer has to be harmonised upfront.
- This would (partly) be compensated by additional cost if instead the data structure and semantics would have to be documented for all data sets. If this has to be provided only on demand, costs would be lower.
|
| 1.5 | Would MIMs (Minimal Interoperability Mechanisms) be the solutions as used in Open and Agile Smart Cities and Communities (OASC)? | - Some OASC MIMs (e.g. MIM-2, MIM-7) could be good sources for inspiration, but they seem to still be at an early stage in their development, so should not be taken up 1:1.
|
| 1.6 | How do you assess the impact of the alignment with HVD, OPD, Green Data Space? | - Question not really clear. What is meant by OPD?
- On the relation with HVD: if requirements on harmonisation are to be reduced drastically, INSPIRE could limit itself on adding a few provisions (e.g. on documenting data models, the use of common vocabularies of use of identifiers) on top of the HVD provisions.
|
Question 2: Establishment of a feedback mechanism (user feedback on data)
...
INSPIRE provides the governance structure for the data covered. When revising the directive reflection is also needed on optimizing the governance structure:
| # | Question | Comments |
|---|
| 2.1 | Who should be responsible for the governance of - collecting/assessing the requirements,
- identification of core datasets,
- endorsment of technical solutions.
| - This strongly depends on how many details are regulated in the Directive/Implementing Acts and how much is left to guidance or standardisation.
- What is meant here by “identification core data sets”? The definition of what data sets shall be in scope of the revised Directive? Or who in each MS identifies which of the data sets comply with that definition?
- The development of technical solution could be left to technical communities (e.g. in the GDDS), projects or standardisation bodies. There should still be a step of formal endorsement of recommended solutions (similar to the current Good Practice Process)
|
| 2.2 | How should it be organised? | - The current process for the management of Good Practices and artefacts seems to work well
|
| 2.3 | What will be the costs/who will cover? | - The development should be community-driven (and –paid), the endorsement and management process should be covered by the EC
|
Question 3: Data confidentially (mechanism, standards)
...