13th MIWP-6 sub-group meeting

Friday, 11 March 2016, 10:00-11:30 CET

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:45] Status registry federation testbed

See #2684
Feedback from participants
Next steps

[10:45-11:15] Updates in the RoR prototype

Specification of harvesting process

[11:00-11:15] AOB

Collecting FAQs

Minutes

Attendees

Chris Schubert (AT), Jesus Barrera (ES), Eugeniu Costetchi (EU PO), Michael Noren (EEA), Etienne Taffoureau (FR), Heidi Vanparys (DK), Esa Tiainen (FI), 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.

Status registry federation testbed

Example files were prepared by DK, ES and EEA. All files validated ok using the validation tool provided by JRC.

Feedback from participants of the testbed:

ES: See comments in #2684
DK: relatively straightforward, using a combination of the conformance class requirements and example files
EEA: sometimes difficult to understand the requirements in the conformance classes; used examples to create the descriptors.

The following issues/questions were discussed:

Is it necessary to provide an identifier (URI) for the organisation publishing a register/registry?
- Agreements:
  - An id is not necessary, i.e. the actor node can be a blank node (for simplicity).
  - If there are use cases in the future for uniquely identifying organisations in the RoR (and list them there), the requirement for an id can be added back again. In this case, it should not be the organisation's web site, but rather a local id (e.g. "eurogeographics") within the scope/namespace of the RoR or an existing URI, e.g. from DBPedia (http://dbpedia.org/resource/European_Commission), the Publications Office's list of Corporate Bodies (http://publications.europa.eu/mdr/authority/corporate-body/index.html) and/or WhoIsWho service
  - An optional property for the organisation's web site should be added.
- [Action] JRC to update the conformance classes accordingly.
The usage of xml:base, e.g. as used in ELF code lists
- This is currently not supported in the JRC validation tool
- While the use of xml:base for rdf:resource and rdf:about is allowed in the RDF/XML specification, it is not good practice and not widely supported by tools. Therefore, these properties should have the full URI (unabreviated).
- [Action] JRC to add a requirement or (strong) recommendation on using full URIs in the conformance classes wiki page.
Usage of dcat:dataset URI + content negotiation vs. location of the RDF files (as specified in dcat:distribution)
- Agreements:
  - If a distribution is present, the validator and RoR harvesting procedure should use this instead of trying to retrieve a RDF/XML document from the URI of the dcat:dataset
  - Since there can be several dcat:distributions, the one relevant for the register federation should have the dct:format property set to http://publications.europa.eu/resource/authority/file-type/RDF_XML. In addition, dcat:mediaType can be used for referring to media types included in the IANA list (see discussion in https://joinup.ec.europa.eu/asset/dcat_application_profile/issue/vo10-values-dctformat-and-dcatmediatype)
  - The URI of the dcat:dataset does not need to support proper content negotiation. The important thing is that it returns a valid RDF/XML document for an HTTP GET request with the HTTP Accept header set to 'application/rdf+xml'
- [Action] JRC to update the wording of the conformance class: instead of content negotiation, say "an HTTP GET request to the URI with the HTTP Accept header set to 'application/rdf+xml'" and add the requirement to add a dct:format property to the distribution
How to encode the description of a register?
- The registers's description shall be specified using a <skos:definition> sub-element of the rdf:Description element (rather than <dct:description> as wrongly specified in the requirements on the wiki).
- [Action] JRC to correct the requirement in the conformance classes wiki page.
Does the register descriptor have to include the external values?
- For the information to be stored in the RoR, it is enough to specify the dependencies (reliesOn relation) and the additionally defined values.
- For users of the extended register, the values reused from another register should be included as well. Otherwise it is e.g. unclear whether all or just a sub-set of values from the extended register are being reused.
- [Action] JRC to investigate whether the conformance classes can be split further in order to clarify this distinction.

Updates in the RoR prototype

Daniele presented the specification for the harvesting functionality of the RoR (this will be shared in the wiki shortly). Currently, the specification is focused on the "searching and browsing extensions" use case.