Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
The Record API provides direct access to Europeana’s data and metadata, which is modelled using EDM. EDM is an open flexible data model used to capture the data and metadata about Cultural Heritage Objects (CHOs). The Record API is used to retrieve all of the data and metadata that relates to a single Cultural Heritage object, which will have a single Europeana ID. A Europeana ID is made up of a dataset number, and a record ID. For the object at this URL: https://www.europeana.eu/item/90402/RP_P_1984_87, the dataset ID is 90402, and the record ID is RP_P_1984_87. Both are findable by looking at the URL.
The identifier of the record which is composed of the dataset identifier plus a local identifier within the dataset in the form of "/DATASET_ID/LOCAL_ID", for more detail see Europeana ID.
FORMAT
The file extension corresponding to one of the supported output formats, namely: .json, .jsonld, .rdf. See next section on Output Formats
Additional parameters may apply to the request above such as the API key and Browser access.
The Record API supports 3 serialization formats, namely: JSON, JSON-LD and RDF/XML. The primary and default output supported by this API is JSON which also means that some fields are only available in this format. Both JSON-LD and RDF/XML are formats to represent Linked Data which used predefined transport schemas for serializing RDF data. To request a record in either of these formats, just alter the extension of the call to the desired format. The table below explains each of the formats and their respective extensions.
The XML output is primarily based on RDF/XML format for RDF serialization but following the EDM XSD schema (the same schema is also used for data ingestion to Europeana).
Error Responses
An error occurring during processing of an API method is reported by (1) a relevant HTTP status code, (2) a value of the success field and (3) a meaningful error message in the error field. The following table shows the fields appearing within an error response:
Field
Datatype
Description
Field
Datatype
Description
apikey
String
The authentication parameter sent out by the client (the wskey parameter)
success
Boolean
A boolean (true/false) flag denoting the successful execution of the call
statsDuration
Number
The time (in milliseconds) taken to serve the request
error
String
If the call was not successful, this fields will contain a detailed text message.
The following kinds of errors can be returned by the API:
HTTP Status Code
Description
HTTP Status Code
Description
200
The request was executed successfully.
401
Authentication credentials were missing or authentication failed.
404
The requested record was not found.
429
The request could be served because the application has reached its usage limit.
500
An error has occorred in the server which has not been properly handled. If you receive this error it means that something has gone really wrong, so please report them to us!
{
"apikey": "test",
"success": false,
"error": "Invalid API key"
}
Retrieving a record in the default format (JSON)
JSON is the primary output format of the Record API. It uses a Europeana-specific schema for representing EDM data.
A response in JSON will always contain several fields that present information about the handling of the request, while the concrete information about the record is presented in the "object" field.
Field
Datatype
Description
Field
Datatype
Description
apikey
String
the authentication parameter sent out by the client (the wskey parameter)
success
Boolean
a boolean (true/false) flag denoting the successful execution of the call
statsDuration
Number
the time (in milliseconds) taken to serve the request
requestNumber
Number
a positive number denoting the number of request by this API key within the last 24 hours
Object
Object
The object representing the EDM metadata record, see next section
Object
The Object gathers all the information contained within an EDM metadata record.
A collection of EDM Agent objects contextually related to the object. Find more in the EDM Definition.
aggregations
Array (Aggregation)
A collection of EDM Aggregation objects related to the object. Find more in the EDM Definition.
concepts
Array (Concept)
A collection of SKOS Concept objects contextually related to the object. Find more in the EDM Definition.
country
Array (String)
europeanaAggregation
Array (EuropeanaAggregation)
A collection of EDM Europeana Aggregation objects related to the object. Find more in the EDM Definition.
europeanaCollectionName
Array (String)
A collection of names of the datasets the object belongs to.
europeanaCompleteness
Number
A number between 0 and 10 representing the metadata quality of the object.
language
Array (String)
A singleton collection with the language of the object.
licenses
Array (License)
A collection of CC Licenses. Find more in the EDM Definition.
optOut
Boolean
Flag indicating whether the provider allowed retrieval of a thumbnail of the record
places
Array (Place)
A collection of EDM Place objects contextually related to the object. Find more in the EDM Definition.
provider
Array (String)
A singleton collection with the name of the organization that delivered this object to Europeana.
providedCHOs
Array (ProvidedCHO)
A collection of Provided Cultural Heritage Objects related to the record. Find more in the EDM Definition.
proxies
Array (Proxy)
A collection of proxy objects for Provided Cultural Heritage Objects. Find more in the EDM Definition.
services
Array (Service)
A collection of service objects required to consume a Web Resource according to a specific protocol and profile.
timespans
Array (TimeSpan)
A collection of EDM TimeSpan objects contextually related to the object. Find more in the EDM iDefinition.
timestamp_created_epoch
Number
Unix time of the date when the object was created.
timestamp_update_epoch
Number
Unix time of the date when the object was last updated.
timestamp_created
String
ISO 8601 format of the date when the object was created.
timestamp_update
String
ISO 8601 format of the date when the object was last updated.
title
Array (String)
A collection with the main and alternative titles of the object.
type
String
The type of the object (see the TYPE facet)
year
Array (String)
JSON Structures and Fields for EDM
The JSON structures and fields defined in this section all represent classes and properties defined in EDM. More information can be found on the Europeana Data Model documentation page
The JSON output of this API uses the following datatypes:
Datatype
Description
Datatype
Description
Boolean
true or false
Number
integer or double precision floating-point number
String
double-quoted Unicode, with backslash escaping
Array
an ordered sequence of values, comma-separated and enclosed in square brackets; the values do not need to be of the same type
Array([Datatype])
an ordered sequence values of Datatype (e.g. String or Object), comma-separated and enclosed in square brackets
Object
an unordered collection of key:value pairs with the ':' character separating the key and the value, comma-separated and enclosed in curly braces; the keys must be strings and should be distinct from each other
LangMap
A special datatype to provide values in various languages. It is an associative array where the keys are ISO language codes or "def" (where the language is not given), and the value is an array of strings. For example: "dcTitle": {"por": ["Paris"]}. Here the datatype of dcTitle is a LanguageMap: the language code is "por" (stands for Portuguese), and the value is a list with only one element: "Paris". For those familiar with Java notations: is it the JSON equivalent of Map<String,List<String>>
null
empty value
Retrieving a Record in the JSON-LD format
JSON-LD stands for JSON for Linking Data and is one of the Linked Data formats that the Record API supports. The basic structure of the JSON-LD response is similar to the default JSON format of the Record API:
JSON-LD makes use of Internationalized Resource Identifiers, IRIs as property names. This ensures that each statement of a record matches a standard vocabulary. In Europeana's implementation the properties are qualified names (in the format of "namespace_prefix:property_name" such as "dc:creator") for the sake of brevity. In the normal JSON response we use non-standard camel case ("dcCreator") property names. In the JSON Section you can find the connections between our camelCase property names and the JSON-LD and RDF qualified names.
JSON-LD has a @context part, which links object properties in a JSON document to concepts in an ontology. In our JSON-LD this lists the used namespaces and their prefixes.
JSON-LD makes a distinction between values that are string literals from values that are other resources.
This is how JSON-LD structures a value that has a resource as its datatype:
And this is how JSON-LD structures a value that has a string literal as its datatype:
{
"dc:creator": "Europeana",
...
}
Retrieving a Record in the RDF/XML format
The XML output is primarily based on RDF/XML format for RDF serialization but following the EDM XSD schema (the same schema is also used for data ingestion to Europeana).
The structure of an RDF/XML document formated using the EDM XSD schema is as follows:
The root element of the XML document is "rdf:RDF". This element will have declared all the namespaces required for the qualified names of all classes and properties being using within the document. A list of all supported namespaces can be view in our EDM introduction.
Within the root element, all instances of EDM classes are declared using the qualified name of the classes as the label for the XML element. An "rdf:about" attribute is present indicating the IRI of that instance.
Datatypes for request parameters
The following datatypes are defined for the request parameters used in this method.
Datatype
Description
Datatype
Description
String
Values are preserved as they are present in the data.
Deprecation Information
The following will be deprecated per the given date, ensure that your API clients are updated accordingly:
Date
Deprecation Details
Date
Deprecation Details
January 2018
As the API supports SSL now for a while, we will start to redirect all non-SSL traffic for the API to SSL. Ensure your applications follow redirects if needed or adjust the hostname to use SSL.
Roadmap and Changelog
We deploy new versions of the portal and API quite regularly, but not all new versions result in changes in the interface. To see the changes made for this version and also all previous releases, see the API changelog in the project GitHub.