Baseline Patterns

Table of Contents

Core Properties
Types and Classifications
- Types of Types
Names and Identifiers for a Resource
- Names
- Identifiers
Statements about a Resource
Parts
- Membership
Events and Activities
- Time Span Details

It is useful to have some common baseline patterns to follow when using a very open ontology, like CIDOC-CRM. From working with datasets from across many different museums, the following patterns have been agreed on as useful ways to think about our cultural data.

These patterns are presented below with examples of how they are used in practice, but these are not intended to be exhaustive. The documentation for the different resource types will include more information about how they are used in different circumstances.

Core Properties

There are a few core properties that every resource should have for it to be a useful part of the world of Linked Open Data:

@context is a reference to the context mapping which determines how to interpret the JSON as Linked Open Data. It is not a property of the entity being described, but of the document. It must be present.
id captures the URI that identifies the object. Every resource must have exactly one id, and it must be an HTTP URI.
type captures the class of the object, or rdf:type in RDF. Every resource must have exactly one class. This allows software to align the data model with an internal, object oriented class based implementation.
_label captures a human readable label as a string, intended for developers or other people reading the data to understand what they are looking at. Every resource should have exactly one label, and must not have more than one. It is just a string, and does not have a language associated with it -- if multiple languages are available for the content, then implementations can choose which is most likely to be valuable for a developer looking at the data.

Example:

The simplest possible object has a URI, a class and a label.

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/20",
  "type": "HumanMadeObject",
  "_label": "Example Object"
}

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Types and Classifications

CIDOC-CRM is a framework that must be extended via additional vocabularies and ontologies to be useful. The provided mechanism for doing this is the classified_as property, which refers to a term from a controlled vocabulary. This is in contrast to the type property described above, which is used for CIDOC-CRM defined classes, and a few extensions as needed. The classified_as property is thus a way to be more specific about the sort of entity, while maintaining the core information as the class using type. Controlled vocabulary entries should not be used with type, nor classes used with classified_as.

While any external vocabulary of terms can be used, the Getty's Art and Architecture Thesaurus is used whenever possible for consistency and that it is already widespread in the museum domain. The set of terms that have been identified as useful are listed in the community best-practices for recommendations, and within the documentation of the model when a particular choice is essential for interoperability.

Use cases for this pattern are in almost every example, but include:

The object being an art object
The type of an art object being a painting
The type of a description being a materials statement
The type of an identifier being an accession number
The type of an organization being a museum
The type of a place being a gallery

Example:

The type of the object (an instance of the class HumanMadeObject) is a painting (aat:300033618), and an artwork (aat:300133025):

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/21",
  "type": "HumanMadeObject",
  "_label": "Simple Example Painting",
  "classified_as": [
    {
      "id": "http://vocab.getty.edu/aat/300033618",
      "type": "Type",
      "_label": "Painting"
    },
    {
      "id": "http://vocab.getty.edu/aat/300133025",
      "type": "Type",
      "_label": "Work of Art"
    }
  ]
}

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Types of Types

A common pattern is to not only classify main entities, but also to classify the types themselves in order to know what sort of type it is, without recognizing all of them individually. This is important when the set of first degree types is not easily enumerable, such as classifications for the type of object or work. If the set of vocabulary terms that can normally be used without further extension can be established, then this pattern is not used. This is also not needed when the relationship from the entity to the first degree type clarifies this, such as the motivation or about properties.

Use cases for this pattern include:

The classification is the type of object or work of the physical thing (e.g. Painting)
The classification is the type of text of the statement (e.g. Dimensions Statement)
The classification is the nationality of the person (e.g. Swiss)

Example:

The physical thing is classified as being a Painting, and the concept "Painting" is for classifying the type of object (as opposed to any other sort of classification).

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/22",
  "type": "HumanMadeObject",
  "_label": "Example Painting",
  "classified_as": [
    {
      "id": "http://vocab.getty.edu/aat/300033618",
      "type": "Type",
      "_label": "Painting",
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300435443",
          "type": "Type",
          "_label": "Type of Work"
        }
      ]
    },
    {
      "id": "http://vocab.getty.edu/aat/300133025",
      "type": "Type",
      "_label": "Artwork"
    }
  ]
}

