...
Every call to the Search API is an HTTPS request in the following URL signature:
https://api.europeana.eu/record/v2/search.json
Notice: The APIs are now being served under a unified and dedicated address https://api.europeana.eu
separate from our Portal. We have done so to better manage the traffic to the APIs besides making it more intuitive for you (our users). We will keep serving under the old https://www.europeana.eu/
while we still see traffic going via this route. We kindly advise you to change your clients to use the new API endpoint.
...
Expand | |||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||
|
Expand | ||
---|---|---|
| ||
Request:
|
Response
A response from the Search API is always formatted in JSON and will contain a number of fields that present information about the handling of the request, while the concrete information about the record is presented in the "items" field (see Metadata Sets).
...
The following kinds of errors can be returned by the Record API:
Expand | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
Expand | ||
---|---|---|
| ||
|
...
The following table shows the base and language specific search fields for the dc:creator property:
Search Field | Search Datatype | Result Field |
---|---|---|
Search Fields defined in EDM
...
The following datatypes are defined for the search fields used for querying, filtering and faceting.
Expand | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
REUSABILITY
The possible values of the reusability parameter are shown in the following Table:
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||
|
Expand | ||
---|---|---|
| ||
Request:
|
Profiles
A profile typically determines how extensive the response will be, by either dictating the metadata fields that will be present (ie. minimal, standard and rich) or appending additional data elements such as facets or breadcrumbs. Most facets can be combined with the exception of the metadata facets or combined facets such as rich. The following table lists the profiles supported by the API:
...
A collection of search queries that were applied to your call.
Expand | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
Metadata Sets
Each item in a search result is represented by a subset of the fields from the corresponding metadata record. The extent of the fields that are present is determined by the Profile chosen.
...
The following table shows the base and language-specific result fields for the dc:creator property:
Result Field | Result Datatype | Search Field |
---|---|---|
Result Fields
The table below lists all the fields that are output by the search divided per profile (metadata set).
...
Expand | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Expand | ||
---|---|---|
| ||
Request:
|
Faceting
The number of records that Europeana contains is very big and growing. Therefore we need efficient ways to allow our users to discover what they need easily. One such technique is a faceted indexing system that classifies each record along multiple dimensions. The facets, seen on the left side of the Europeana Collections Portal, can be useful for filtering search results and can also be used by API clients. If you conduct a search for the keyword "paris" and have a look at the TYPE facet, this facet would tell how many items exist within your search result grouped by TYPE (such as IMAGE, VIDEO etc.). All search fields can also be faceted on.
...
It is also possible to select which facets to retrieve beyond (or instead of) the default facet set, via the facet
parameter.
Parameter | Datatype | Description |
---|---|---|
facet | A name of an individual field or a comma separated list of fields |
The value of the parameter could be "DEFAULT" (which is a shortcut for the default facet set) or any search field. A remainder that search fields with datatype Text are indexed as tokenized terms which imply that facet values and counts will reflect such terms as opposed to the whole value (ie. phrase) like in the remaining datatypes. This is the reason why the language specific search fields were added with type string so that faceting could be done on the complete values. These are the fields actually used by the Europeana Collections Portal to display the facet values on the left side.
We have aligned the logic for faceting across all fields in the API output to be consistent. Previously, faceting on the 'default' facets (such as TYPE, or RIGHTS) would use a different logic than faceting on custom fields (such as proxy_dc_creator). The difference is that now all other values in a list of facet values are returned (multi-facet).
Expand | ||
---|---|---|
| ||
Request:
|
Expand | ||
---|---|---|
| ||
Request:
|
Multiple Individual Facets
A client can request one or more facets in a single query. This can be done by either duplicating the facet parameter or by combining all the fields needed for faceting as a comma-separated String.
Expand | ||
---|---|---|
| ||
Request:
|
Expand | ||
---|---|---|
| ||
Request:
|
Offset and limit for Facets
A client can request how many facet values to retrieve, and which should be the first one. These parameters can be used to page over all facet values without requesting too many facet values at a time. The table below explains these two parameters. The FACET_NAME constant stands for the field for which the limit applies.
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Expand | ||
---|---|---|
| ||
Request:
|
Pagination
The Search API offers two ways of paginating through the result set: basic and cursor-based pagination. The basic pagination is suitable for smaller or user-facing browsing applications which allows for the iteration over the first 1000 results using the start parameter. For larger and/or harvesting applications, the API offers the capability to use cursor-based pagination which allows for a quick iteration over the entire result set.
Pagination | Capabilities | Implementation |
---|---|---|
Basic | Allows to go to a specific offset/page (start=X). | Use the start parameter to set the search result offset, default value is 1. |
Cursor-based | Quickly iterate over the entire result set. | Set the cursor parameter to * to start cursor-based pagination at page 1. |
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query="Mona Lisa"
Query Syntax
Europeana uses the Apache Solr platform to index its data and therefore Apache Lucene Query Syntax is inherently supported by the Search API, although the Solr eDismax query parser is the one currently used by default in the search engine. Advanced users are encouraged to use Lucene and Apache SOLR guides to get the most out of the Europeana repository. For others, we supply a basic guide for querying Europeana.
...
To look for records that contain a search term in one of the data fields, provide the term as a query parameter:
Syntax: "Mona Lisa"
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query="Mona Lisa"
Note that like in many other search applications omitting the quotes will result in searching for records that contain the term Mona and the term Lisa but not necessarily both of them together or in that order. We can allow the existence of a number of other words in between by adding that number after the quotes. For example, searching by “Peter Rubens”~1 will return objects about Peter Rubens but also about Peter Paul Rubens.
...
Syntax: who:("Leonardo da Vinci")
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=who:("Leonardo da Vinci")
Boolean Search
To combine several terms in one search one can use boolean operators AND, OR, and NOT (note the case-sensitivity). Use parentheses to group logical conditions. Note that two consecutive terms without any boolean operator in between default to the AND operator.
Syntax: mona AND lisa
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=mona+AND+lisa
Boolean operators can also be combined with the search by fields. The following example searches for objects whose location is in Paris or in London:
Syntax: where:(Paris OR London)
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=where:(Paris+OR+London)
The boolean NOT operator excludes results that contain the specified word/s after it. For example, looking for objects which contain the term Lisa but do not contain the term Mona is done by the following:
Syntax: lisa NOT mona
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=lisa+NOT+mona
Wildcard search
If you are not sure of the spelling of the search terms, you can use wildcards such as * or ? These will work on all words, but not in the first letter of the word.
Wildcard - * - will find words with any number of letters in the place of the asterisk, for example ca* will find cat, cap, cane, cable, and canary.
Wildcard - ? - a single letter wildcard, for example ca?e will find cane, care, case etc.
You can use the tilde symbol - ~ - to find results with a similar spelling. For example, searching Nicolas~ will also include words Nicholaus, Nicolaas, Nikolaus, Nicola, Nicolai
Syntax: Nicolas~
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=Nicolas~
Range search
To execute range queries, the range operator should be used. This example will search for objects whose field values fall between a and z:
Syntax: [a TO z]
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=[a TO z]
As well as for textual fields it can also be used for numeric values, date ranges, or geographical areas, as shown below.
...
Syntax: pl_wgs84_pos_lat:[45 TO 47] AND pl_wgs84_pos_long:[7 TO 8]
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=pl_wgs84_pos_lat:[45 TO 47] AND pl_wgs84_pos_long:[7 TO 8]
Timestamp Search
One can also search objects by date. Currently, full-fledge date search is supported only for the fields storing the creation (timestamp_created) and update (timestamp_update) dates of the objects in our database, which are available in two formats: the UNIX epoch timestamp and the ISO 8601 formatted date. To search for objects created or updated on a given date, use the following query:
Syntax: timestamp_created:"2013-03-16T20:26:27.168Z"
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=timestamp_created:"2013-03-16T20:26:27.168Z"
Syntax: timestamp_update:"2013-03-16T20:26:27.168Z"
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=timestamp_update:"2013-03-16T20:26:27.168Z"
Searching for date range (as [date1 TO date2]):
Syntax: timestamp_created:[2013-11-01T00:00:0.000Z TO 2013-12-01T00:00:00.000Z]
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=timestamp_created:[2013-11-01T00:00:0.000Z TO 2013-12-01T00:00:00.000Z]
Syntax: timestamp_update:[2013-11-01T00:00:0.000Z TO 2013-12-01T00:00:00.000Z]
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=timestamp_update:[2013-11-01T00:00:0.000Z TO 2013-12-01T00:00:00.000Z]
Date mathematics
With date mathematics you can formulate questions such as "in the last two months" or "in the previous week". The basic operations and their symbols are addition (+), substraction (-) and rounding (/). Some examples:
...
Syntax: timestamp_created:[xxx TO NOW]
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&&query=timestamp_created:[2014-05-01T00:00:00.000Z TO NOW]
From xxx up until yesterday
Syntax: timestamp_created:[xxx TO NOW-1DAY]
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&&query=timestamp_created:[2014-05-01T00:00:00.000Z TO NOW-1DAY]
Changes in the last two months
Syntax: [NOW-2MONTH/DAY TO NOW/DAY]
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&&query=timestamp_created:[NOW-2MONTH/DAY TO NOW/DAY]
You can find more about date mathematics at Solr's API documentation
...
Syntax: query=Westminster & qf=where:London
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=Westminster&qf=where:London
Currently, we can also filter the results by distance using the function distance in the parameter qf. This example will look for objects with the words world war that are located (the object itself or the spatial topic of the resource) in a distance of 200 km to the point with latitude 47 and longitude 12.
Syntax: query=world+war & qf=distance(location,47,12,200)
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=world+war&qf=distance(location,47,12,200
We can also use more specific fields instead of location: currentLocation (with coordinates from edm:currentLocation), and coverageLocation (with coordinates from dcterms:spatial and dc:coverage). For example, qf=distance(currentLocation,47,12,200) will filter the results to those actually located within 200 km of the coordinates indicated.
...
Syntax: query=mona+lisa & sort=YEAR+asc
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=mona+lisa&sort=YEAR+asc
When we refine by distance (i.e., qf=distance(...)), we can also include distance+asc or distance+desc in the sorting parameter in order to rank the results by the distance to the coordinates.
Syntax: query=world+war & qf=distance(location,47,12,200) & sort=distance+asc
https://api.europeana.eu/record/v2/search.json?wskey=xxxx&query=world+war&qf=distance(location,47,12,200)&sort=distance+asc
Refinement and sorting parameters can be concatenated. Each such parameter and the mandatory query parameter contributes a breadcrumb object if breadcrumbs are specified in the search profile.
...
The Search API offers an auxiliary method to help translate search terms to different languages so that they can be easily used with the main Search API method. This method uses the Wikipedia API to perform the actual translation. The signature of the method is as follows:
https://europeana.eu/api/v2/translateQuery.json?wskey=YOUR_KEY&term=TERM&languageCodes=LANGUAGE_CODES
The following parameters are supported by this method:
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
Response
A response of the translation method is always formatted in JSON and will contain a number of fields that present information about the handling of the request, while the concrete information about the record is presented in the "translations" field.
Expand | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
Expand | ||
---|---|---|
| ||
Request: |
For background information on this method, see the blog post Improving search across languages
...
Basic search function following the OpenSearch specification, returning the results in XML (RSS) format. This method does not support facet search or profiles. The names of parameters are different from other API call methods, because they match the OpenSearch standard. The OpenSearch response elements can be used by search engines to augment existing XML formats with search-related metadata. The signature of the method is as follows:
https://api.europeana.eu/record/v2/opensearch.rss?searchTermsrsssearchTerms=TERMS&count=COUNT&startIndex=START
The following parameters are supported by this method:
Expand | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
For the response, see OpenSearch specification.
...
The following will be deprecated per the given date, ensure that your API clients are updated accordingly:
Date | Deprecation Details |
---|---|
January 2018 | As the API supports HTTPS now for a while, we will start to redirect all non-HTTPS traffic for the API to HTTPS. Ensure your applications follow redirects if needed or adjust the hostname to use HTTPS. |
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. The current version of the Search API is 2.9.0 (2019-07-15). To see the changes made for this version and also all previous releases, see the API changelog in the project GitHub.
...