Schema.org Application Profile for NDE (SCHEMA-AP-NDE)

1. Introduction

1.1. Goal

This document prescribes the SCHEMA-AP-NDE generic data model to be used when publishing linked data in the Dutch heritage network (NDE). The model consists of a minimal set of classes and properties. It is based on:

• the current state of datasets in the heritage network, as observed in the Dataset Knowledge Graph, particularly its property partitions analysis;

• the needs of service platform builders for understanding, processing and presenting data, especially across datasets and publishers.

By adhering to this model, dataset publishers ensure that their data can be:

1. discovered, understood and combined with other datasets in the network;

2. used in service platforms to build applications and visualisations.

1.2. Scope

The document is restricted in four ways:

1. it applies to the Dutch heritage network (NDE), which implements the National Digital Heritage Strategy and Digital Reference Heritage Architecture;

2. it applies to the way published data is expressed, not how it is stored or managed internally;

3. it prescribes a generic data model and leaves the use of domain data models up to dataset publishers;

4. it bears upon datasets, not their descriptions; for the latter see [NDE-DATASETS].

1.3. Examples

RDF examples in this document are in the RECOMMENDED JSON-LD § 3.5 Serialization format.

2. Definitions

Data model

Set of classes and their properties that defines how data is expressed.

Generic data model

A simple, shared data model; the scope of this document. Can be used alongside domain data models.

Domain data model

A domain-specific data model, such as CIDOC-CRM, Linked Art, RiC-O or RDA. Can be used alongside a generic data model. Adds precision at the cost of complexity. Out of this document’s scope.

Metadata record

An RDF resource that expresses an entity in the heritage network using one of the top-level classes in the § 4 Data model: CreativeWork (for heritage objects), Person, Organization and Place.

Heritage object

Physical or digital object that is described by a metadata record. Corresponds to [DERA]’s cultuurhistorisch object.

Term

A word, name, acronym, phrase or other symbol with a formal definition, preferably available in the Network of Terms. Corresponds to [DERA]’s term; expressed in this application profile as a DefinedTerm.

3. General considerations

3.1. Generic and domain data models

The purpose of generic data models is to integrate data in the heritage network and make it more visible. Domain models are usually more richly populated and provide consumers with more possibilities for further processing, for example in service platforms.

This document is limited to a set of classes and properties that together form the generic data model. For most datasets, the generic data model expresses only a subset of data properties that are available. This document’s purpose, therefore, is not a complete and correct expression of the source data, but an easily understandable and usable one.

If done well, the generic data invites consumers to explore the data in more depth using the domain data models. So to facilitate further exploration, publishers MAY use domain data models of their choosing alongside the generic data model. Examples are:

• CIDOC-CRM and its derivative Linked Art for museum collections and catalogs;

• RiC-O for archives;

• PiCo for biographical data;

• RDA for libraries.

3.2. Vocabulary

The generic data model presented in this document is designed as a [SCHEMA-ORG] application profile. Schema.org is a widely adopted cross-domain metadata standard. It is, therefore, well-suited for the heritage network, which spans datasets from the library, archive, museum and other domains.

The Schema.org website considers “both ‘https://schema.org’ and 'http://schema.org' (…) fine”.

However, to avoid mixed namespaces and enable future-proof interoperability across serialization formats, publishers:

• MUST use the https://schema.org/ (HTTPS) namespace for newly published datasets;

• SHOULD migrate existing datasets to https://schema.org/ (HTTPS) as well.

Both https://schema.org/ and http://schema.org/ MUST be accepted by consumers.

Note: Schema.org’s default JSON-LD context resolves terms to http://schema.org/ IRIs, even when using "@context": "https://schema.org". See § 6 Formal definition for how to override this when processing JSON-LD.

3.3. Language

For all name and description values, their language MUST be specified. The language MUST be expressed as a well-formed language tag according to [BCP47], such as ‘nl’ (language only) or ‘nl-NL’ (including region).

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/1",  "@type": "CreativeWork",  "name": [    {      "@language": "nl",      "@value": "De Sterrennacht"    },    {      "@language": "en",      "@value": "The Starry Night"    }  ]}

Even if only one language is available, the language MUST be specified.

{  "@context": "https://schema.org",  "name": {    "@language": "nl",    "@value": "De Sterrennacht"  }}

If the language of value is unknown, for example because it’s not recorded in the source data, the most likely language SHOULD be assigned: if a dataset is known to be predominantly Dutch, its labels are most likely in Dutch and SHOULD be tagged nl.

Only when the language genuinely cannot be determined, the [BCP47] ‘undetermined’ subtag und MUST be used. Because und is itself a well-formed language tag, the value stays a language-tagged string and remains valid, so a record whose only name has an unknown language can still be published.

{  "@context": "https://schema.org",  "name": {    "@language": "und",    "@value": "山水"  }}

Each language MUST occur only once, so only a single value per language is allowed.

{  "@context": "https://schema.org",  "name": [    {      "@language": "en",      "@value": "The Starry Night"    },    {      "@language": "en",      "@value": "Repeated English name while only one is allowed"    }  ]}

3.4. Reference terms

When referencing terms, each term MUST be typed as a DefinedTerm to indicate to consumers that a formal definition is being referenced. Each DefinedTerm MUST have a language-tagged human-readable name property. If known, the term’s public URI from a controlled vocabulary MUST be provided via sameAs.

The DefinedTerm is a local node, scoped to the publishing dataset: it carries the dataset’s own name for the term (which MAY differ from the label used by the external source) and makes no claims about the resource it points at. The sameAs URI is the canonical identifier and keeps its own typing in its source vocabulary (e.g. skos:Concept in a thesaurus).

To recognise that two DefinedTerms denote the same concept, consumers MUST compare their sameAs URIs rather than the nodes’ own blank-node or URI identities, which are local to each publishing dataset and therefore not shared across datasets.

Term URIs MUST be dereferenceable, which means that consumers can retrieve the term’s definition either:

• through the Network of Terms;

