Baseline Patterns

Table of Contents


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:

Example: The simplest possible object.

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

JSON-LD (Raw) | JSON-LD (Playground) | Turtle (Raw) | Turtle (Styled)

Types and Classifications

The CRM is a framework that must be extended via additional vocabularies and ontologies to be useful. The provided mechanism for doing this is the predicate crm:P2_has_type, mapped as classified_as in the model. The semantics of crm:P2_has_type are closer to "is classified as" or perhaps "has semantic tag", rather than "is an instance of the class" like rdf:type (mapped as type in the model). The type field is used for CRM defined classes, and as few other extensions as possible.

While any external vocabulary of terms can be used, the Getty Vocabularies are used whenever possible for consistency. The set of terms that have been identified as useful from those vocabularies is listed in the community best-practices.

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

Example:

The type of the object (an instance of HumanMadeObject) is a painting (aat:300033618):

Example: An object is a painting and a work of art.

{
  "@context": "https://linked.art/ns/v1/linked-art.json", 
  "id": "https://linked.art/example/object/14", 
  "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": "Artwork"
    }
  ]
}

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 as an item of interest also have at least one specific name. This 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 language, and can have the Linguistic features of the model associated with them, such as being in a 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/15", 
  "type": "HumanMadeObject", 
  "_label": "Painting: Pasture and Sheep", 
  "identified_by": [
    {
      "id": "https://linked.art/example/name/18", 
      "type": "Name", 
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300404670", 
          "type": "Type", 
          "_label": "Primary Name"
        }
      ], 
      "language": [
        {
          "id": "http://vocab.getty.edu/aat/300388277", 
          "type": "Language", 
          "_label": "English"
        }
      ], 
      "content": "Pasture and Sheep"
    }
  ], 
  "classified_as": [
    {
      "id": "http://vocab.getty.edu/aat/300033618", 
      "type": "Type", 
      "_label": "Painting"
    }, 
    {
      "id": "http://vocab.getty.edu/aat/300133025", 
      "type": "Type", 
      "_label": "Artwork"
    }
  ]
}

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/16", 
  "type": "HumanMadeObject", 
  "_label": "Painting: Pasture and Sheep", 
  "identified_by": [
    {
      "id": "https://linked.art/example/identifier/4", 
      "type": "Identifier", 
      "content": "P1998-27", 
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300312355", 
          "type": "Type", 
          "_label": "Accession Number"
        }
      ]
    }, 
    {
      "id": "https://linked.art/example/name/19", 
      "type": "Name", 
      "content": "Pasture and Sheep", 
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300404670", 
          "type": "Type", 
          "_label": "Primary Name"
        }
      ]
    }
  ], 
  "classified_as": [
    {
      "id": "http://vocab.getty.edu/aat/300033618", 
      "type": "Type", 
      "_label": "Painting"
    }, 
    {
      "id": "http://vocab.getty.edu/aat/300133025", 
      "type": "Type", 
      "_label": "Artwork"
    }
  ]
}

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 Linguistic Object 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:

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:300010358) statement:

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

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:

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/18", 
  "type": "HumanMadeObject", 
  "_label": "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": "Artwork"
    }
  ], 
  "made_of": [
    {
      "id": "http://vocab.getty.edu/aat/300015045", 
      "type": "Material", 
      "_label": "watercolors"
    }
  ], 
  "part": [
    {
      "id": "https://linked.art/example/object/18/part/1", 
      "type": "HumanMadeObject", 
      "_label": "Canvas Support", 
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300014844", 
          "type": "Type", 
          "_label": "Support"
        }
      ], 
      "made_of": [
        {
          "id": "http://vocab.getty.edu/aat/300014078", 
          "type": "Material", 
          "_label": "canvas"
        }
      ]
    }
  ]
}

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:

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/8", 
  "type": "Group", 
  "_label": "Paintings Department", 
  "classified_as": [
    {
      "id": "http://vocab.getty.edu/aat/300263534", 
      "type": "Type", 
      "_label": "Department"
    }
  ], 
  "member": [
    {
      "id": "https://linked.art/example/person/19", 
      "type": "Person", 
      "_label": "Curator"
    }
  ]
}

JSON-LD (Raw) | JSON-LD (Playground) | Turtle (Raw) | Turtle (Styled)