graph TD classDef object stroke:black,fill:#E1BA9C,rx:20px,ry:20px; classDef actor stroke:black,fill:#FFBDCA,rx:20px,ry:20px; classDef type stroke:red,fill:#FAB565,rx:20px,ry:20px; classDef name stroke:orange,fill:#FEF3BA,rx:20px,ry:20px; classDef dims stroke:black,fill:#c6c6c6,rx:20px,ry:20px; classDef infoobj stroke:#907010,fill:#fffa40,rx:20px,ry:20px classDef timespan stroke:blue,fill:#ddfffe,rx:20px,ry:20px classDef place stroke:#3a7a3a,fill:#aff090,rx:20px,ry:20px classDef event stroke:#1010FF,fill:#96e0f6,rx:20px,ry:20px classDef literal stroke:black,fill:#f0f0e0; classDef classstyle stroke:black,fill:white; O1(object22) class O1 object; O1-- type -->O1_0[HumanMadeObject] class O1_0 classstyle; O1-- _label -->O1_4("''Example Painting''") class O1_4 literal; O2(aat:300033618) class O2 type; O2-- type -->O2_0[Type] class O2_0 classstyle; O2-- _label -->O2_3("''Painting''") class O2_3 literal; O3(aat:300435443) class O3 type; O3-- type -->O3_0[Type] class O3_0 classstyle; O3-- _label -->O3_3("''Type of Work''") class O3_3 literal; O2-- classified_as -->O3 O1-- classified_as -->O2 O4(aat:300133025) class O4 type; O4-- type -->O4_0[Type] class O4_0 classstyle; O4-- _label -->O4_3("''Artwork''") class O4_3 literal; O1-- classified_as -->O4

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Names and Identifiers for a Resource

Names

As the _label property is intended as internal documentation for the data, it is strongly recommended that every resource that should be rendered to an end user also have at least one specific name. The name could be for an object, a person, a group, an event or anything else. This pattern uses the identified_by property, with a Name resource. The value of the name is given in the content property of the Name.

It is somewhat unintuitive to think of a name as identifying the resource it is associated with, as names are typically not unique. However, as the name itself is uniquely identified rather than just an anonymous string, they are no longer a shared label and instead the particular instance of a name is uniquely associated with the resource. With this formulation, the name instance does uniquely identify the resource.

If there is more than one name given, then there should be one that is classified_as the primary name for use. This is done by adding the Primary Name (aat:300404670) term to it. There should be exactly one primary title given per language.

Names are also part of human communication, and can have the Linguistic features of the model associated with them, such as having a particular language, or having translations.

Example:

The primary name for the painting is "Pasture and Sheep", which is in English.

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/23",
  "type": "HumanMadeObject",
  "_label": "Painting: Pasture and Sheep",
  "identified_by": [
    {
      "type": "Name",
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300404670",
          "type": "Type",
          "_label": "Primary Name"
        }
      ],
      "content": "Pasture and Sheep",
      "language": [
        {
          "id": "http://vocab.getty.edu/aat/300388277",
          "type": "Language",
          "_label": "English"
        }
      ]
    }
  ]
}