• by directly resolving its URI.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "genre": {    "@type": "DefinedTerm",    "name": {      "@language": "en",      "@value": "Post-Impressionist"    },    "sameAs": "http://vocab.getty.edu/aat/300021508"  }}

When no public term is known, sameAs MAY be omitted:

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "genre": {    "@type": "DefinedTerm",    "name": {      "@language": "en",      "@value": "Post-Impressionist"    }  }}

A DefinedTerm MAY also carry its own @id, making the local term node dereferenceable within the dataset. The @id identifies this dataset’s term node, while sameAs is the canonical external identifier that consumers compare on; the two can coexist.

{  "@context": "https://schema.org",  "@id": "https://example.com/dataset1/resource1",  "@type": "CreativeWork",  "genre": {    "@id": "https://example.com/dataset1/terms/post-impressionism",    "@type": "DefinedTerm",    "name": {      "@language": "en",      "@value": "Post-Impressionist"    },    "sameAs": "http://vocab.getty.edu/aat/300021508"  }}

A DefinedTerm value MUST additionally be typed with a type from the property’s Schema.org range whenever that range does not already include DefinedTerm, so that the data also validates against Schema.org’s own type expectations. For example, genre and about accept a DefinedTerm directly, so no co-type is needed, whereas material, creator and contentLocation do not, so the DefinedTerm is co-typed with a type that is in range. Each property’s required co-type is shown in its example throughout the document.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "material": [    {      "@type": ["DefinedTerm", "URL"],      "name": {        "@language": "en",        "@value": "oil paint (paint)"      },      "sameAs": "http://vocab.getty.edu/aat/300015050"    },    {      "@type": ["DefinedTerm", "URL"],      "name": {        "@language": "en",        "@value": "canvas (textile material)"      },      "sameAs": "http://vocab.getty.edu/aat/300014078"    }  ]}

3.5. Serialization

Servers MUST provide at least one RDF serialization format. Supporting multiple formats using content negotiation is RECOMMENDED.

The following formats are RECOMMENDED:

• [JSON-LD] when serving an individual resource at its URI, because of its accessibility to web platform builders;

• [N-QUADS] for RDF dumps containing multiple resources, because of its efficiency.

3.6. Publication method

3.6.1. Publication levels

In the heritage network, SCHEMA-AP-NDE data MUST be available on two levels:

1. resolvable URIs for individual resources

2. data dumps for datasets

It MAY additionally be available through a:

3. SPARQL endpoint.

If the generic data model is used alongside domain data models, there are two methods for doing so:

• § 3.6.2 Combined

• § 3.6.3 Separate profiles.

In this case, publishers MUST support at least one of these methods.

3.6.2. Combined

With RDF, it’s perfectly fine to express the same data in multiple ways. Therefore, the generic and domain data models MAY coexist in the same information resource.

{
  "@context": [
    "https://linked.art/ns/v1/linked-art.json",
    {
      "schema": "https://schema.org/"
    }
  ],
  "id": "https://literatuurmuseum.nl/id/123456789",
  "type": ["HumanMadeObject", "schema:CreativeWork", "schema:VisualArtwork"],
  "_label": "Het fluitketeltje en andere versjes",
  "produced_by": {
    "type": "Production",
    "carried_out_by": [
      {
        "id": "http://data.rkd.nl/artists/8342",
        "type": "Person"
      }
    ]
  },
  "schema:name": "Het fluitketeltje en andere versjes",
  "schema:creator": {
    "@id": "http://data.rkd.nl/artists/8342",
    "@type": "schema:Person"
  }
}

3.6.3. Separate profiles

Alternatively, publishers MAY separate the generic data model by using profile-based content negotiation (see [DX-PROF-CONNEG]). To do so, publish a profile with URI https://docs.nde.nl/schema-profile/.

Note: While still a draft, [DX-PROF-CONNEG] has already been implemented, for example by the Rijksmuseum.

Note: This method does not apply to SPARQL endpoints, which use the SPARQL protocol and do not support profile-based content negotiation.

# Get the list of profiles.
GET /resource/a?profile=alt HTTP/1.1

# Server responds with a list of profiles that includes the NDE generic data model.
HTTP/1.1 200 OK
Content-Type: application/json

{
    "resource": "http://example.org/resource/a",
    "profiles": [
        {
            "token": "nde",
            "uri": "https://docs.nde.nl/schema-profile/",
            "media_types": ["application/ld+json", "text/turtle"]
        },
        ...
    ]
}

It is then possible to request the metadata record in the generic data model using the Accept-Profile HTTP header:

GET /resource/a HTTP/1.1
Accept: application/ld+json
Accept-Profile: <https://docs.nde.nl/schema-profile/>

# Server responds with a SCHEMA-AP-NDE representation of the metadata record.
HTTP/1.1 200 OK
Content-Type: application/ld+json

...

4. Data model

This section describes the classes and properties that MUST be used to publish metadata records in the heritage network.

Each record MUST be typed as one of the following classes:

• CreativeWork

• Person

• Organization

• Place.

For each of these classes, the sections below list the REQUIRED and OPTIONAL properties.

MediaObject is documented as a supporting class, used through the associatedMedia property on CreativeWork.

DefinedTerm, used to reference terms on properties such as genre, material and about, is documented under Reference terms.

4.1. Class diagram

4.2. CreativeWork

The type for heritage objects ([DERA]’s cultuurhistorisch object) in this application profile.

Some heritage objects fit CreativeWork well, such as paintings, books or musical compositions. Others are a less natural fit, such as fossils, buses or bridges, either because they are not ‘creative works’ in the everyday sense or because they fit somewhere else in Schema.org’s type hierarchy.

Nevertheless, CreativeWork serves as the catch-all type for all heritage objects in this application profile, to differentiate them from the other top-level classes (Person, Organization, Place).

For more fine-grained typing, § 4.2.9 additionalType SHOULD be used.

Note: CreativeWork does not reference the Dutch legal concept 'creatief werk' as used in the Auteurswet (Copyright Act of 1912) in any way.

4.2.1. Subclasses

