Friday, 24 April 2015, 10:00 - 11:30 CET
Agenda
10:00-10:10 Welcome and approval of the agenda (Michael Lutz)
10:10-10:20 Minutes of the previous meeting (for discussion and agreement) (Michael Lutz)
- review of open action items
10:20-10:45 Use cases (Christian Ansorge, Michael Lutz)
- See issue Use case section of TGs and #2318
10:45-11:00 Register of registers (Daniele Francioli, Emanuela Epure) [Slides: 20150424_RoR_First_ideas.ppt]
11:00-11:15 Testbed planning (Michael Lutz)
11:15-11:30 AOB
- Re3gistry and INSPIRE registry service releases
- INSPIRE conference
Minutes
Attendees
Anders Foureaux, Andreas von Dömming, Chris Schubert, Christian Ansorge, Michael Lutz, Norbert Pfaffinger, Oliver Seeger (for Wolfgang Tinkl), Daniele Francioli, Heidi Vanparys, Clément Jaquemet, Michael Noren, Martin Tuchyna, Jeremy Tandy
Welcome and approval of the agenda
A point on meeting frequency was added in AOB. Otherwise, the agenda was approved as proposed.
Minutes of the previous meeting
Michael reviewed the open action items from the last meeting. The following actions are still open:
- [Action A6.2] JRC to draft ToR for a TG editor.
- [Action A6.6] JRC to elaborate the proposal for the testbed set-up and play it through for some of the proposed use cases to illustrate how they would be solved using the proposed approach.
The minutes were approved as they stand on the wiki.
Use cases (UCs)
Christian and Michael presented the use cases currently documented in the use case section of TGs and the issue tracker (see #2318).
Michael asked about the difference between use cases B (#2332) and C (#2333). Christian explained that UC B is not necessarily related to the register federation. The links described in the UC are to other items in the same register. UC C is explicitly about extending an existing code list.
It was agreed that we should not include non-federation UCs in the TGs and testbed, but to focus instead on cross-organisational aspects. We will assume that the registries participating in the federation support basic register operations. The local creation of registers etc. should simply be stated as a precursor/pre-conditions to the use cases we are concerned with.
Michael suggested that also UC F (#2336) is a functrional requirement for a registry tool rather than a federation UC. Martin agreed, but said that it was an important issue to be addressed at the national registers and that it would be nice to discuss experiences on this topic in the sub-group. It was agreed that JRC will create a page on the wiki to keep track of such issues. [Action A6.7]
Michael asked whether UC G (#2331) is a use case or more a technical requirement to be considered in other UCs. Jeremy agreed that it should be considered in the workflows in other UCs. It was agreed that this is an important aspect, but that it should either be reworded as a UC or considered in other UCs.
Christian asked when to register an asset as a federation asset in the UC "Register an asset in the federation" - when it simply should become known in the federation, or only when it has references to other assets in the federation. Michael saird that it could be useful also to have "unlinked" assets in the RoR, e.g. the Slovakian Feature catalogue register that is not (currently) linked to anything. Christian suggested to rather focus only on assets that are linked to something. Michael agreed, but maybe we don't need to explicitly exclude the possibility to just register other assets (that are not (yet) connected to other assets).
On the UC "Register an extension of an asset in the federation", Christian suggested to also consider other associations (e.g. exact match).
On the UC "Retrieve (the ids of) all known extensions of a given register (item)", Jeremy stressed that since we can assume to be working with HTTP protocol, caching concerns could be delegated to infrastructure layer of HTTP.
On the UCs on operations on register items, it was agreed that
- the UC "Retrieve all register items of a register (item) extension (including the items in the extended register)" is crucial,
- the UC "Retrieve all register items of an a register (item), including the values in all known extensions" is also important, but maybe less so,
- the UC "Retrieve all register items of an extended register (item) that have been modified (changed status) since a given date" is mainly to be seen a utility function to support regular harvesting and should be considered with lower priority
Anders promised to document a business UC on validation. [Action A6.8] Jeremy suggested to consider the API from the UK registry implementation for validation of data / codelist value against a register. Martin asked whether validation was limited to code lists. Michael said that validation can be against any register, e.g. INSPIRE themes, conformance classes, etc. INSPIRE code lists have the specific feature that they can be extensible (or not), i.e. this needs to be considered during validation.
It was agreed that search across registers needs to be supported. Christian pointed out that this is already covered in UC A. Jeremy pointed to an example of the UK registry search API.
Jeremy also pointed out the UK registry discussion on "delegation" between registries - which includes the concepts of simple namespace forwarding and full registry federation.
Register of registers
Daniele presented some first ideas on how to structure the register of registers (RoR) [Slides: 20150424_RoR_First_ideas.ppt].
It was agreed that the RoR should also have a search function to find available assets and extensions in addition to a simple GET by id operation.
Heidi suggested that extension should not be handled as a separate register but rather as a property of the assets.
Heidi aksed what happens if an item in an extension is adopted to be part of the central INSPIRE registry at some point. Will the URI then change? This was not discussed further, but may become a use case at a later stage.
Jeremy pointed out that the RoR is just a normal register. Therefore, we should simply apply normal management regime for registers and just discuss the content model.
Testbed planning
Michael proposed the following approach to the testbed:
- Phase 1: RoR-related use cases
- Registering and retrieving assets (either existing production registers or test instances) and extensions
- Set up test instance of RoR
- Register assets and extensions in RoR
- Retrieve them
- Phase 2: register item use cases
- Retrieve register items for extensions
- Bottom-up
- Top-down
- Retrieve register items for extensions
- Phase 3 (?): Advanced use cases
EEA wil check internally if they can contribute with a test instance of Data Dictionary. [Action A6.9]
One (real) example to look at could be the recently published Corine Land Cover vocabulary (http://dd.eionet.europa.eu/vocabulary/landcover/clc), which could be considered an extension of the INSPIRE code list register (additional code list) and/or of the (empty) INSPIRE code list LandCoverClassValue (http://inspire.ec.europa.eu/codelist/LandCoverClassValue/).
Martin asked whether the the testbed will be distributed or run in a testing environment (at JRC). Michael said that the plan was to have a distributed testbed but that JRC can investigate whether we can set up a test environemt with different tools (Re3gistry, UK-LDReg, EEA data dict tool, others?) [Action A6.10]
AOB
Re3gistry and INSPIRE registry service releases
Michael announced the new releases of the INSPIRE registry service (release 5) and the Re3gistry software (v1.0), which were published earlier this week.
You can find more information here: https://joinup.ec.europa.eu/community/are3na/news/new-releases-re3gistry-software-and-inspire-registry-service
INSPIRE conference
Michael will propose to organise an informal meeting at the INSPIRE conference. Anders, Martin, Andreas, Christian and Michael will be attending the conference.
Meeting frequency
It was agreed to keep the meeting frequency at once per month. The next meeting will be in the week between 18-22 May [doodle]. There will be a dedicated call on use cases in the week before [doodle].