graph TD classDef object stroke:black,fill:#E1BA9C,rx:20px,ry:20px; classDef actor stroke:black,fill:#FFBDCA,rx:20px,ry:20px; classDef type stroke:red,fill:#FAB565,rx:20px,ry:20px; classDef name stroke:orange,fill:#FEF3BA,rx:20px,ry:20px; classDef dims stroke:black,fill:#c6c6c6,rx:20px,ry:20px; classDef infoobj stroke:#907010,fill:#fffa40,rx:20px,ry:20px classDef timespan stroke:blue,fill:#ddfffe,rx:20px,ry:20px classDef place stroke:#3a7a3a,fill:#aff090,rx:20px,ry:20px classDef event stroke:#1010FF,fill:#96e0f6,rx:20px,ry:20px classDef literal stroke:black,fill:#f0f0e0; classDef classstyle stroke:black,fill:white; O1(object23) class O1 object; O1-- type -->O1_0[HumanMadeObject] class O1_0 classstyle; O1-- _label -->O1_4("''Painting: Pasture and Sheep''") class O1_4 literal; O2( _ ) class O2 name; O2-- type -->O2_0[Name] class O2_0 classstyle; O3(aat:300404670) class O3 type; O3-- type -->O3_0[Type] class O3_0 classstyle; O3-- _label -->O3_3("''Primary Name''") class O3_3 literal; O2-- classified_as -->O3 O2-- content -->O2_3("''Pasture and Sheep''") class O2_3 literal; O4(aat:300388277) class O4 type; O4-- type -->O4_0[Language] class O4_0 classstyle; O4-- _label -->O4_3("''English''") class O4_3 literal; O2-- language -->O4 O1-- identified_by -->O2

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Identifiers

Many resources of interest are also given external identifiers, such as accession numbers for objects, ORCIDs for people or groups, lot numbers for auctions, and so forth. Identifiers are represented in a very similar way to names, but instead use the Identifier class. Identifiers will normally have a classification determining which sort of identifier it is, to distinguish between internal repository system assigned numbers from museum assigned accession numbers, for example.

As Identifiers and Names use the same identified_by property, the JSON will frequently have mixed classes in the array. Unlike Names, Identifiers are not part of human language and thus cannot have translations or a language associated with them.

Example:

The accession number identifier for the painting is "P1998-27".

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/24",
  "type": "HumanMadeObject",
  "_label": "Painting: Pasture and Sheep",
  "identified_by": [
    {
      "type": "Identifier",
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300312355",
          "type": "Type",
          "_label": "Accession Number"
        }
      ],
      "content": "P1998-27"
    },
    {
      "type": "Name",
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300404670",
          "type": "Type",
          "_label": "Primary Name"
        }
      ],
      "content": "Pasture and Sheep"
    }
  ]
}

graph TD classDef object stroke:black,fill:#E1BA9C,rx:20px,ry:20px; classDef actor stroke:black,fill:#FFBDCA,rx:20px,ry:20px; classDef type stroke:red,fill:#FAB565,rx:20px,ry:20px; classDef name stroke:orange,fill:#FEF3BA,rx:20px,ry:20px; classDef dims stroke:black,fill:#c6c6c6,rx:20px,ry:20px; classDef infoobj stroke:#907010,fill:#fffa40,rx:20px,ry:20px classDef timespan stroke:blue,fill:#ddfffe,rx:20px,ry:20px classDef place stroke:#3a7a3a,fill:#aff090,rx:20px,ry:20px classDef event stroke:#1010FF,fill:#96e0f6,rx:20px,ry:20px classDef literal stroke:black,fill:#f0f0e0; classDef classstyle stroke:black,fill:white; O1(object24) class O1 object; O1-- type -->O1_0[HumanMadeObject] class O1_0 classstyle; O1-- _label -->O1_4("''Painting: Pasture and Sheep''") class O1_4 literal; O2( _ ) class O2 name; O2-- type -->O2_0[Identifier] class O2_0 classstyle; O3(aat:300312355) class O3 type; O3-- type -->O3_0[Type] class O3_0 classstyle; O3-- _label -->O3_3("''Accession Number''") class O3_3 literal; O2-- classified_as -->O3 O2-- content -->O2_3("''P1998-27''") class O2_3 literal; O1-- identified_by -->O2 O4( _ ) class O4 name; O4-- type -->O4_0[Name] class O4_0 classstyle; O5(aat:300404670) class O5 type; O5-- type -->O5_0[Type] class O5_0 classstyle; O5-- _label -->O5_3("''Primary Name''") class O5_3 literal; O4-- classified_as -->O5 O4-- content -->O4_3("''Pasture and Sheep''") class O4_3 literal; O1-- identified_by -->O4

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Statements about a Resource