Publishers SHOULD use more fine-grained classes alongside the top-level class CreativeWork. Examples include, but are not limited to:

• Article for stories;

• ArchiveComponent for archival items and collections;

• Book;

• Manuscript;

• Message for letters;

• MusicComposition, MusicRecording and MusicAlbum for musical items and collections;

• Painting;

• Photograph.

{
  "@context": "https://schema.org",
  "@id": "https://n2t.net/ark:/123456/1",
  "@type": ["CreativeWork", "Painting"]
}

Even though the superclass can be derived from its subclasses using RDF inferencing (in this example, CreativeWork from Painting), the superclass MUST be provided explicitly to help users understand the data.

Use @type only for Schema.org classes: the top-level CreativeWork together with any Schema.org subclass that applies. Types drawn from other vocabularies, such as a Getty AAT concept, are terms rather than Schema.org classes and MUST NOT appear in @type; reference them through additionalType as a DefinedTerm instead.

When a Schema.org subclass and an external term describe the same concept (for example Painting and the AAT term “paintings”), asserting both is expected and complementary, not redundant: the @type records the Schema.org class, while additionalType adds the precise, linkable vocabulary term.

4.2.2. URI (required)

Each CreativeWork MUST be identified by a persistent URI. Blank nodes MUST NOT be used.

{  "@context": "https://schema.org",  "@id": "https://example.com/resource",  "@type": "CreativeWork"}

4.2.3. name (required)

{  "@context": "https://schema.org",  "@id": "https://example.com/dataset1/resource1",  "@type": "CreativeWork",  "name": [    {      "@language": "nl",      "@value": "De Sterrennacht"    },    {      "@language": "en",      "@value": "The Starry Night"    }  ]}

4.2.4. sdDatePublished (required)

The value MUST be in [ISO8601] format: YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ.

4.2.5. isPartOf

This contextualizes the CreativeWork for consumers, with the dataset’s description providing information about properties that are shared between CreativeWorks in the same dataset, such as publisher and license.

Note that a CreativeWork may be part of multiple datasets.

The dataset MUST be typed as a Dataset.

The isPartOf property MAY also be used to indicate hierarchical relations between CreativeWorks within the dataset. In that case, the value’s type will be something other than Dataset. This usage is out of scope for this document.

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/1",  "@type": "CreativeWork",  "isPartOf": {    "@id": "https://organization.com/dataset1",    "@type": "Dataset"  }}

4.2.6. associatedMedia

If an IIIF Presentation API manifest is available for the CreativeWork, it MUST be included as an additional associatedMedia entry with:

• @id set to the manifest URI

• encodingFormat set to application/ld+json;profile='http://iiif.io/api/presentation/3/context.json'.

• license matching the rights property specified in the presentation manifest

The IIIF Presentation manifest MUST describe all media for the CreativeWork.

IIIF-aware consumers SHOULD access media via the IIIF Presentation manifest.

Non-IIIF consumers SHOULD access media via the per-image entries’ contentUrl and thumbnailUrl, and can ignore the manifest entry (it has no contentUrl).

Note: Schema.org lists MediaObject as the only range of associatedMedia. This profile additionally permits a single IIIF Presentation manifest entry, which is not itself a MediaObject but is identified by its encodingFormat rather than by its class.

See MediaObject for this property’s allowed values.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "associatedMedia": {    "@type": ["MediaObject", "ImageObject"],    "license": "https://creativecommons.org/publicdomain/zero/1.0/",    "contentUrl": "https://demo.limb-gallery.com/i/?IIIF=/7b/2e/bc/4c/7b2ebc4c-1a55-4d5d-a154-8b590764caa6/iiif/Van_Gogh_-_Starry_Night_-_Google_Art_Project.tif/full/max/0/default.jpg",    "thumbnailUrl": "https://demo.limb-gallery.com/i/?IIIF=/7b/2e/bc/4c/7b2ebc4c-1a55-4d5d-a154-8b590764caa6/iiif/Van_Gogh_-_Starry_Night_-_Google_Art_Project.tif/full/%5E!256,256/0/default.jpg"  }}

{  "@context": "https://schema.org",  "@type": "CreativeWork",  "associatedMedia": [    {      "@type": ["MediaObject", "ImageObject"],      "license": "https://creativecommons.org/publicdomain/zero/1.0/",      "contentUrl": "https://demo.limb-gallery.com/i/?IIIF=/7b/2e/bc/4c/7b2ebc4c-1a55-4d5d-a154-8b590764caa6/iiif/Van_Gogh_-_Starry_Night_-_Google_Art_Project.tif/full/max/0/default.jpg",      "thumbnailUrl": "https://demo.limb-gallery.com/i/?IIIF=/7b/2e/bc/4c/7b2ebc4c-1a55-4d5d-a154-8b590764caa6/iiif/Van_Gogh_-_Starry_Night_-_Google_Art_Project.tif/full/%5E!256,256/0/default.jpg"    },    {      "@id": "https://demo.limb-gallery.com/iiif/25290/manifest",      "license": "https://creativecommons.org/publicdomain/zero/1.0/",      "encodingFormat": "application/ld+json;profile='http://iiif.io/api/presentation/3/context.json'"    }  ]}

4.2.7. creator

Even where more specific properties, applicable to CreativeWork’s subtypes, are available in Schema.org, such as artist, composer and director, the creator property MUST be used for consistency. Although Schema.org defines author as equivalent to creator for CreativeWorks, this profile picks creator so that consumers can rely on a single property.

Multiple creators (for example an author and a photographer) MUST each be expressed as separate, flat creator values. The creator property MUST NOT wrap its values in a Role node, since this would force consumers to handle two value shapes. Publishers who wish to express qualified contributor roles MAY do so on a separate property such as contributor, which is outside this profile and does not affect profile validity.

The creator MUST be a Person or Organization, in one of the following forms (most to least preferred):

Preferably, reference a public term (an authority record) by co-typing the creator as a DefinedTerm and adding its URI via sameAs.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "creator": {    "@type": ["DefinedTerm", "Person"],    "name": {      "@language": "nl",      "@value": "Vincent van Gogh"    },    "sameAs": "https://data.rkd.nl/artists/32439"  }}

