Tuesday, 26 May 2015
INSPIRE/GWF Conference, Lisbon
Draft Minutes
This informal meeting was attended by some MIWP-6 members that were present at the INSPIRE/GWF conference: Andreas von Dömming, Christian Ansorge, Martin Tuchyna, Tõnis Kardi, Michael Lutz
The discussion focused on possible implementations of the following use cases:
- Free-text search for register items using the RoR as access point
- Retrieving all extensions of a given register (or code list) using the RoR as access point
- Retrieving the content of a register extension including the content of the extended register using a federated registry as access point
The implementation scenarios are described on the wiki.
In the discussion, it was agreed that the work of MIWP-6 should focus on the APIs and exchange formats required to implement a federation, rather than guidelines for how to implement them in specific registry solutions. However, some scenarios for implementation and their pros and cons could also be described.
Possible simple API calls could be:
- Accessing an item: GET <item-URI>
- Free-text search for items in a registry: GET <registry-URI>?q=<keyword>
- Free-text search for items in a register: GET <register-URI>?q=<keyword>
- Structured search for an item: GET <registry/register-URI>?<key1>=<value1>&<key2>=<value2>&...
- Combined free-text and structured search: GET <registry/register-URI>?q=<keyword>&<key1>=<value1>&<key2>=<value2>&...
Another discussion topic was how to define and represent extensions. We looked at the example how code list extensions have been defined in the ELF project. Here an ELF code list has been defined as a container with items coming from the central INSPIRE code list being extended as well as additional values defined as well:
- INSPIRE code list: inspire/codelist/A with values
- inspire/codelist/A/v1
- inspire/codelist/A/v2
- ...
- ELF code list: elf/codelist/A with values
- inspire/codelist/A/v1
- inspire/codelist/A/v2
- ...
- elf/codelist/A/v3
- elf/codelist/A/v4
- ...
This means that the extension code list explicitly defines which of the values of the code list being extended should be included in the extension. In principle, the extension could thus decide not to include all of the values of the extended code list (e.g. to leave out the ones that are not relevant for the application supported by the extension). In this case, the extension would be a "profile" (i.e. a mix of a sub-set and extension) rather than a pure extension.
We discussed also different approaches for how to implement the "synchronisation" between the central registers and the extensions, so that any changes made in the central register are propagated to the extensions.
The following open questions / pointers were raised during the discussion:
- Should the results of use cases 1 and 2 be just the item ids (that can then be used to retrieve the item data) or should they include also the item data?
- The W3C Linked Data Platform specification contains a specification for containers of things
- Use a pull or push mechanism to provide information about what has changed in a federated register to the RoR to support incremental updates?
- Only consider "pure extensions" or also "profiles" (including restrictions)?