Tuesday, 19 May 2015, 15:00 - 16:30 CEST
Agenda
15:00-15:10 Welcome and approval of the agenda (Michael Lutz)
15:10-15:20 Minutes of the previous meeting (for discussion and agreement) (Michael Lutz)
- review of open action items
15:20-15:45 Use cases (Christian Ansorge)
- See Use case section of TGs
- Report on status of use case discussions and meeting on 12/5/2015
15:45-16:15 Testbed planning (Michael Lutz)
- Proposed initial content for the testbed (see Federation example content)
- Architecture scenarios [20150519_Federation_architecture.pptx]
16:15-16:30 AOB
- INSPIRE conference (see doodle at http://doodle.com/tas3pkxma8un8cyb)
Draft Minutes
Attendees
Anders Foureaux, Andreas von Dömming, Christian Ansorge, Norbert Pfaffinger, Daniele Francioli, Clément Jaquemet, Michael Noren, Christine Laaboudie, Jesus Barrera, Alejandra Sanchez, Michael Lutz
Welcome and approval of the agenda
The agenda was approved as proposed.
Minutes of the previous meeting
The minutes of the previous meeting were approved as currently on the wiki.
The following actions are still open:
- A6.8: Anders to document a business UC on validation
- A6.9: EEA to check internally if they can contribute with a test instance of Data Dictionary
- A6.10: JRC to investigate whether we can set up a test environemt with different tools (Re3gistry, UK-LDReg, EEA data dict tool, others?)
Use cases
Christian presented the status of use case discussions and the meeting on 12/5/2015 (see Use case section of TGs). Michael Noren proposed to use user stories (from agile SW development) rather than or in addition to the more detailed UC descriptions used so far (see section "Alternative way of describing the use cases" in the Use Case chapter). It was generally agreed that user stories provide a detailed and easy-to-understand way of presenting user requirements, but that we should not completely switch approach and throw away the work already done for the definition of the use cases. It was agreed to use a combination of both and to focus discussions at this point on the technical architecture and design decisions. When we have a clearer picture of the overall architectural approach, we should revisit and refine the UCs and user stories in the guidelines.
Testbed planning
Michael Lutz presented some example content for the register federation (see Federation example content), which could be used as initial content for the testbed and also for specifying more precisely what behaviour we expect from the register federation "system" for specific requests or queries (by specifying what data a request or query should return).
It was agreed that it will be crucial to agree on how extensions should be represented and published, e.g. whether a copy of the items from the extended register should be held in the extending register.
Michael also presented a number of architectural scenarios for search and retrieval use cases (see attachment:20150519_Federation_architecture.pptx). The scenarios illustrate different options for implementing a search through the register federation (e.g. using "live" cascading requests vs. keeping a search index at the level of the RoR).
Michael Noren commented that federated search has the inherent problem of producing a good ranking of the search results, generally makes searches slow and requires each local registry to provide a search API. Clément agreed that distributed queries seem not to be necessary and bring complexity without added value. He proposed to follow an approach similar to that for the discovery service and geoportal.
It was agreed that the Register of registers (RoR) (rather than a local registry) should be considered as the main query endpoint, since the federation will be based on different software implementations, and we should try to avoid having to make (many) changes in these existing systems.
Andreas cautioned that also a search scenario with the RoR as main entry point would require an API at the level of the local registers. Michael said that this depends on how search is implemented - as distributed (on the fly) search or through an index at the RoR. Andreas agreed, but said that APIs might still be required for maintaining the index.
It was agreed to further develop the scenarios, using a use case (or user story) and some example register federation content as a starting point. JRC will create a first draft based on the presented slides and discussion during the meeting. [Action A6.11] The scenarios should also discuss pros and cons and possible implications for each scenario. Norbert stressed that the decision on the preferred architecture will depend on non-functional requirements. Michael said that in some cases, it may be possible to also support more than one of the described scenarios, in order to give more flexibility.
AOB
Michael reminded all participants of the INSPIRE/GWF conference to fill the doodle at http://doodle.com/tas3pkxma8un8cyb.