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

Connection details

Recording: AdobeConnect, MP4

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. 

The following issues/questions were discussed:

• How to deal with registries that are actively being removed from the RoR?
  • Agreement: They should be removed from the RoR/federation
• How to deal with registers that are no longer included in registry descriptor files?
  • There was not conclusive agreement on how to handle this case. Since this could be an error in the registry descriptor, removal of a register could be raised as a warning or confirmation could be requested from the registry manager before removing the register from the RoR.

[Action] The next steps in the implementation of the RoR will be to

• implement the harvesting use case according to the specification
• specify the implementation of the search use case
• implement the search use case

AOB

• Michael L encouraged once more everyone to submit questions to the issue tracker that they have themselves or have been asked by INSPIRE stakeholders about registers and registries. 
• Please fill the doodle poll for the next meeting: http://doodle.com/poll/qv2am34y72nbxygs