In many cases, current data does not support the level of specificity that the full ontology allows, or the information is simply best expressed in human-readable form. For example, instead of a completely modeled set of parts with materials, many museum collection management systems allow only a single human-readable string for the "medium" or "materials statement". The same is true in many other situations, including rights or allowable usage statements, dimensions, edition statements and so forth. Any time that there is a description of the resource, with or without qualification as to the type of description, then this pattern can be used to record the descriptive text.

The pattern makes use of the LinguisticObject class that is used to identify a particular piece of textual content. These Linguistic Objects are then refered to by any other resource. They maintain the statement's text in the content property, and the language of the statement (if known) in the language property.

Use cases for this pattern include:

General description of the resource
Materials statement for an object
Attribution statement for an image
Biography for a person
Dimensions statement for a part of an object

Note that both Names and Statements can have Names (e.g. "Former Title", "Supplied Description") and Statements (such as the source of the name or statement), however best practice is to only use these sparingly.

Example:

Having only a textual description of the materials in English, the content "Oil on Canvas" is recorded as referring to the painting as a "materials" (aat:300435429) statement:

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/25",
  "type": "HumanMadeObject",
  "_label": "Painting on Canvas",
  "referred_to_by": [
    {
      "type": "LinguisticObject",
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300435429",
          "type": "Type",
          "_label": "Material Statement",
          "classified_as": [
            {
              "id": "http://vocab.getty.edu/aat/300418049",
              "type": "Type",
              "_label": "Brief Text"
            }
          ]
        }
      ],
      "content": "Oil on Canvas",
      "language": [
        {
          "id": "http://vocab.getty.edu/aat/300388277",
          "type": "Language",
          "_label": "English"
        }
      ]
    }
  ]
}

graph TD classDef object stroke:black,fill:#E1BA9C,rx:20px,ry:20px; classDef actor stroke:black,fill:#FFBDCA,rx:20px,ry:20px; classDef type stroke:red,fill:#FAB565,rx:20px,ry:20px; classDef name stroke:orange,fill:#FEF3BA,rx:20px,ry:20px; classDef dims stroke:black,fill:#c6c6c6,rx:20px,ry:20px; classDef infoobj stroke:#907010,fill:#fffa40,rx:20px,ry:20px classDef timespan stroke:blue,fill:#ddfffe,rx:20px,ry:20px classDef place stroke:#3a7a3a,fill:#aff090,rx:20px,ry:20px classDef event stroke:#1010FF,fill:#96e0f6,rx:20px,ry:20px classDef literal stroke:black,fill:#f0f0e0; classDef classstyle stroke:black,fill:white; O1(object25) class O1 object; O1-- type -->O1_0[HumanMadeObject] class O1_0 classstyle; O1-- _label -->O1_4("''Painting on Canvas''") class O1_4 literal; O2( _ ) class O2 infoobj; O2-- type -->O2_0[LinguisticObject] class O2_0 classstyle; O3(aat:300435429) class O3 type; O3-- type -->O3_0[Type] class O3_0 classstyle; O3-- _label -->O3_3("''Material Statement''") class O3_3 literal; O4(aat:300418049) class O4 type; O4-- type -->O4_0[Type] class O4_0 classstyle; O4-- _label -->O4_3("''Brief Text''") class O4_3 literal; O3-- classified_as -->O4 O2-- classified_as -->O3 O2-- content -->O2_3("''Oil on Canvas''") class O2_3 literal; O5(aat:300388277) class O5 type; O5-- type -->O5_0[Language] class O5_0 classstyle; O5-- _label -->O5_3("''English''") class O5_3 literal; O2-- language -->O5 O1-- referred_to_by -->O2

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Parts

Describing the hierarchy of parts of resources is a core pattern for having increasingly granular or specific descriptions. The advantage of partitioning is that more specific information can be provided about each part, as a thing separate from the whole. This pattern covers the spectrum of different classes used in the model, from physical and textual, to temporal or geographic. Parts are given using the properties part (from the whole to the part) or part_of (from the part to the whole).

Use cases for this pattern include:

