Wednesday, 25 February 2015, 10:00 - 11:30 CET
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)
10:20-10:45 Use cases (Christian Ansorge)
10:45-11:15 Testbed set-up (Daniele Francioli, Michael Lutz)
11:15-11:25 Re3gistry & INSPIRE registry testing and open issues (Daniele Francioli & Emanuela Epure)
11:25-11:30 AOB
The agenda was approved as proposed.
The minutes of the previous meeting were accepted as they currently stand on the wiki.
The status of the open action items was reviewed. The status (on 2015-04-08) is as follows:
Christian presented the use cases which are documented in sub-issues of issue #2318.
On use case C (Extend existing codelist), Wolfgang asked how to prevent that too many codelists are being generated (for every llittle changes)? E.g. not just anyone should be able to extend a code list. Andreas agreed that can probably not be solved technically, but will depend on the behaviour of the one that accepts submission for the registry (the control body).
It was suggested that use cases A and D are basically the same use case - to search for existing items across the federation (the item can be of different item classes, e.g. code lists, application schemas, ...)
Michael suggested that the use cases should focus on what a user would like to achieve, and that the technology/architecture used to achieve it is not relevant at this stage.
Daniele presented a proposal for setting up the register federation testbed as well as a rough schedule [Slides: Set-up_testbed_registrer_federation.ppt].
Wolfgang asked whether there is an ISO/OGC scheme for register metadata to be used. Michael replied that the data model for registers from ISO 19135 could be a starting point. He also clarified that the mention of "capabilities" in the slides was just as an anology and that it is still to be decided how to implement this technically.
Christain asked whether the proposed architecture would mean that content would be harvested from other registries into a central registry. Daniele and Michael clarified that only register metadata would be harvested, not the actual register data. Norbert agreed that the actual data should only be linked.
Tõnis asked whether the extension information should not be available through the federation register. Daniele clarified that it is indeed the idea to have all metadata about the extensions available inside the federation available in the federation register, so that it can be queries to find out which extensions of an item are available in the federation. However, it may still be useful (or necessary) to also have extension information available locally, in particular about the items that are being extended.
[Action A6.6] JRC to elaborate the proposal and play it through for some of the proposed use cases to illustrate how they would be solved using the proposed approach.
The received feedback and proposed solutions for the following two issues was presented.
None.