Changelog API version 1.5

Changes and additions in API (ver. 1.5) released in KulturNav main version (date):

1.12.7 (planned for 2024-03-04)


  • An issue with parsing long property names affecting API search has been resolved. (#2224)

New properties:

  • New property, concept.scientificName, containing the scientific name for a taxon:
    • (TEXT) - the scientific name (language code "la")
    • (TEXT) - code/name of author
    • (DATE) - year

Modified properties:

  • concept.dialectalDesignation: The dialectal expression is now stored in the new property (TEXT)
    with language according to ISO 639. Data has been migrated to the new property. When retrieving data from the property, replace the dialectal expression from concept.dialectalDesignation.designation (STRING) with (TEXT).
  • concept.taxon.scientificName (STRING) has been moved to the new property concept.scientificName and is now stored in (TEXT) with language according to ISO 639. Data has been migrated to the new property with language "la".
  • (STRING) has been moved to the new property (TEXT). Data has been migrated.
  • (STRING) has been moved to the new property (DATE/year). Data has been migrated.
  • (ENTITY_REFERENCE) has been removed from the schema. The property was not in use.

1.12.5 (2023-09-18)


  • An issue with RDF Export has been resolved. (#2222)

1.12.3 (2023-03-20)

  • api/core. In some cases, properties were duplicated in returned data, and this has now been fixed. (#2170)

1.12.2 (2023-03-20)

  • api/core. The property externalEntry is now returned correctly. (#2156)

1.12.1 (2023-02-06)

  • api. The language element current language is now also generated on the displayValue property. For example, the element provides a preview of the for a referenced entity (ENTITY_REFERENCE) and now has the same language handling as and caption. (#2060)
  • api/core: Properties that dynamically aggregate information are now delivered correctly through api/core. Note that it may take a significant amount of time to gather and return this data. Dynamic retrieval of related information is indicated by the text lookup for related entities in the property documentation, for example, on a person. We recommend fetching fewer objects per "page" (preferably 20 entries) for smoother handling of dynamic retrievals. If the displayValues parameter is omitted (which makes an extra lookup for names), the number can be increased slightly. (#2123)
  • api/core. Images uploaded, linked to KulturNav, or retrieved for the entity via DigitaltMuseum are now available through api/core via the superconcept.imageEntities property. (#2145, 2149, 2150)
  • api/core. The entity.list property is now returned in the same way when called through /{uuid} and /id:{uuid}. (#2113)
  • api/core. The synthetic property related has now been expanded under the synonyms element so that all relevant names and designations are included, and they are delivered with the correct current language (*). (#2151)
  • api/core. The property externalEntry is now returned complete with content. (#2113)

1.11.4 (2022-11-24, 12-07, 2023-01-12)

  • api/autocomplete now has the correct CORS header. (#2138)

1.11.3 (2022-10-03, 11-09)

  • New API method: api/autocomplete that facilitates lookups for entries when choosing a post.
  • api/core. The entity.list property can now be added among properties and returned. (#2088)
  • api/core. An issue with property identifiers ("property uuid") has been fixed. Previously, properties were assigned new identifiers instead of presenting the ones that were stored. (#2103)
  • api/core. Inline properties are now correctly displayed in returned data regardless of the status of the inline property. (#2098)
  • api/core. We have optimized api/core so that it is now much faster to retrieve complex entities (#2109) - from 1.11.2a
  • api/autocomplete. We have improved it so that the selection includes a filter for entities in a specified dataset or folder. Search is also handled better and is now tokenized. Hits are returned in two lists: fullMatch (complete return) and startMatch (where the names of returned entities begin with the same letter as the search string). - from 1.11.2a

1.11.1 (2022-01-24, 2022-02-21)

  • Language tag for all languages. API handling no longer overwrites an explicitly specified and stored synthetically added All languages ( * ). (#2070)
  • api/core now correctly returns JSON even if there are structural problems in entries (e.g., is missing). (#2069)
  • RDF mapping has been supplemented and made more universal.
  • You can now fetch a GeoJSON representation with properties in the specified language (accept-language or lang={lang} in URL)

1.10.5 (2021-12-14)

  • The issue with using an entity's UUID as a search string in api/core for certain classes has been fixed. (#2051)
  • The language element All languages (*) no longer displays a language tag (such as [EN]) on TEXT values - the value element - replaced from a language other than the one specified in an API return. (#2057)

1.10.3 (2021-09-14)

  • Simplified language handling in returned API data. An element for all languages in the form of an asterisk ("*") is always added to a value in an element of type TEXT - "value": {"*": "Building", "no": "Bygning", "nn": "Bygning", "sv": "Byggnad"}. The value is retrieved from the language perceived as primary for the property through: 1) ?lang=xx, 2) header Accept-Language: xx or 3) default language according to configuration
  • API properties compoundName and nativeCompoundName now use an indexing in the form of tokenized text without stemming and stopword filtering
  • New API - /api/core/ developed to minimize the size of returned data, optimize response times, and increase flexibility in the use of machine data. A request to /api/core/ returns a minimal amount of data that can then be expanded as needed, property by property. Read more about api/core.
    /api/core/{uuid|property:value,...}[/{offset}[/{number of records}]][?properties={property,...}[&displayValue={true|false}]][&labels={true|false}][&lang={no|nn|sv|en|fi|et}]

1.10.1 (2021-02-08)

  • Export of RDF/XML had issues with timeouts in connection with large exports. We have addressed this by adding paging to the export syntax. Learn more about the change in export. Updated 2021-03-02(b)
  • RDF data can now be exported in JSON-LD format (Updated 2021-03-02b):


1.9.12 (2020-12-16)

  • API. Language control in API calls from Accept-Language: nb and ?lang=nb is now handled correctly. (#1954)

1.9.9 (2020-06-18)

  • Support for Cross-Origin Resource Sharing (CORS) on machine-readable resources.
  • Changed JSON structure to refer to an inline element in an entity. A full path for a reference to an entity and event is in the element: extendedReferenceValue where the second value after the slash points to an inline element in an entity. The value then contains only the entity reference.


extendedReferenceValue: {uuid}/{uuid}  
  • Retrieve GeoJSON from a single entry (with geodata) by appending .geojson to the URL



1.9.8 (2020-03-10, 03-23, 04-02, 04-16)

  • New synthetic properties: entity.longitude and entity.latitude showing an entity's location in WGS 84 created from other, more class-specific, properties.
  • New API method.

The method returns data in GeoJSON format from a dataset:

/api/geoJSON/< dataset-uuid >  


/< dataset-uuid >.geojson  

1.9.7 (2019-11-08 + 11-15 + 12-04)

  • Support for DCAT-AP (Data Catalogue Vocabulary - Application Profile for data portals in Europe, ver 1) for the datasets that respective dataset managers choose to publish under the profile. The entire KulturNav is seen as a DCAT catalog, which in turn consists of catalogs - one catalog per class (e.g., a catalog for /dcat/person and another for /dcat/concept). In each catalog, the datasets marked for publication by the respective dataset manager are published. Endpoint:
  • A dataset can now be more easily fetched as a whole with its entries via standardized methods.
  • Improved mapping of collection terms. They are seen as skos:collection.
  • New parameter in API search: idonly that reduces the response to an ID list - example:



Version 1.9.6 (2019-08-14+19+29)

  • The entityTypeName element is now also shown in results from /api/search/
  • New indexing and changed handling of stemming in search have improved API syntax in search. See
  • Fixed an issue with API search when Accept-Language uses a complex language code in the header, e.g., en-US. (#1702)

Version 1.9.5 (2019-05-22+28)

  • We have added a new property in an API response to an entry: entityTypeName showing the current entity type in the various site languages.

Version 1.8.8 (2018-10-19)

  • We have simplified for machines and developers to access machine data. Add the extension:
    .json to get the entry in KulturNav's internal API format
    .json-ld to get the entry as JSON-LD
    .rdf to get the entry as RDF/XML

Version (2018-10-04)

  • Performance improvement for certain API responses by removing the dataset.size element from folders (List). (#1502)

Version (2018-09-28)

  • We have corrected errors in the API response for external data and added LODometer data to the additionalData element. (#1496)

Version 1.8.1 (2018-01-12)

  • Field headers/labels are now sent as part of the API response.
  • The schema is now supplemented with field headers/labels and expanded with content even for event/inline fields.
  • Write API. A first version of an API for writing data to KulturNav is now in beta. Express interest in testing by sending an email to

Version 1.7.4 (2017-06-01)

  • /api/summary/ now includes the entity's status and the entity's belonging to a dataset.
  • Image links retrieved from DigitaltMuseum have been separated in the API return from images uploaded or linked to the entry. Images retrieved from DigitaltMuseum's API are now returned under the superconcept.additionalData element.

Version 1.6.11 (2017-03-31)

  • New API method: api/summary/ that gives you a lightweight overview of key data about an entry, a dataset, or a search result. Read more under API

Version 1.6.9 (2017-03-17)

  • dataset.primaryLanguage is now on entries in datasets that contain the property.
  • entity.begin and entity.end are now included in several classes, e.g., Design.

Version 1.6.4 (2017-01-22)

New API methods

  • api/revisions/{uuid}. Shows a list of the entry's revision history with the latest entry first in the list.

  • Retrieve a revision via api:


Version 1.6.1 (2017-01-11)

New properties in API

  • entity.begin. Specifies the time when the object was created/born, for example, when a person is born or a ship is launched.
  • entity.end. Specifies the time when the object ceased to exist/died, for example, when a person dies or a ship is scrapped.
  • entityTypeHierarchy. Specifies in which class structure the current object is located as a list of classes from the most overarching to the most detailed.

Version 1.5.0 (2016-10-10)

Version 1.5 of the API involves extensive changes to KulturNav's development interface, API. The changes bring significant improvements with increased simplicity to access information and faster response times, affecting both API methods and the data returned. The changes are thoroughly described here, commenting on backward compatibility with previous versions of the API. Below is a brief overview:

  • Simplified syntax for field names in search parameters. The value suffix has been removed.
  • Simplified language handling in search. Language is specified in a separate parameter or in the header for http GET
  • Compact JSON structure results in fewer API calls. Information about events is now stored inline directly in the main entity
  • Extended search syntax:
    - Or search in a property with | (OR), for example: entityType:[Agent|NamedObject]
    - Unified search phrases using quotation marks: text:"title duke of"
  • Changed function for search with entity.list (folders). You search in the folder's total "expanded" content, i.e., both in individual entries and the entries in the datasets in the folder.
  • New method: /api/version that returns the default version number of the API.