MIMO and EDM

Musical Instrument Museums Online (MIMO) was a project that ran from September 2009 to August 2011, and acted as a consortium of some of Europe's most important musical instruments museums. Within a specific project, MIMO brought together digital collections of musical instruments and has created a single online access point to them within Europeana. MIMO delivered 43,234 records represented in EDM to Europeana. It was the first time an aggregator had delivered data to Europeana using the Europeana Data Model. This experience has raised issues which were really useful for the Europeana Office in the implementation of EDM.

The data was generated from LIDO metadata and transformed in EDM, using an XSLT stylesheet, which uses the EDM XML schema at http://www.europeana.eu/schemas/edm/. The mapping was based on the EDM template for Europeana providers. Specific metadata examples can be found on the EuropeanaLabs wiki.

1) General approach
The MIMO project was interested in delivering their data in EDM instead of ESE in order to take advantage of the richness of the data aggregated within the project and to benefit from the potential of EDM in term of link representation.

2) Attaching several digital representations to one CHO
MIMO provided multiple digital resources, from images to audiovisual content (CHO) - musical instruments in most of the cases. EDM allows these different resources to be connected to each other and enriches the global context of the object aggregated. In the example below, the cultural heritage object is provided with three different digital representations. This situation results in the creation of three different 'edm:WebResources' pointing to three images (jpeg).

Clavicorde lié dit de Lépante from Cité de la Musique http://www.europeana.eu/portal/record/09102/33711D0A88B8AD6D719112CDD9D37EE77526BC94.html

If EDM was to allow MIMO to provide multiple digital representations for each CHO, a decision had to be made for the Europeana portal. MIMO had to identify a ‘preferred' view of each object which would be displayed as a preview in the Europeana portal.

Since the three digital representations of the CHO could have different usage and access rights, EDM allows one edm:rights element per 'edm:WebResource'.

3) Mapping specificities
The main task for MIMO was to map the original LIDO properties to the EDM properties.
Most issues here are linked to the fact that some properties in EDM are using literals while others are using references, and to the use of the properties with the appropriate classes.

Use of literals vs. references
For example, Europeana requires 'edm:dataProvider' and 'edm:provider' information to track the provenance of the data and build a facet on this element. These two properties belong to the aggregation class. MIMO uses a URI to identify a data provider and its aggregation. However, since Europeana doesn't use any controlled lists to define its contributors it has been decided to keep a literal in the properties 'edm:dataProvider' and 'edm:provider' for now.

Conversely, some EDM properties only support references, such as 'edm:isShownBy' and 'edm:isShownAt' which link to the digital object and 'edm:rights', the value of which needs to be a URI taken from a controlled list.

Attaching a property to the right EDM resource
'Edm:rights' indicates ‘the usage and access rights that apply to this digital representation'. The issue for MIMO was to decide at which level they needed to use this property. EDM allows the use of 'edm:rights' for each CHO at the 'ore:Aggregation' level and at the 'edm:WebResource' level. Since EDM allows multiple 'edm:WebResources' per CHO, it would be possible to attach one rights statement per 'edm:WebResource'. The rights statements could be concurrent.

However, in its first implementation of EDM, Europeana retained the coarse-grained rights management approach of ESE, with one rights value per record. It still required one ‘default' rights value associated with the 'ore:Aggregation' resource, as well as all possible individual values for all the 'edm:WebResources'. MIMO decided to apply the licence creativecommons.org/licenses/by-nc-sa/3.0/ to all 'edm:WebResources' and the 'ore:Aggregation'.

4) Linking instead of creating new resources
In addition to the descriptive metadata for the CHO itself, MIMO has a lot of information on resources related to the CHO, which brings context to it. EDM allows the representation of such information by using specific contextual entities that allow semantic enrichment of the data. MIMO chose two different approaches in order to provide richer contextual information.The first approach is to link the existing data to existing resources available in the semantic web.

In order to enrich its data with spatial information MIMO used the contextual entity 'edm:Place' which can be used to describe any spatial location. MIMO used GeoNames to find a URI corresponding to the place associated with the CHO.

<edm:Place rdf:about="http://sws.geonames.org/4919987/">
    <skos:prefLabel xml:lang="en">Elkhart</skos:prefLabel>
    <skos:altLabel xml:lang="en">Elkhart/Indiana/United States of America</skos:altLabel>
 </edm:Place>

In defining the place MIMO decided to attribute an identifier to the finest level of granularity - the city - and not provide a URI for each broader place.