When no public term is available, give a plain Person or Organization with a name.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "creator": {    "@type": "Person",    "name": {      "@language": "nl",      "@value": "Vincent van Gogh"    }  }}

When it is unknown whether the creator is a person or organization, the type MAY be omitted; a name is still required.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "creator": {    "name": {      "@language": "nl",      "@value": "Vincent van Gogh"    }  }}

4.2.8. identifier

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "identifier": "Q45585"}

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "identifier": {    "@type": "PropertyValue",    "propertyID": {      "@id": "https://registry.identifiers.org/registry/viaf"    },    "value": "176354386",    "url": "http://identifiers.org/viaf:176354386"  }}

4.2.9. additionalType

The value MUST reference a term, modeled as a DefinedTerm (see § 3.4 Reference terms). Because schema:additionalType expects a URL, the DefinedTerm node MUST also be co-typed as URL ("@type": ["DefinedTerm", "URL"]).

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": ["CreativeWork", "Painting"],  "additionalType": {    "@type": ["DefinedTerm", "URL"],    "name": {      "@language": "en",      "@value": "paintings (visual works)"    },    "sameAs": "https://vocab.getty.edu/aat/300033618"  }}

4.2.10. description

{  "@context": "https://schema.org",  "@id": "https://example.com/dataset1/resource1",  "@type": "CreativeWork",  "description": [    {      "@language": "nl",      "@value": "Olieverfschilderij van het uitzicht uit Van Goghs ziekenhuiskamer in Saint-Rémy-de-Provence, vlak voor zonsopkomst."    },    {      "@language": "en",      "@value": "Oil-on-canvas painting depicting the view from his asylum room at Saint-Rémy-de-Provence, just before sunrise."    }  ]}

4.2.11. abstract

{  "@context": "https://schema.org",  "@id": "https://example.com/dataset1/resource1",  "@type": "CreativeWork",  "abstract": [    {      "@language": "nl",      "@value": "Het schilderij is een nachttafereel met gele sterren boven een kleine stad met heuvels. Het is een uitzicht vanuit een denkbeeldig punt over een dorp met kerktoren, met links een vlammende cipres en rechts olijfbomen tegen de heuvels op."    }  ]}

4.2.12. text

This includes content such as:

• the full text of a written work (e.g. story)

• transcribed text from visual media (e.g., inscriptions in photographs).

Note that this property contains plain text only, without preserving structural elements like paragraphs, headings or the relationship between text and embedded media.

{  "@context": "https://schema.org",  "@id": "https://example.com/dataset1/resource1",  "@type": ["CreativeWork", "Article"],  "text": [    {      "@language": "nl",      "@value": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. In a dignissim enim, in hendrerit ipsum. Sed accumsan purus id erat hendrerit rutrum. Nullam luctus, erat luctus fringilla semper, arcu erat gravida mi, vel molestie ex odio et orci. Phasellus vestibulum tristique pulvinar. Aliquam erat volutpat."    }  ]}

4.2.13. size

Because this is a display string, it SHOULD be a language-tagged string (rdf:langString), for example “24 inches high by 18 inches wide”@en and “61 cm hoog bij 46 cm breed”@nl. A plain string (xsd:string) is only allowed for backwards compatibility.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "size": [    { "@value": "29 inches high by 36 inches wide", "@language": "en" },    { "@value": "74 cm hoog bij 92 cm breed", "@language": "nl" }  ]}

4.2.14. contentLocation

The value MUST reference a term, or, if no term is available, a custom Place resource MUST be used. Because schema:contentLocation takes Place, not DefinedTerm, Place must be added to @type.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "contentLocation": {    "@type": ["DefinedTerm", "Place"],    "name": {      "@language": "fr",      "@value": "Saint-Rémy-de-Provence"    },    "sameAs": "http://www.wikidata.org/entity/Q221507"  }}

4.2.15. temporalCoverage

The value MUST be either an [ISO8601] date or time interval (such as ‘2011’, ‘2011/2012’, ‘1889-06/07’ for shortened notation, ‘-0430/-0403’ for the Peloponnesian War (431 to 404 BCE), ‘-38000/-33000’ for deep-time ranges whose years exceed four digits, or ‘1440/..’ for an open-ended range), or a reference to a period. A year MUST keep the [ISO8601] minimum of four digits (zero-padded) and MAY exceed four digits for deep time. A leading minus marks a BCE year, but note how [ISO8601] reads it: years are numbered astronomically, with a year 0000 that equals 1 BCE, so a negative year is one year older than its digits read as a label (‘-0044’ denotes 45 BCE, and the range ‘-0430/-0403’ above denotes 431 to 404 BCE). If the period is a structured entity from a controlled vocabulary (such as AAT), it MUST be referenced as a DefinedTerm so that consumers receive structured typing. A bare HTTP(S) URI is allowed only for backward compatibility and SHOULD NOT be used in new data.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "temporalCoverage": "1889-06/07"}

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "temporalCoverage": {    "@type": "DefinedTerm",    "name": {      "@language": "en",      "@value": "Dutch Golden Age"    },    "sameAs": "http://www.wikidata.org/entity/Q661566"  }}

4.2.16. locationCreated

The value MUST reference a term, or, if no term is available, a custom Place resource MUST be used. Because schema:locationCreated takes Place, not DefinedTerm, Place must be added to @type.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "locationCreated": {    "@type": ["DefinedTerm", "Place"],    "name": {      "@language": "fr",      "@value": "Saint-Rémy-de-Provence"    },    "sameAs": "http://www.wikidata.org/entity/Q221507"  }}

4.2.17. dateCreated

A single date MUST be given, at the highest precision known (YYYY, YYYY-MM or YYYY-MM-DD).

An interval (such as 1980/1985) MUST NOT be used, even when the exact creation date is uncertain. Unlike schema:temporalCoverage, schema:dateCreated ranges over schema:Date and schema:DateTime only, neither of which permits an [ISO8601] interval; intervals belong to schema:temporalCoverage, which describes the content’s subject period rather than its creation. For an uncertain creation date, drop to the lowest common precision instead (for example 1980 when creation is known only to fall within 1980–1985).

