Provider and Aggregator names
Is there a publicly available list of provider names?
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.
What does Europeana do if the aggregator is only temporary (e.g. for the duration of a project)?
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.
Europeana stipulates there should be only one 'click' between the portal and the object. If content providers use an unusual image format which requires a plug-in, with an intermediate page to give users this information, this adds an extra 'click"'between the portal and the content. Is this acceptable?
If a second click is required in order to alert a user to the need for a plug-in, that is acceptable.
In how many languages can data providers search Europeana?
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.
How does Europeana count the number of objects? For example, does a digitised book of 300 pages count as one object or 300?
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.
What is the best level of granularity for objects to be submitted to Europeana?
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.
What is a 'digital object'? For example, museum descriptions are so rich they could be regarded as digital objects in their own right even though they have no digital 'image' to accompany the description. They are essentially very full metadata records. What is the policy about including such objects?
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.
What kind of content are you looking for?
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.
- Romany material
- 1989 and subsequent event material
- Silent film
- News and documentary
- Languages other than English, French, German and Spanish
- Music (jazz, contemporary and classical)
- Wildlife sounds
- Ethnographical recordings
- Languages other than English, French and German
- Early history to 14th century
- Contemporary content
- Music scores and lyrics
- Performing arts and film texts
- Political documents
- Medical pre-1950s
- Biology pre-1950s
- Economy pre-1950s
Europeana Semantic Elements (ESE)
How can content providers use ESE to give an indication of the broader historical context of an object? For example: a) to indicate that a particular instrument represented the shift towards the use of high technology in chemistry or b) that a particular essay by James Joule was fundamental to the work of Helmholtz in developing his concept of energy.
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.
Should data still be provided to Europeana in ESE now that EDM has been published?
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.
The 'Rights Guidelines' say that Europeana will supply some tools to support selection of licences, rights statements and public domain values for the 'europeana:rights' element. Where can these tools be found?
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/.
Why have you released ESE v3.4 when you plan to implement EDM in future?
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.
Which elements are mandatory in ESE v3.4?
Existing mandatory elements from ESE v3.3 are:
- 'europeana:isShownAt' or 'europeana:isShownBy'
The following new ones have been added in ESEv3.4.
- '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
Why have you added a new Europeana type of '3D'?
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.)
As a data provider, how can I indicate that my content has been generated by users, and how can other users find it?
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.
How frequently does Europeana harvest data? Data providers may receive a few hundred new records a day.
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.
What kind of thumbnails should text, video and audio have? Should it be a scan of the cover of the publication (book cover, record cover etc.)? Or should audio and video have a preview that would play when the mouse pointer is hovered over it?
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.
What should we do if we do not have an image for the object e.g. because it is sound?
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.
What size and format should thumbnails be?
Details of the thumbnails can be found in the Europeana Portal Image Policy document
Is it acceptable to provide a thumbnail image that has a digital watermark on it?
In order to offer a good user experience, Europeana does not accept thumbnail images that contain a visible digital watermark.
Is Europeana coordinating a system of identifiers for submitted publications that could be used in place of, for example, Digital Object Identifiers (DOI)? If not, is such a system being planned for the future?
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.
Europeana Data Model (EDM)
What is EDM and why are you changing to it?
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.
How should we deliver our metadata to Europeana?
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.
Technically, how is data transferred to Europeana?
The original metadata should be delivered via OAI-PMH. The mapping file can be emailed. A more streamlined process is under development.
Is data in Europeana expressed in XML or RDF?
At the moment, we are using an XML schema to represent EDM data.
How can a provider update their data?
Updates can be done by modifying the mapping, or by a redelivery of the original data.
How does Europeana enrich metadata?
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.
Why is multilingual metadata important?
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.
How does Europeana handle metadata provided in different languages?
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.
How should metadata in different languages be labelled?
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.
How should multiple records in different languages for the same object be submitted?
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.
How does Europeana handle titles in different languages?
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.
My objects are already ingested in Europeana and I have now translated all my metadata into another language. How do I add these additional translations?
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.
We have multilingual vocabularies, how can we submit them to Europeana and how are they used?
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.