We provide a full list of Europeana's data providers. The name of an institution appears on this list only once there is some data ingested. Institutions which have not yet finished submitting data do not appear on this list.

The name of the current aggregator should still be entered in the data. There is a project strategy in place to enable these changes to be monitored and adjusted accordingly.

If a second click is required in order to alert a user to the need for a plug-in, that is acceptable.

Europeana can be searched in the languages of the ingested metadata. Metadata is ingested and indexed in the language in which it is provided. So for example, if a title is provided in Greek, it will be indexed in Greek and a query in Greek will find that term in Greek. As part of the enrichment process, place names, subject terms and person names are matched with external resources that will provide the values in as many languages as are available.

Providers may send metadata in more than one language if they wish. Therefore, the number of languages that can be used to search Europeana is the number of languages represented in the ingested metadata. This is currently 34 languages.

Europeana counts the number of records. So if there are 300 pages to which you can navigate on the local site but only one record in Europeana it will count as one object.

The granularity should be a) at a level that is meaningful for a user and b) it should have a metadata record that relates to that level. For example, there is no point in providing a link to a page in the middle of a book if there is no meaningful metadata explaining the context and giving some information about that page.

Europeana is focusing on giving access to the digital version of physical objects held in museums and elsewhere rather than digital information about these objects. Such descriptions are therefore not considered as digital objects in the context of Europeana at the moment and this includes digitised catalogue cards as well.

We evaluate new sources of data to best fill in gaps in material and provide a unique value to the Europeana data services. At the moment we are looking for content that falls within the following list. Of course, this list is not comprehensive.

All formats

• Romany material
• 1989 and subsequent event material

Video/Film

• Silent film
• 1914-1918
• News and documentary
• Interviews
• Languages other than English, French, German and Spanish

Sound

• Music (jazz, contemporary and classical)
• Wildlife sounds
• Ethnographical recordings
• Languages other than English, French and German

Text

• Early history to 14th century
• Contemporary content
• 1914-1918
• Newspapers
• Music scores and lyrics
• Performing arts and film texts
• Political documents
• Archaeology
• Medical pre-1950s
• Biology pre-1950s
• Economy pre-1950s

ESE does not easily allow the expression of the semantics given in these examples in the metadata. EDM should allow this kind of connection to be made, and the first implementation of this is currently under way.

Until EDM is fully deployed this kind of historical information could be put into a 'dc:description' element. Alternatively (or indeed, additionally), a 'dc:relation' element could be used to provide the URL of the related object from the described object. This would create the link but not state the nature of the connection.

ESE v3.4 is the metadata format currently implemented in Europeana. The transition from ESE to EDM will take place very gradually over a period of several months as part of the incremental implementation of the Danube release. Europeana will be migrating the current ESE data in the portal to EDM and attempting to enrich it.

There is currently no tool available within Europeana for the selection of licences or rights statements. However, there is a Public Domain Calculator which takes you through the process of deciding if an object is in the Public Domain. It can be found at http://www.outofcopyright.eu/.

ESE is a subset of EDM and several of its elements are critical to the functioning of the Europeana portal. These quality improvements will have a positive effect on future EDM implementation.

Existing mandatory elements from ESE v3.3 are:

• 'europeana:isShownAt' or 'europeana:isShownBy'
• 'europeana:provider'
• 'europeana:type'

The following new ones have been added in ESEv3.4.

• 'europeana:rights'
• 'europeana:dataProvider'
• 'dc:language' - is mandatory for objects with type TEXT, strongly recommended for other types where appropriate
• 'dc:title' and 'dc:descriptio'n – one of these two must be provided
• 'dc:subject', 'dc:type', 'dc:coverage' and 'dcterms:spatial' – one of these four must be provided

Some providers have 3D objects to supply to Europeana and need to be able to indicate this in the metadata. The value '3D' can now be entered in the 'europeana:type' element (also 'edm:type'). The portal will use this value to create a new facet in the search results. In addition, if the value '3D-PDF' is entered in the 'dc:format' element, a PDF icon will be displayed alongside the object in the search result so users will know what application is needed to view the object. (See the metadata documentation for further details.)

The metadata element 'europeana:UGC' (also 'edm:UGC') has been introduced to allow providers to indicate that content has been sourced from the public. Digitised and born-digital resources contributed by the general public are collected by Europeana through crowd-sourcing initiatives and projects. Any objects that fit this definition should have this element provided with the value 'TRUE' in uppercase so it can be identified in the portal. (See the metadata documentation for further details.)

If this value is present in the metadata then an icon representing user-generated content and a 'Content created by user' label will be displayed in search results. It will also be used as a filter to allow portal users to include or exclude such content from a search.

The regular import pattern needs to be agreed between each aggregator and Europeana: it will depend on the frequency, type (addition/deletion/change) and volumes of updates occurring on the aggregator's side. As part of its planning process, each aggregator should send Europeana an estimation of those update aspects. Europeana will evaluate them against machine and human resources capacity, then prioritise and integrate them into the overall Europeana ingestion planning.

At the moment, all thumbnails in the portal are images and they do not trigger any functionality. It is up to the provider to choose the image they provide - a book or record cover is suitable but an image from elsewhere in the object can be chosen if it is thought to be more interesting or representative of the content of the object.