The value MUST be in [ISO8601] format: YYYY-MM-DD, YYYY-MM, or YYYY. Provide the date at the highest precision known. If the exact date is unknown, a partial [ISO8601] date MAY be used:

• "1889-06-15" if the full date is known;

• "1889-06" if only the year and month are known;

• "1889" if only the year is known.

A year before 1 CE takes a leading minus ("-0044"), and a year MAY exceed four digits for deep time ("-38000"); in both cases it MUST keep the [ISO8601] minimum of four digits (zero-padded). [ISO8601] numbers years astronomically, with a year 0000 that equals 1 BCE, so a negative year is one year older than its digits read as a label: "-0044" denotes 45 BCE, and 44 BCE is written "-0043".

In JSON-LD, a plain string is enough, because it is automatically typed as schema:Date, which accepts all three forms. When typing literals explicitly (Turtle, N-Triples, or any other RDF serialization), match the datatype to the precision: xsd:date for full dates only, xsd:gYearMonth for YYYY-MM, and xsd:gYear for YYYY. A partial date MUST NOT be typed as xsd:date (e.g. "1699"^^xsd:date), since that is malformed XSD; use xsd:gYear, xsd:gYearMonth, or schema:Date instead.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "dateCreated": "1889-06"}

{  "@context": [    "https://schema.org",    {      "xsd": "http://www.w3.org/2001/XMLSchema#"    }  ],  "@id": "https://www.vondel.humanities.uva.nl/onstage/plays/1043",  "@type": "CreativeWork",  "dateCreated": {    "@value": "1699",    "@type": "xsd:gYear"  }}

4.2.18. about

The value MUST reference a term, another [[#CreativeWork|CreativeWork]], or the [[#Person|Person]] or [[#Organization|Organization]] that is the subject. A subject that is also described as an entity in the dataset MAY be referenced directly, without co-typing it as a DefinedTerm.

If the subject is a location, it MUST be listed under contentLocation instead.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "about": [    {      "@type": "DefinedTerm",      "name": {        "@language": "en",        "@value": "starry sky"      },      "sameAs": "http://www.wikidata.org/entity/Q149908"    },    {      "@type": "DefinedTerm",      "name": {        "@language": "en",        "@value": "Moon"      },      "sameAs": "http://www.wikidata.org/entity/Q405"    }  ]}

4.2.19. material

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "material": [    {      "@type": ["DefinedTerm", "URL"],      "name": {        "@language": "en",        "@value": "oil paint (paint)"      },      "sameAs": "http://vocab.getty.edu/aat/300015050"    },    {      "@type": ["DefinedTerm", "URL"],      "name": {        "@language": "en",        "@value": "canvas (textile material)"      },      "sameAs": "http://vocab.getty.edu/aat/300014078"    }  ]}

4.2.20. genre

The value MUST reference a term.

{  "@context": "https://schema.org",  "@id": "http://www.wikidata.org/entity/Q45585",  "@type": "CreativeWork",  "genre": {    "@type": "DefinedTerm",    "name": {      "@language": "en",      "@value": "Post-Impressionist"    },    "sameAs": "http://vocab.getty.edu/aat/300021508"  }}

4.3. Organization

An Organization SHOULD be identified by a persistent URI – self-minted or from an organization directory – and, where the organization is known in a public source, linked to it via sameAs, so that consumers can deduplicate it within and across datasets. Where no URI is known, it MAY be defined inline by its properties, like a Person.

4.3.1. name (required)

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/3",  "@type": "Organization",  "name": {    "@language": "en",    "@value": "Example Museum"  }}

4.3.2. location

See Place for this property’s allowed values.

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/3",  "@type": "Organization",  "location": {    "@type": "Place",    "name": {      "@language": "en",      "@value": "Office"    },    "address": {      "@type": "PostalAddress",      "streetAddress": "Street 123",      "postalCode": "1234 AB",      "addressLocality": "City",      "addressRegion": "Noord-Holland",      "addressCountry": "NL"    }  }}

4.4. Person

If a metadata record is a person, it MUST be typed as Person. The value MUST reference a term if one is available for the person; otherwise, the person MUST be defined by the required properties listed below.

The objective for the Person model is not to fully describe all aspects of a person, but to easily identify and distinguish between similar persons.

4.4.1. name (required)

The name MUST NOT contain information that belongs to other properties, such as birthDate or deathDate.

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/2",  "@type": "Person",  "name": {    "@language": "nl",    "@value": "Pluk van de Petteflat"  }}

4.4.2. birthDate

The value MUST be in [ISO8601] format: YYYY-MM-DD, YYYY-MM, or YYYY. Provide the date at the highest precision known. If the exact date is unknown, a partial [ISO8601] date MAY be used:

• "1889-06-15" if the full date is known;

• "1889-06" if only the year and month are known;

• "1889" if only the year is known.

A year before 1 CE takes a leading minus ("-0044"), and a year MAY exceed four digits for deep time ("-38000"); in both cases it MUST keep the [ISO8601] minimum of four digits (zero-padded). [ISO8601] numbers years astronomically, with a year 0000 that equals 1 BCE, so a negative year is one year older than its digits read as a label: "-0044" denotes 45 BCE, and 44 BCE is written "-0043".

In JSON-LD, a plain string is enough, because it is automatically typed as schema:Date, which accepts all three forms. When typing literals explicitly (Turtle, N-Triples, or any other RDF serialization), match the datatype to the precision: xsd:date for full dates only, xsd:gYearMonth for YYYY-MM, and xsd:gYear for YYYY. A partial date MUST NOT be typed as xsd:date (e.g. "1699"^^xsd:date), since that is malformed XSD; use xsd:gYear, xsd:gYearMonth, or schema:Date instead.