Delineating physical components or aspects of an object, such as the frame being part of the painting, or the recto side being part of the page.
Separating a long period or event into smaller sections, such as battles within a war, or the activities of different people during the production of an object.
Separating geographical locations into smaller subdivisions, such as that the neighborhood is part of the city, which is in turn part of the state.
Partitioning a text into segments, such as that the paragraph is part of a chapter, which is in turn part of the entire book

Example:

The canvas support is part of the overall watercolor painting.

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/26",
  "type": "HumanMadeObject",
  "_label": "Example Painting",
  "made_of": [
    {
      "id": "http://vocab.getty.edu/aat/300015045",
      "type": "Material",
      "_label": "watercolors"
    }
  ],
  "part": [
    {
      "type": "HumanMadeObject",
      "_label": "Canvas Support",
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300014844",
          "type": "Type",
          "_label": "Support",
          "classified_as": [
            {
              "id": "http://vocab.getty.edu/aat/300241583",
              "type": "Type",
              "_label": "Part Type"
            }
          ]
        }
      ],
      "made_of": [
        {
          "id": "http://vocab.getty.edu/aat/300014078",
          "type": "Material",
          "_label": "canvas"
        }
      ]
    }
  ]
}

graph TD classDef object stroke:black,fill:#E1BA9C,rx:20px,ry:20px; classDef actor stroke:black,fill:#FFBDCA,rx:20px,ry:20px; classDef type stroke:red,fill:#FAB565,rx:20px,ry:20px; classDef name stroke:orange,fill:#FEF3BA,rx:20px,ry:20px; classDef dims stroke:black,fill:#c6c6c6,rx:20px,ry:20px; classDef infoobj stroke:#907010,fill:#fffa40,rx:20px,ry:20px classDef timespan stroke:blue,fill:#ddfffe,rx:20px,ry:20px classDef place stroke:#3a7a3a,fill:#aff090,rx:20px,ry:20px classDef event stroke:#1010FF,fill:#96e0f6,rx:20px,ry:20px classDef literal stroke:black,fill:#f0f0e0; classDef classstyle stroke:black,fill:white; O1(object26) class O1 object; O1-- type -->O1_0[HumanMadeObject] class O1_0 classstyle; O1-- _label -->O1_4("''Example Painting''") class O1_4 literal; O2(aat:300015045) class O2 type; O2-- type -->O2_0[Material] class O2_0 classstyle; O2-- _label -->O2_3("''watercolors''") class O2_3 literal; O1-- made_of -->O2 O3( _ ) class O3 object; O3-- type -->O3_0[HumanMadeObject] class O3_0 classstyle; O3-- _label -->O3_2("''Canvas Support''") class O3_2 literal; O4(aat:300014844) class O4 type; O4-- type -->O4_0[Type] class O4_0 classstyle; O4-- _label -->O4_3("''Support''") class O4_3 literal; O5(aat:300241583) class O5 type; O5-- type -->O5_0[Type] class O5_0 classstyle; O5-- _label -->O5_3("''Part Type''") class O5_3 literal; O4-- classified_as -->O5 O3-- classified_as -->O4 O6(aat:300014078) class O6 type; O6-- type -->O6_0[Material] class O6_0 classstyle; O6-- _label -->O6_3("''canvas''") class O6_3 literal; O3-- made_of -->O6 O1-- part -->O3

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Membership

Membership in a set is treated slightly differently. A set can have no members and still be a set, whereas if you destroy the last part of an object, it no longer exists. For example, a department of an organization (a Group) might not have any members due to the retirement of the last member, but there is a still an identifiable, ongoing group that would hopefully gain members when new hires are made. Membership is given using the member or member_of property, instead of the corresponding part and part_of.

Use cases for the membership pattern include:

A curator is a member of the paintings department of the museum.
A painting is part of the collection of a the museum.
An identifier is part of the set of identifiers that collectively make up the accession numbers assigned to paintings by the museum.

Example:

The curator is a member of the paintings department.

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/group/2",
  "type": "Group",
  "_label": "Paintings Department",
  "classified_as": [
    {
      "id": "http://vocab.getty.edu/aat/300263534",
      "type": "Type",
      "_label": "Department"
    }
  ],
  "member": [
    {
      "type": "Person",
      "_label": "Curator"
    }
  ]
}

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Events and Activities

