Monday, 18 January 2016, 10:00-11:30 CET
Recording (started with slight delay)
Agenda
[10:00-10:10] Welcome, approval of the agenda and minutes of the previous meeting (for discussion and agreement) (Michael Lutz)
[10:10-10:20] Updates in the RoR prototype
- See http://inspire-regadmin.jrc.ec.europa.eu/ror/
- Additional content
- Changes in the user interface & content model
[10:20-10:45] Registration process for registries/registers
- Slides: 20160118_MIWP-6_meeting_11.pptx
- Issues (exchange format): #2615 and #2616
[10:45-11:00] Planning next steps
[11:00-11:15] Collecting FAQs
[11:15-11:30] AOB
Minutes
Attendees
Anders Foureaux (SE), Heidi Vanparys (DK), Alejandra Sanchez, Jesus Barrera (ES), Norbert Pfaffinger (AT), Esa Tiainen (FI), Michael Noren, Christian Ansorge (EEA), Willem van Gemert, Eugeniu Castetchi (OP), Lorena Hernandez, Daniele Francioli, Emanuela Epure, Michael Lutz (JRC)
Welcome, approval of the agenda and minutes of the previous meeting
The minutes of the last meeting were approved without comments.
The agenda was approved as proposed.
Updates in the RoR prototype
Additional content
Daniele presented the updated RoR prototype (http://inspire-regadmin.jrc.ec.europa.eu/ror/). It contains additional content - several INSPIRE-related vocabularies (with extensions, but also sub-sets of the central INSPIRE code list register) from the EIONET data dictionary. Willem & Eugeniu asked why in the registers tab there were two different URI entries for the same item. Daniele explained that one is referring to the code list in the central INSPIRE registry and the other one to the EIONET extension.
Changes in the user interface & content model
The relations map chart shows the dependencies between registries and registers. Solid arrows show the "relies on" (extension/subset/profile) relations. Christian (EEA) pointed out that the direction of some of the relations should be reversed.
Heidi proposed to add the relation types to the legend of the relations map.
Michael L questioned the need for including the "Item class" information in the RoR tables and proposed to remove this information for the time being. It can be added again if a clear requirement arises.
[Action] JRC to make the agreed changes in the RoR prototype.
Registration process for registries/registers
Daniele presented a proposal for how organisations could register their registers in the RoR, including proposals for exchange formats for registries and registers (20160118_MIWP-6_meeting_11.pptx). In particular, he highlighted which is the information to be collected from both the registry and the relevant registers to be federated. Daniele pointed out the importance of defining an update frequency both for the registry and the registers, since the RoR will harvest the information based on these values. That way, only new or modified data will be collected instead of importing all the contents every time, which will contribute to have a more performant software.
Willem & Eugeniu asked if DCAT-AP could be used to describe the Registry/Registers, Michael L confirmed that this is indeed the proposal.
Michael N asked whether the registry exchange file will contain all registers, not only those intended to be exchanged with the federation. Michael L clarified that this is not necessarily the case and that each registry owner can decide (by creating the registry exchange file) which of the registers contained in the registry should be included in the federation.
Christian proposed that there should also be a push mechanism, not only harvesting. To keep the testbed simple (for registry owners) he proposed to start implementation with the push mechanism. Daniele said that so far, no push mechanism was planned, but that it could be added if really required. JRC and EEA agreed to further discuss the need for adding a push mechanism to the RoR.
Eugeniu asked whether, if the update frequency was set to "yearly", this implied that the harvest would be performed once a year? If so, users probably would prefer to set it to "daily", which from his experience can be challenging to debug. Daniele replied that the RoR would first use the updateFrequency information, but if for any reason there is a need to restart the harvesting manually, there will be the possibility of running it manually. Eugeniu agreed that allowing a manual harvest is essential.
Christian asked what was the motivation for splitting the registry from the register file. He would prefer keep the information on the registry and all its contained registers in a single file. Michael L explained that, by splitting the files, it is easier (and more performant) to only request the relevant information. Willem & Eugeniu agreed that they would prefer to have separate descriptions/files per asset. The approach proposed by Christian is the current approach in Joinup with ADMS. The OP have to provide one file containing the whole catalogue with all datasets, even if only one has changed. It was agreed to continue the discussion on the issue tracker (#2661).
Open issues on the exchange file format
Michael L announced that JRC will start implementing also the third use case (search index).
The currently proposed fields for the exchange format (#2615) were discussed. In a comment, Heidi suggested that, when register items from another register are reused in an extension, no information should be repeated that is already available in the source register. This will help ensuring consistency.
Michael L agreed in principle, but cautioned that for users of the extension, the additional information would be useful (without them having to request it from the source register in a separate request). There may be the need for different information for the federation exchange format and for the representation presented to the user. Alternatively, in the federation guidelines, methods could be included for ensuring consistency between registers that reuse items.
Norbert agreed that, if we assume that local registries use the same files for (a) providing content to the users, and (b) for participating in the registry federation, then all the content should be there (including "repeated" one). If different files are used, then "repeating" content in the files destined for registry federation should be avoided.
[Action] Daniele to differentiate fields required for newly defined items and items that are being reused from another register.
Collecting FAQs
Michael L encouraged everyone to submit questions to the issue tracker that they have themselves or have been asked by INSPIRE stakeholders about registers and registries. Martin Tuchyna will upload a number of questions shortly. Michael L encouraged everyone to propose answers to these questions until the next meeting, where the proposed answers will be discussed.
AOB
Please fill the doodle poll for the next meeting: http://doodle.com/poll/tye8cvx3pdcqp7yp