4.4.3. birthPlace

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/2",  "@type": "Person",  "birthPlace": {    "@type": ["DefinedTerm", "Place"],    "name": {      "@language": "nl",      "@value": "Utrecht"    },    "sameAs": "https://sws.geonames.org/2745912/"  }}

4.4.4. deathDate

The value MUST be in [ISO8601] format: YYYY-MM-DD, YYYY-MM, or YYYY. Provide the date at the highest precision known. If the exact date is unknown, a partial [ISO8601] date MAY be used:

• "1889-06-15" if the full date is known;

• "1889-06" if only the year and month are known;

• "1889" if only the year is known.

A year before 1 CE takes a leading minus ("-0044"), and a year MAY exceed four digits for deep time ("-38000"); in both cases it MUST keep the [ISO8601] minimum of four digits (zero-padded). [ISO8601] numbers years astronomically, with a year 0000 that equals 1 BCE, so a negative year is one year older than its digits read as a label: "-0044" denotes 45 BCE, and 44 BCE is written "-0043".

In JSON-LD, a plain string is enough, because it is automatically typed as schema:Date, which accepts all three forms. When typing literals explicitly (Turtle, N-Triples, or any other RDF serialization), match the datatype to the precision: xsd:date for full dates only, xsd:gYearMonth for YYYY-MM, and xsd:gYear for YYYY. A partial date MUST NOT be typed as xsd:date (e.g. "1699"^^xsd:date), since that is malformed XSD; use xsd:gYear, xsd:gYearMonth, or schema:Date instead.

4.4.5. deathPlace

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/2",  "@type": "Person",  "deathPlace": {    "@type": ["DefinedTerm", "Place"],    "name": {      "@language": "nl",      "@value": "Auvers-sur-Oise"    },    "sameAs": "http://www.wikidata.org/entity/Q131153786"  }}

4.4.6. hasOccupation

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/2",  "@type": "Person",  "hasOccupation": {    "@type": ["DefinedTerm", "Occupation"],    "name": {      "@language": "en",      "@value": "carpenter"    },    "sameAs": "http://vocab.getty.edu/aat/300025008"  }}

{  "@context": "https://schema.org",  "@id": "https://n2t.net/ark:/123456/2",  "@type": "Person",  "hasOccupation": {    "@type": "Occupation",    "name": {      "@language": "nl",      "@value": "sekreetruimer"    }  }}

4.5. Place

For properties that reference locations, if no term is available, a custom Place resource MUST be used instead.

4.5.1. name (required)

4.5.2. address

See PostalAddress for this property’s allowed values.

{  "@context": "https://schema.org",  "@id": "https://example.com/dataset/place",  "@type": "Place",  "address": {    "@type": "PostalAddress",    "streetAddress": "Street 123",    "postalCode": "1234 AB",    "addressLocality": "City",    "addressRegion": "Noord-Holland",    "addressCountry": "NL"  }}

4.5.3. geo

{  "@context": "https://schema.org",  "@type": "Place",  "@id": "https://example.com/dataset/place",  "geo": {    "@type": "GeoCoordinates",    "latitude": 37.42242,    "longitude": 122.08585  }}

4.6. MediaObject

In case of image, video, audio or 3d model objects, in addition to the MediaObject class, the relevant subclass MUST be used:

• ImageObject

• VideoObject

• AudioObject

• 3DModel

For other types of media, the generic class MediaObject MUST be used by itself.

4.6.1. license (required)

The value SHOULD be an open license that allows the media to be consumed, for example one of the Creative Commons licenses.

{  "@context": "https://schema.org",  "@type": "MediaObject",  "license": "https://creativecommons.org/publicdomain/zero/1.0/"}

4.6.2. contentUrl (required)

For ImageObjects, this SHOULD be a high-resolution image to be used in full-screen viewers etc.

{  "@context": "https://schema.org",  "@type": ["MediaObject", "ImageObject"],  "contentUrl": "https://demo.limb-gallery.com/i/?IIIF=/7b/2e/bc/4c/7b2ebc4c-1a55-4d5d-a154-8b590764caa6/iiif/Van_Gogh_-_Starry_Night_-_Google_Art_Project.tif/full/max/0/default.jpg"}

4.6.3. thumbnailUrl (required)

For ImageObjects, this SHOULD be a small image to be used in lists, search results etc.

{  "@context": "https://schema.org",  "@type": ["MediaObject", "ImageObject"],  "contentUrl": "https://demo.limb-gallery.com/i/?IIIF=/7b/2e/bc/4c/7b2ebc4c-1a55-4d5d-a154-8b590764caa6/iiif/Van_Gogh_-_Starry_Night_-_Google_Art_Project.tif/full/max/0/default.jpg",  "thumbnailUrl": "https://demo.limb-gallery.com/i/?IIIF=/7b/2e/bc/4c/7b2ebc4c-1a55-4d5d-a154-8b590764caa6/iiif/Van_Gogh_-_Starry_Night_-_Google_Art_Project.tif/full/%5E!256,256/0/default.jpg"}

4.6.4. copyrightNotice

{  "@context": "https://schema.org",  "@type": ["MediaObject", "ImageObject"],  "license": "https://creativecommons.org/licenses/by-sa/4.0/",  "copyrightNotice": {    "@language": "en",    "@value": "© 2025 Example Museum, with permission from Ph. Otographer"  }}

4.7. PostalAddress

A postal address for an Organization or Place. All properties are OPTIONAL.

4.7.1. streetAddress

4.7.2. postalCode

4.7.3. addressLocality

4.7.4. addressRegion

4.7.5. addressCountry

4.8. GeoCoordinates

Geographic coordinates for a Place.

4.8.1. latitude (required)

The value MUST be an xsd:double or an xsd:decimal. Both are accepted because a plain decimal literal in Turtle (for example 52.379189) is typed xsd:decimal, while the same value in JSON-LD becomes xsd:double.

4.8.2. longitude (required)

The value MUST be an xsd:double or an xsd:decimal. Both are accepted because a plain decimal literal in Turtle (for example 4.899431) is typed xsd:decimal, while the same value in JSON-LD becomes xsd:double.

5. Full examples

