VLO Taskforce Virtual meeting December 15, 2014

Overall Topic: How to handle relations in CMDI

Participants: Peter, Hanna, Susanne, Axel, Thomas, Jens

• (1) Facets
  • Agreement: facet definitions as proposed by Hanna will be integrated in the VLO (via Kees Jan?) e.g. by means of tooltips
  • still open discussion: Should Continent and Country be merged to one (new) facet Spacial Coverage?
  • How should License be filled? A first implementation is available at ​http://aspra11.informatik.uni-leipzig.de:8080/vlo/search?1 The data appears to be very heterogeneous (license names, links to license texts, complete licence texts, general remarks such as "freely available"). For a search facet Licence Name seems more appropriate. This needs more discussion based on the analysis of the preview implementation.
  • Introduce a new display facet Speaker? Task: Hanna and Peter will provide a proposal.
  • Agreement: We will not propose a new search facet for annotation layers as this is a highly specialized feature of certain types of resources (e.g. corpora) only.
  • Further discussion on facets in January (see below point (3))

• (2) Relations
  • There is no general account for representing relations in the CMDI header. Therefore special relations should be provided within the components part of CMDI metadata records.
  • Proposal (as best-practice:) within the CMDI header only part-whole-relations (i.e. constituency) should be include (ResourceProxy, thus spanning acyclic graphs). These are of primary importance for the VLO wrt:
    • navigation
    • sorting
    • granularity issues (locating complete collections as opposed to single files of a corpus)
    • versioning (This can be modeled as a special case of constituency if we opt for "abstract" resources (as metadata only) that comprise all actual versions (either as "real" resources or metadata in case of complex resources such as corpora))
    • (These relations can also be directly mapped onto common Fedora installations.)
  • The VLO-WG will provide recommendations for the handling of all remaining relations via CMDI components:
    • an example set of CMDI components (maybe grouped together into one surrounding component) for different relations,
    • a list of recommended ISOcat-DCs for specific relation types.
  • Keeping relations in components ensures flexible adaptations to new relation types. When relations are expressed via the CMDI header, adding a new relation type implies a new version of CMDI.
  • Relations under consideration not only include those between texts but also possible relations between tools and services.
  • CMDI providers should provide information about relations at least in one way (from one document to another)
  • The provision of the inverse relation is optional.
  • The basis for the creation of CMDI components for relations is the selection of relations supported by OLAC-DCMI. --> Peter will prepare a proposal
  • resourceProxy's within the CMDI-Headers are not used to model/record relations but for the provision of adresses for different instances of a document only.
  • The <isPartOf>-list element already existing within the CMDI-Header could be deprecated. Task: Discuss this with the CMDI-taskforce (Axel?).
  • Open issues: Come up with best practice recommendations for relations in CMDI based on the discussion in the meeting.

• (3) Next meeting
  • The next 2 meetings will take place in January and February 2015
    • 21.-23.01.15: Facets, Relations, Preparation for the QA-Meeting in Feb.
    • 18.-20.01.15: Quality Assurance
  • Doodle: ​http://doodle.com/ckvkwvyewifvmx3c
    • Please fill in your availabilities until December 29th, 2014