Patterns are not only within a single entity, but also in the way that we manage relationships between entities. While many systems link straight from one an object to its creator, for example, CIDOC-CRM and thus Linked Art instead uses an intermediate entity that represents the activity of the artist in creating the object. This enables us to associate time, place, actors, techniques, other objects and more with the creation activity, rather than needing many individual relationships.

The key participants in those different types of events are:

the Object being acted upon,
the Actors (people or organizations) that perform the activity,
the Locations at which the activity occurs,
and the Time at which it occurs.

The general pattern is to create a resource for the Activity or Event, and associate the participants with that resource. The relationships for time (timespan) and place (took_place_at) are relevant to Events that happen without the direct cause being a human action, and the relationship for the actor (carried_out_by) is added to those for human activities. The relationship to the Object is dependent on the type of Event or Activity, which are discussed in more detail in the specific sections.

There are both subclasses of Activity, such as Acquisition, Production and AttributeAssignment, and classifications associated with them to be more specific, either as a technique like glassblowing (aat:300053932), or via classified_as for more general terms like gift giving (aat:aat:300404212) to clarify the sort of Acquisition.

The pattern uses the terms and structure given in this completely artificial example:

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/event/3",
  "type": "Activity",
  "timespan": {
    "type": "TimeSpan",
    "_label": "When",
    "begin_of_the_begin": "earliest-start-datetime",
    "end_of_the_end": "latest-end-datetime"
  },
  "took_place_at": [
    {
      "type": "Place",
      "_label": "Where"
    }
  ],
  "carried_out_by": [
    {
      "type": "Actor",
      "_label": "Who"
    }
  ]
}

graph TD classDef object stroke:black,fill:#E1BA9C,rx:20px,ry:20px; classDef actor stroke:black,fill:#FFBDCA,rx:20px,ry:20px; classDef type stroke:red,fill:#FAB565,rx:20px,ry:20px; classDef name stroke:orange,fill:#FEF3BA,rx:20px,ry:20px; classDef dims stroke:black,fill:#c6c6c6,rx:20px,ry:20px; classDef infoobj stroke:#907010,fill:#fffa40,rx:20px,ry:20px classDef timespan stroke:blue,fill:#ddfffe,rx:20px,ry:20px classDef place stroke:#3a7a3a,fill:#aff090,rx:20px,ry:20px classDef event stroke:#1010FF,fill:#96e0f6,rx:20px,ry:20px classDef literal stroke:black,fill:#f0f0e0; classDef classstyle stroke:black,fill:white; O1(event3) class O1 event; O1-- type -->O1_0[Activity] class O1_0 classstyle; O2( _ ) class O2 timespan; O2-- type -->O2_0[TimeSpan] class O2_0 classstyle; O2-- _label -->O2_2("''When''") class O2_2 literal; O2-- begin_of_the_begin -->O2_3("''earliest-start-datetime''") class O2_3 literal; O2-- end_of_the_end -->O2_4("''latest-end-datetime''") class O2_4 literal; O1-- timespan -->O2 O3( _ ) class O3 place; O3-- type -->O3_0[Place] class O3_0 classstyle; O3-- _label -->O3_2("''Where''") class O3_2 literal; O1-- took_place_at -->O3 O4( _ ) class O4 actor; O4-- type -->O4_0[Actor] class O4_0 classstyle; O4-- _label -->O4_2("''Who''") class O4_2 literal; O1-- carried_out_by -->O4

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)

Time Span Details

The minimal timespan model is given above, with just the begin_of_the_begin and an end_of_the_end properties to record the beginning of the span, and the end of the span. The end of the span is not included in the span, and thus if the end_of_the_end is "1500-01-01T00:00:00Z", then the 1500 is not included, and the last mathematical moment of the last day of December 1499 is the very end.

It is very useful to have a Name for the TimeSpan that gives a human readable version of the machine readable timestamps and durations. This uses the pattern given above for naming things, and might be displayed to user directly, whereas the other properties could be used for matching a time-based search.