Some full examples of metadata records.

5.1. Story

{
  "@context": "https://schema.org",
  "@id": "https://www.bhic.nl/ontdekken/verhalen/vincent-van-gogh-op-kostschool",
  "@type": ["CreativeWork", "Article"],
  "name": {
    "@language": "nl",
    "@value": "Vincent van Gogh op kostschool"
  },
  "creator": {
    "@type": "Person",
    "name": {
      "@language": "nl",
      "@value": "Cor Kerstens"
    }
  },
  "isPartOf": {
    "@id": "https://www.bhic.nl/ontdekken/verhalen",
    "@type": "Dataset"
  },
  "associatedMedia": {
    "@id": "https://www.bhic.nl/memorix/images/search/detail/31c4cc62-45fb-11e3-8624-e7bda1721fcf/media/26097b4e-deca-d99c-4c2d-2598d67b61a0",
    "@type": ["MediaObject", "ImageObject"],
    "license": "https://creativecommons.org/licenses/by-sa/4.0/",
    "contentUrl": "https://webservices.memorix.nl/mediabank/media/31c4cc62-45fb-11e3-8624-e7bda1721fcf/downloadoriginal/26097b4e-deca-d99c-4c2d-2598d67b61a0?apiKey=24c66d08-da4a-4d60-917f-5942681dcaa1",
    "thumbnailUrl": "https://webservices.memorix.nl/mediabank/media/31c4cc62-45fb-11e3-8624-e7bda1721fcf/download512/26097b4e-deca-d99c-4c2d-2598d67b61a0?apiKey=24c66d08-da4a-4d60-917f-5942681dcaa1",
    "caption": {
      "@language": "nl",
      "@value": "De voormalige kostschool, Stationsstraat 16 in Zevenbergen"
    },
    "copyrightNotice": {
      "@language": "nl",
      "@value": "BHIC"
    }
  },
  "additionalType": {
    "@type": ["DefinedTerm", "URL"],
    "name": {
      "@language": "nl",
      "@value": "biografische schets"
    },
    "sameAs": "http://vocab.getty.edu/aat/300404016"
  },
  "description": {
    "@language": "nl",
    "@value": "Van 1 oktober 1864 tot 31 augustus 1866 verbleef Vincent van Gogh op de kostschool van Jan Provily in Zevenbergen. Vincent zelf vertelt er in drie brieven kort iets over. Hieruit blijkt dat hij zich hier niet zo gelukkig heeft gevoeld."
  },
  "abstract": {
    "@language": "nl",
    "@value": "Van 1 oktober 1864 tot 31 augustus 1866 verbleef Vincent van Gogh op de kostschool van Jan Provily in Zevenbergen."
  },
  "text": {
    "@language": "nl",
    "@value": "Domineeszoon Vincent van Gogh werd op 30 maart 1853 in het Brabantse grensdorp Zundert geboren. Tot zijn 8ste jaar kreeg hij les van zijn vader (…)"
  },
  "contentLocation": {
    "@type": ["DefinedTerm", "Place"],
    "name": {
      "@language": "nl",
      "@value": "Stationsstraat in Zevenbergen"
    },
    "sameAs": "http://www.wikidata.org/entity/Q19547129"
  },
  "temporalCoverage": "1864/1866",
  "dateCreated": "2019-04-25",
  "sdDatePublished": {
    "@type": "http://www.w3.org/2001/XMLSchema#date",
    "@value": "2024-01-15"
  },
  "about": [
    {
      "@type": "DefinedTerm",
      "name": {
        "@language": "nl",
        "@value": "Vincent van Gogh"
      },
      "sameAs": "https://data.rkd.nl/artists/32439"
    },
    {
      "@type": "DefinedTerm",
      "name": {
        "@language": "nl",
        "@value": "kostscholen"
      },
      "sameAs": "https://data.cultureelerfgoed.nl/term/id/cht/596dac9d-868f-461e-bbf9-6baae4fb5a12"
    }
  ],
  "genre": {
    "@type": "DefinedTerm",
    "name": {
      "@language": "nl",
      "@value": "biografieën"
    },
    "sameAs": "http://vocab.getty.edu/aat/300080102"
  }
}

6. Formal definition

SHACL shapes for validating against SCHEMA-AP-NDE are available at GitHub.

To guarantee consistency, this specification document is built from those SHACL shapes.

The SHACL shapes use the https://schema.org/ namespace. However, Schema.org’s default JSON-LD context at https://schema.org/docs/jsonldcontext.jsonld resolves all terms to http://schema.org/ IRIs. Consumers that process JSON-LD data need to override the context so that the resulting RDF triples use the https://schema.org/ namespace.

A ready-to-use context is available at https://docs.nde.nl/schema-profile/context.jsonld. It uses [JSON-LD11]’s @import to inherit Schema.org’s type coercions (e.g. url and sameAs remain IRIs) while overriding the namespace to https://. Consumers can apply this context when expanding JSON-LD data before validation or querying:

{
  "@context": "https://docs.nde.nl/schema-profile/context.jsonld",
  "@type": "CreativeWork",
  "name": "Example"
}

Alternatively, consumers can inline the context to avoid a dependency on the hosted version:

{
  "@context": {
    "@version": 1.1,
    "@import": "https://schema.org/docs/jsonldcontext.jsonld",
    "@vocab": "https://schema.org/",
    "schema": "https://schema.org/"
  },
  "@type": "CreativeWork",
  "name": "Example"
}

Beyond the namespace override, the hosted context declares [JSON-LD11] containers that make the data easier to consume. When a consumer compacts JSON-LD data with it:

• multi-valued properties (such as creator, material and identifier) are always returned as arrays (@container: @set), so a consumer never has to test whether a value is a single object or a list; and

• language-tagged text properties (name, description, abstract and text) are returned as language maps (@container: @language), keyed by language tag, so a value can be read directly as name.nl or name.en.

These containers take effect only on compaction with this context; they do not change the underlying RDF triples, so data stays conformant whether or not a consumer applies them. The minimal inline override shown above covers only the namespace override — consumers that want always-arrays and language maps should use the hosted context, which declares the containers.