The second approach is to publish new reference resources. As an aggregator of musical instruments across six countries, MIMO was in the position of creating a domain-specific thesaurus. MIMO decided to contribute to the Linked Data effort and represented its own thesauri using the standard SKOS model. The first two define concepts for musical instruments using the MIMO instrument keywords vocabulary and the Hornbostel‐Sachs musical classification system. To provide this information, MIMO used the EDM contextual entity 'skos:Concept', which can be used to describe all entities from knowledge organisation systems like thesauri, classification schemes, including some place gazetteers or person authority files.

<skos:Concept rdf:about="http://www.mimo-db.eu/InstrumentsKeywords/2308">
   <skos:prefLabel xml:lang="en">Square pianoforte</skos:prefLabel>
</skos:Concept>
<skos:Concept rdf:about="http://www.mimo-db.eu/HornbostelAndSachs/6458">
    <skos:prefLabel xml:lang="en">314.122-4-8 True board zithers with resonator box (box zither) sounded by hammers or beaters, with keyboard</skos:prefLabel>
</skos:Concept>

MIMO also created an authority list for instrument makers. To represent them, MIMO used the class 'edm:Agent' that comprised people, either individually or in groups, who have the potential to perform intentional actions for which they can be held responsible.

<edm:Agent rdf:about="http://www.mimo-db.eu/InstrumentMaker/Person/3487">
      <skos:prefLabel>Christian Salomon Wagner</skos:prefLabel>
</edm:Agent>

For each 'edm:Agent', resource MIMO provided one label; quite often the Linked Data version provides much more information. For instance, for Antonio Stradivari the URI http://www.mimo-db.eu/InstrumentMaker/Person/3196 gives access to three different labels:

• Stradivari Antonius
• Stradivarius Antonius
• Stradivarius Antonio

In this case, MIMO decided to provide its local definition of the agent and provided its preferred label to Europeana:

<edm:Agent rdf:about="http://www.mimo-db.eu/InstrumentMaker/Person/3196"> 
  <skos:prefLabel>Antonio Stradivari</skos:prefLabel>
</edm:Agent>

A way of improving the description would be to refer to a fuller representation of the thesaurus and provide a SKOS label for each value in the EDM XML file. When the situation was too complex, with multiple labels for a contextual entity, the decision was taken to not provide any further value/label but just the raw URIs referring to it.

5) Example of a loss of information due to the implementation of EDM
MIMO's original data were rich in information related to the context of creation or modification of the music instrument. The concept of event is indeed key in the LIDO format. Since the 'edm:Event' class is not part of the first implementation of EDM, information related to events was lost during the mapping of the LIDO data to EDM. Only information related to the creation events has been kept in the description.

6) RDF/XML structure
MIMO started working with EDM when the EDM XML schema was not yet stable: namely, EDM was using the RDF model but no decision was made on the structure of the data itself.

Two solutions were possible:

• Using a typical XML structure with the different elements nested into each other. For instance using 'edm:ProvidedCHO' as a sub-element of 'ore:Aggregation'. This would give the following:

<ore:Aggregation>
   <edm:ProvidedCHO/>
</ore:Aggregation>

• Using a flat XML structure and the RDF syntax to represent links between resources. This would give the following:

<ore:Aggregation rdf:about="[ID Aggregation resource]">
<edm:ProvidedCHO rdf:about="[ID CHO]">

The latter solution was chosen. However, it requires the creation of an identifier for every resource.

When no references are available to define a resource, three options are possible:

• Generating a specific fully functional HTTP URI for the resource
• Providing a local identifier in place of an HTTP URI
• Allowing ‘blank nodes', i.e. resources without explicit identifiers

MIMO decided to use the second option, providing a local identifier for each CHO. For instance:
<edm:ProvidedCHO rdf:about="#CM:0161358"> for a cultural heritage object.

This identifier will be used by Europeana if necessary to generate a working HTTP URI such as http://europeana.eu/provider/collection/item/aLocalIdentifier.

7) Building URIs for resources
While working on a mapping to EDM, MIMO had to handle the issues directly related to the creation of URIs.
When creating the contextual entities, particular attention was paid to the structure of the links in order to make them more robust.
For instance the original link http://www.mimo-db.eu/InstrumentsKeywords/2208/Electronic has been improved to http://www.mimo-db.eu/InstrumentsKeywords/2208/ since 2208 was the reference identifier of the resource. Keeping the ‘electronic' part would generate issues if the label changed.