If no image can be provided to use as a thumbnail then a default image will be used based on the type of object (image, sound, text or video). These default images do not give a very good user experience, however, especially when several show on the results screen. If at all possible you should provide a more appealing image.

Details of the thumbnails can be found in the Europeana Portal Image Policy document

In order to offer a good user experience, Europeana does not accept thumbnail images that contain a visible digital watermark.

Europeana uses a custom system of identifiers for ingested data. Note that Europeana does not ingest publications, only the metadata, so the identifier is for the record, not the publication.

ESE is a flat data model that provides the lowest common denominator for ensuring interoperability between metadata standards. The disadvantage of this is that richness is lost in the process. EDM is a data model that will improve the way metadata can be provided and used in Europeana. It has several advantages over ESE:

• it allows a greater degree of granularity in describing objects,  distinguishing between:
  • the original object and its digital representation
  • the original object and the record describing that object
  • objects that are composed of other objects
• it supports the aggregation of representations of the same object from different sources with different and possibly contradictory statements in the metadata

To exploit the richness of data from many cultural heritage domains, EDM adopts a cross-domain semantic web-based framework that will also allow enrichment of data from third party sources through linking.

The objective is for providers to supply their metadata in their richest XML format together with an xslt mapping from that format to EDM. The Europeana Operations team will carry out the transformation of the data. In addition there is currently a prototyping exercise being carried out with several projects to accept EDM directly.

The original metadata should be delivered via OAI-PMH. The mapping file can be emailed. A more streamlined process is under development.

At the moment, we are using an XML schema to represent EDM data.

Updates can be done by modifying the mapping, or by a redelivery of the original data.

Europeana attempts to enrich data by cleaning it and adding standard multilingual terms and references to answer 'who', 'what', 'where' and 'when' questions. This is carried out by applying terms from thesauri or controlled vocabularies using the Annocultur tool.  The added terms and values are not copied back into the provider metadata but stored alongside it and displayed under separate 'Autogenerated tags'  in the portal. 

Person names are matched to DBpedia entries to give a unique identifier for the name.  This links to additional information about the person, and enables the display of multilingual versions of the name in the portal.

Concepts are matched to the terms in the Gemet thesarus which provides a unique reference for the concept.  It also enables the display of the term in many languages and a display of the references and labels of broader terms.

Places are matched to place names in GeoNames. This gives a unique reference for the place name, enables the display of multilingual versions of the names, the display of geographic co-ordinates and broader geographic areas associated with the place.

Time periods are enriched from a vocabulary developed using the Annocultur tool which can now be found at Semium.org.  This establishes a unique reference for the time period with start and end dates and can also connect to the name of a historical period. 

Europeana provides access to cultural heritage from different countries and in different languages. The language a user is searching in is the language in which documents are retrieved. Providing your metadata in more than one language ensures that your objects are visible across language borders, which will result in more traffic. 

So far, Europeana can not adequately display this information. We are in a transitional phase moving from ESE to the implementation of the Europeana Data Model (EDM), which is geared towards a rich semantic and multilingual representation of metadata. We are expecting to integrate multilingual functionality and multilingual display in the near future. It is important therefore to label multilingual variants of your metadata so your objects can be retrieved across languages and gain more visibility once EDM is fully functional.

We encourage you to include the XML attribute 'xml:lang' in all metadata elements which you can provide in several languages. Here is an example:

<dc:description xml:lang="fr">végétation des montagnes de France</dc:description>

This allows us to use this information in multilingual functionalities. So far, Europeana can not adequately display this information but we are expecting to integrate this functionality in the near future. 

If metadata records for the same object exist in several languages they should not be submitted as separate records. This would result in duplicate objects in the portal with no way to cross-link them. The metadata should be submitted as one record with duplicate elements for each value occurring in multiple language versions (ideally also with an 'xml:lang' tag). This ensures that multilingual values are identified and ready for display in the portal. 

If 'xml:lang' tags have been used, then future functionality could display these different versions by labelling the different languages.  For example:

Subject: [es] baño termal, cura; recuperación, viaje;  [en] cure, recovery, travel, [fr] cure, rétablissement, station thermale

Note that the 'Title' element is a special case and is explained in a separate FAQ. 

This is a special case because at the moment only one instance of 'dc:title' can be displayed in the portal. However, we would still suggest that you provide translations in repeated elements using the 'xml:lang' tag, as this functionality is expected to be implemented in future. For now, to ensure translated titles are displayed please put the alternative versions in the 'dcterms:alternative' element as well.

For EDM data, it is possible to submit several 'dc:title' properties with 'xml:lang' tags  which would indicate that an object has a title in several languages.

If already-submitted records have been enriched with values in multiple languages after ingestion, then the data sets can be resubmitted to replace the earlier monolingual versions. 

Once EDM is implemented, providers can submit multilingual versions of their vocabularies. These will be ingested together with their data to support multilingual functionality and data enrichment. Examples of such vocabularies are those created by MIMO, further explained in their EDM case study. The instrument keywords are listed in several languages together with broader and related terms.

We also encourage you to submit relevant multilingual vocabularies to the Europeana Tech mailing list so it can be discussed with the community.