Page tree

Wednesday, 25 February 2015, 10:00 - 11:30 CET

Connection details

Draft 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)

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)

  • Multi-valued custom attributes (#2317)
  • XML schemas (#2320)

11:25-11:30 AOB

Draft Minutes

Attendees

  • MIWP-6 sub-group members:  Anders Foureaux, Andreas von Dömming, Chris Schubert, Christian Ansorge, Christine Laaboudie, Esa Tiainen, Jesus Barrera, Magnus Karge, Michael Lutz, Norbert Pfaffinger, Tõnis Kärdi, Wolfgang Tinkl.
  • Other attendees: Daniele Francioli, Emanuela Epure, Heidi Vanparys

Welcome and approval of the agenda

The agenda was approved as proposed.

Minutes of the previous meeting

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:

  • [Action A6.1] Michael to discuss with Jeremy Tandy the lead of the testbed task. - Done. Jeremy Tandy will not be able to lead this task, so JRC will take over this role.
  • [Action A6.2] Michael to investigate feasibility to fund a TG editor. - Done. Funding is available in JRC for this task. ToR are yet to be written.
  • [Action A6.3] Michael to update the TG ToR as proposed. - Done.
  • [Action A6.4] Magnus to investigate if we can share ISO/DIS 19135-1 with the group. - Done. The document is available to members of the MIWP-6 sub-group for the purpose of the MIWP-6 work [#2406].
  • [Action A6.5] Michael to discuss with conference organisers and report back. - Done. There is now a proposal from the MIWP-5 sub-group to organise a workshop on validation and certification, so the proposal would be not to organise a workshop on registers/registries. To be discussed in the next meeting whether we still would like to organise activities (e.g. at the JRC stand) around the MIWP-6 work.

Use cases

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.

Testbed set-up

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.

Re3gistry & INSPIRE registry testing and open issues

The received feedback and proposed solutions for the following two issues was presented.

  • Multi-valued custom attributes (#2317)
  • XML schemas (#2320)

AOB

None.

  • No labels