There are other properties for TimeSpan instances that are useful when the exact span of time is not certain.

end_of_the_begin: This property is another datetime that gives the latest possible datetime for the beginning of the span.
begin_of_the_end: This property is yet another datetime that gives the earliest possible datetime for the end of the span.
duration: This property refers to a Dimension, that describes the amount of time that the activity or event took, within the span of time. As the property defines the type of dimension, the Dimension instance does not need to be classified_as any particular Type ... it is always a duration.

Example:

An auction that occured during April 1763 over a period of three consecutive days.

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/event/4",
  "type": "Activity",
  "_label": "Auction",
  "classified_as": [
    {
      "id": "http://vocab.getty.edu/aat/300054751",
      "type": "Type",
      "_label": "Auction Event"
    }
  ],
  "timespan": {
    "type": "TimeSpan",
    "identified_by": [
      {
        "type": "Name",
        "content": "Three days within April 1763"
      }
    ],
    "begin_of_the_begin": "1763-04-01T00:00:00Z",
    "end_of_the_begin": "1763-04-28T00:00:00Z",
    "begin_of_the_end": "1763-04-04T00:00:00Z",
    "end_of_the_end": "1763-05-01T00:00:00Z",
    "duration": {
      "type": "Dimension",
      "value": 3,
      "unit": {
        "id": "http://vocab.getty.edu/aat/300379242",
        "type": "MeasurementUnit",
        "_label": "days"
      }
    }
  }
}

graph TD classDef object stroke:black,fill:#E1BA9C,rx:20px,ry:20px; classDef actor stroke:black,fill:#FFBDCA,rx:20px,ry:20px; classDef type stroke:red,fill:#FAB565,rx:20px,ry:20px; classDef name stroke:orange,fill:#FEF3BA,rx:20px,ry:20px; classDef dims stroke:black,fill:#c6c6c6,rx:20px,ry:20px; classDef infoobj stroke:#907010,fill:#fffa40,rx:20px,ry:20px classDef timespan stroke:blue,fill:#ddfffe,rx:20px,ry:20px classDef place stroke:#3a7a3a,fill:#aff090,rx:20px,ry:20px classDef event stroke:#1010FF,fill:#96e0f6,rx:20px,ry:20px classDef literal stroke:black,fill:#f0f0e0; classDef classstyle stroke:black,fill:white; O1(event4) class O1 event; O1-- type -->O1_0[Activity] class O1_0 classstyle; O1-- _label -->O1_4("''Auction''") class O1_4 literal; O2(aat:300054751) class O2 type; O2-- type -->O2_0[Type] class O2_0 classstyle; O2-- _label -->O2_3("''Auction Event''") class O2_3 literal; O1-- classified_as -->O2 O3( _ ) class O3 timespan; O3-- type -->O3_0[TimeSpan] class O3_0 classstyle; O4( _ ) class O4 name; O4-- type -->O4_0[Name] class O4_0 classstyle; O4-- content -->O4_2("''Three days within April 1763''") class O4_2 literal; O3-- identified_by -->O4 O3-- begin_of_the_begin -->O3_3("''1763-04-01T00:00:00Z''") class O3_3 literal; O3-- end_of_the_begin -->O3_4("''1763-04-28T00:00:00Z''") class O3_4 literal; O3-- begin_of_the_end -->O3_5("''1763-04-04T00:00:00Z''") class O3_5 literal; O3-- end_of_the_end -->O3_6("''1763-05-01T00:00:00Z''") class O3_6 literal; O5( _ ) class O5 dims; O5-- type -->O5_0[Dimension] class O5_0 classstyle; O5-- value -->O5_2(3) class O5_2 literal; O6(aat:300379242) class O6 type; O6-- type -->O6_0[MeasurementUnit] class O6_0 classstyle; O6-- _label -->O6_3("''days''") class O6_3 literal; O5-- unit -->O6 O3-- duration -->O5 O1-- timespan -->O3

Other Representations: JSON-LD (raw) | JSON-LD (playground) | Turtle (raw) | Turtle (styled)