Wednesday, 9 December 2015, 10:00-11:00 CET
Agenda
[10:00-10:50] Registry federation exchange format
- Slides: MIWP-6_meeting_10.pptx
- Issue: #2615 and #2616
- Annotated exchange format example
[10:45-10:55] Feedback from MIG-T meeting
[10:55-11:00] AOB
Draft Minutes
Attendees
Anders Foureaux (SE), Heidi Vanparys (DK), Jesus Barrera (ES), Martin Tuchyna (SK), Norbert Pfaffinger (AT), Michael Noren (EEA), Willem van Gemert, Eugeniu Castetchi (OP), Lorena Hernandez, Daniele Francioli, Emanuela Epure, Michael Lutz (JRC)
Registry federation exchange format
Michael presents different posssible interpetations on how a register can be understood (see MIWP-6_meeting_10.pptx). The sub-group agrees to the proposed "extensional" interpretation, where the inclusion of an item in a register (or concept scheme) implies that the usage of that item is endorsed by the governing body.
Michael clarifies that registers in the context of the INSPIRE registry federation are always considered to be collections of concepts. The case of the INSPIRE code list register (which is a register of code lists, each of which is a register) is a specific case that will not be considered at the level of the RoR. It is agreed that in this case, SKOS concept schemes are a good representation of registers.
Daniele explains the example for an exchange format (see #2616 and the annotated exchange format example). The example implements the extension (from the ELF project) of the INSPIRE CurrentUseValue code list (http://inspire.ec.europa.eu/codelist/CurrentUseValue/).
The example makes use of the VOAF vocabulary for expressing dependencies between registers. VOAF is a vocabulary specification providing elements allowing the description of vocabularies (RDFS vocabularies or OWL ontologies) used in the Linked Data Cloud. In particular it provides properties expressing the different ways such vocabularies can rely on, extend, specify, annotate or otherwise link to each other. It relies itself on Dublin Core and voiD. The name of the vocabulary makes an explicit reference to FOAF because VOAF can be used to define networks of vocabularies in a way similar to the one FOAF is used to define networks of people.
For concepts re-used from another concept scheme, the proposed exchange format only lists the ID and the hierarchy relations and indicates that the listed concepts belong to the concept scheme representing the extension.
Daniele summarises the current discussions on which properties should be mandatory or optional in the exchange format (see #2615). In the following discussion it is pointed out that there may be a difference between the properties that are needed by the RoR (these will be very few as pointed out by Christian) and those that should be presented to a user of the local register for usability reasons (so that they don't have to look up re-used concepts in another register). The sub-group should define the properties strictly necessary for the RoR, but may give recommendations for which additional properties should also be added. There may be implementation scenarios where a local register is implemented as a simple HTML page or XML document. In such cases, the register provider would probably prefer to only provide the minimum necessary information in the SKOS/RDF exchange format, so that it can be harvested by the RoR. In other scenarios, the SKOS/RDF format will be just one of several formats that are provided by a registry to its users and it will serve the dual purpose of providing information to users and to the RoR. In this case, the SKOS/RDF representation will probably be richer.
Norbert highlights that the voaf:reliesOn property cannot be mandatory, since in some cases a register will not have any dependency on another one. It is agreed to distinguish not only mandatory and optional, but also conditional properties in the description of the exchange format. It is also agreed that the description should distinguish between the concepts required/recommended for reused vs. newly defined concepts.
Eugeniu agrees and suggests that statements about concepts defined in someone else's register should be limited to semantic relations (e.g. broader/narrower or inScheme). Michael agrees but says that multilingualism (e.g. providing a label or description in an additional language) could be an exception.
On the use of voaf:reliesOn, Michael clarifies that its main purpose is to provide metadata on dependencies between registers.
Michael concludes that the proposal for the exchange format will be updated based on the discussions in the meeting [Action Daniele] and that all should make any further comments on the relevant issues on the platform.
Feedback from MIG-T meeting
The MIG-T has accepted the proposed changes to the terms of reference. They don't need to be endorsed by the MIG-P. Michael will send around the new terms of reference and ask all members whether they would like to stay in the group for another 6 months [Action Michael].
From side discussions at the meeting, there seems to be a need for an FAQ or simple guidelines on setting up national or thematic registers in INSPIRE. These could address questions such as:
- What does it mean to publish an extension in a register? Is it enough to publish an excel file on an FTP server?
- How do I know if an code list is extensible or not?
- The importance of persistent identifiers
It was agreed to collect such questions in the issue tracker, which can then also be used to elaborate the answers [Action all]. Later, these can be translated into guidelines or an FAQ page. #2637 is an example for collecting FAQ questions and discuss about the answers. Please use "Support" issues and start the subject with [FAQ] to collect questions.
AOB
Please fill the doodle for the next meeting (in mid January) at http://doodle.com/poll/bbnkr7bbfhhh643a