{
  "@context": "https://docs.nde.nl/schema-profile/context.jsonld",
  "@type": "CreativeWork",
  "name": {
    "nl": "De Nachtwacht",
    "en": "The Night Watch"
  },
  "creator": [
    { "@type": "Person", "name": { "nl": "Rembrandt van Rijn" } }
  ]
}

7. Changes

This section lists notable changes to this specification.

7.1. Version 1.2.0 (2026-07-09)

• Accept BCE and beyond-four-digit years in dates: dateCreated, birthDate, and deathDate now validate a leading minus (BCE) and years of four or more digits directly as plain JSON-LD strings, where previously that was reachable only by explicitly typing xsd:gYear; and temporalCoverage no longer caps years at four digits, so deep-time ranges such as -38000/-33000 validate (a05f097).

• Allow Person and Organization as schema:about subject (f051117).

• Typo (faf1dc2).

7.2. Version 1.1.0 (2026-06-29)

• Add @set and @language containers to the JSON-LD context (d379caf).

• Allow temporalCoverage to reference a period as a DefinedTerm (e2f698f).

• Host the JSON-LD context in this repo at /schema-profile/context.jsonld (c7e160d).

• Show a local @id on DefinedTerm alongside the canonical sameAs (8ff61e2).

• Accept xsd:decimal for geo coordinates (23556e4).

• Clarify identifier is per-value, matching its 0..* cardinality (75b5c4b).

• Clarify that the support-method requirement is conditional (c57e896).

• Clarify when to use additionalType vs @type (7528a88).

• Recommend language-tagged size for display strings (b47073a).

• Recommend the und language tag for unknown-language values (b0ba872).

• Add CONTRIBUTING with proposal-evaluation criteria (53a91bd).

• Explain why dateCreated rejects intervals (fcee0e9).

7.3. Version 1.0.0 (2026-06-01)

• First stable release, carrying a backward compatibility promise: within 1.x, data that conforms today keeps conforming, and consumers that ignore properties and values they do not recognise keep working. Changes are additive, relaxing or clarifying, and any breaking changes that would invalidate conforming data wait for a 2.0.

7.4. Version 0.16.0 (2026-06-01)

• Limit dateCreated to a single value (43665b6).

• Limit sdDatePublished to a single value (eb619c1).

• Require isPartOf to reference a dataset by IRI (8dac795).

7.5. Version 0.15.1 (2026-05-30)

• Use Linked Art in combined modelling example (c0af88c).

7.6. Version 0.15.0 (2026-05-29)

• Explain term co-typing (0208413).

• Explain term equivalence (9478442).

• Make Organization URI optional (d09dc0f).

• Model additionalType as a DefinedTerm with sameAs (ef49953).

• Cross-reference DefinedTerm from the data-model section (a92a27b).

7.7. Version 0.14.0 (2026-05-21)

• Make isPartOf and associatedMedia optional (4926a21).

7.8. Version 0.13.0 (2026-05-21)

• Make creator optional (a216f98).

• Require sdDatePublished on CreativeWork (0e8480e).

7.9. Version 0.12.0 (2026-05-18)

• Accept xsd:gYear and xsd:gYearMonth in DateShape (ceb0589).

7.10. Version 0.11.1 (2026-05-14)

• Clarify associatedMedia IIIF wording (4e9d2ec).

7.11. Version 0.11.0 (2026-05-14)

• Drop isBasedOn requirement for IIIF Image API (081f7a3).

• Split IIIF Presentation manifest into dedicated SHACL shape (8d5d5b7).

• Comply with tightened SHACL constraints (1e7718b).

7.12. Version 0.10.1 (2026-05-13)

• Use canonical CC0 1.0 URI (9505184).

7.13. Version 0.10.0 (2026-05-13)

• Allow DefinedTerm without sameAs (870f034).

7.14. Version 0.9.1 (2026-04-29)

• Clarify creator vs author and Role usage (541e0e2).

7.15. Version 0.9.0 (2026-04-20)

• Tighten schema:temporalCoverage to ISO 8601 or HTTP(S) URI (cfb13ca).

7.16. Version 0.8.1 (2026-04-06)

• Clarify HTTPS namespace recommendation for existing datasets (08c7c3d).

7.17. Version 0.8.0 (2026-04-02)

• Switch to https://schema.org/ namespace (22ff59a).

7.18. Version 0.7.2 (2026-03-16)

• Add URL co-type to material DefinedTerm for Schema.org validation (6fa9fe0).

• Show multiple data platforms in overview diagram (ada95c8).

7.19. Version 0.7.1 (2026-03-10)

• Remove misleading publication method matrix (a24613d).

7.20. Version 0.7.0 (2026-03-04)

• Use schema:location instead of schema:address on Organization (21b1fbe).

7.21. Version 0.6.0 (2026-03-04)

• Move IIIF Presentation manifest from MediaObject to CreativeWork (d0a2dae).

• Add SHACL validation to reject info.json suffix in isBasedOn URI (aa55f21).

• Use IIIF Image API base URI without /info.json (6a3f05c).

7.22. Version 0.5.0 (2026-03-02)

• Add DERA cross-references (6334d9e).

7.23. Version 0.4.1 (2026-03-02)

• Metadata record definition (97791a2).

• Remove incomplete example (0b968e4).

7.24. Version 0.4.0 (2026-02-23)

• Clarify allowed date formats in SHACL descriptions (7ac5f18).

• Require sameAs on DefinedTerm, use Occupation as hasOccupation fallback (bdddd80).

• Merge CurrentPostalAddress and HistoricalPostalAddress (c20ee9b).

7.25. Version 0.3.0 (2026-02-20)

• Use sameAs for referencing terms (045e748).

• Show spec version in header (0e8bc58).

• Allow literal strings for sdo:hasOccupation (166c5d5).

• Use dual typing in term examples (a24d070).

7.26. Version 0.2.0 (2026-02-20)

• Allow untyped creator nodes (95ffa50).