Skip to content

Class Analysis

Introduction

This is a brief analysis of the classes in the CIDOC-CRM ontology and their practical utility. The definition of "useful" is those classes which a reasonably comprehensive producer or consumer of a CIDOC-CRM based model should be expected to understand and would make functional differentiations on. Following this definition, there are several sets of classes that can be ignored, for various reasons.

Classes to Ignore

Abstract Classes

Classes: E1, E2, E18, E19, E20, E24, E28, E63, E64, E70, E71, E72, E77, E90, E92

There are 16 classes which are not themselves directly used, however are the domain or range of useful relationships, or otherwise important distinctions within the class hierarchy. These classes likely need to stay in the ontology, but can be ignored for practical purposes. Producers should never put them into their data, and consumers can likewise expect to never see them in data. E63 and E64, the beginning and ending of existence respectively, are included in the set of abstract classes as their class-specific sub-classes are used instead. The issue that previously led to their use in data was resolved by splitting the event that caused the end of existence of a physical thing, from the actual Destruction of it, especially as the same event could destroy multiple objects.

Data Type Classes

Classes: E59, E60, E61, E62, E94, E95

The classes in the CRM that model data types (String, Number, etc) can be ignored, and indeed are ignored in the recent RDF ontologies. Instead the appropriate XSD types should be used in their place:

  • E59 Primitive Value - rdf:Literal
  • E60 Number - xsd:integer / xsd:float as appropriate
  • E61 Time Primitive - xsd:dateTime
  • E62 String - xsd:string
  • E94 Space Primitive - Use appropriate external vocabulary or format, such as WKT
  • E95 Spacetime Primitive - Use appropriate external vocabulary or format

Overly Specific Classes

There are many classes that fail the CRM's own test of individual importance. These can be broken down into clusters. The solution for all of these classes is instead to use P2 has type to refer to an external vocabulary, if needed at all.

Attribution Reification Classes: E14, E15, E16, E17

All of the subclasses of E13 Attribute Assignment can be dispensed with, and replaced with references to external vocabularies from an instance of E13. This would be more consistent with other assignments that must use E13 directly, such as attribution of an artist to a production event, the valuation of an object assigning a Monetary Amount to an object, the naming of an object assigning an Appellation and so on.

Appellation Classes: E35, E41, (E44, E45, E46, E47, E48, E49, E50, E51, E75, E82)

All of the subclasses of E41 Appellation can be dispensed, other than E42 Identifier. For the most part there is also no need to associate specific vocabulary terms to replace them. The name of a Place does not need to be an E44 Place Appellation, as this carries no additional information beyond the class of the subject of the relationship. This also prevents the modeling collision between Names (E44 and similar) and Identifiers (E42) for resources as it would be questionable which of the two classes to use. It should be noted that Identifiers are not Linguistic Objects, even if they are derived from some formal identifier scheme. This argument was agreed upon by the maintenance body for the ontology, leading to the official deprecation of E44, E45, E46, E47, E48, E49, E50, E51, E75 and E82!

E41 Appellation is also added to the list of classes to ignore, as it is not also a Linguistic Object. The number of Appellations which are not Linguistic is infinitesimal compared to the set of Linguistic Appellations, and hence we use only the Name mapping of E33_E41_Linguistic_Appellation that inherits both Appellation and Linguistic Object. This class should be used in place of E35 Title for consistency.

Entity Specialization Classes: E27, E29, E31, E32, E40, E83, E84, E96, E99

These classes (E27 Site, E29 Design or Procedure, E31 Document, E32 Authority Document, E40 Legal Body, E84 Information Carrier, E96 Purchase, E99 Product Type) have no useful distinguishing features beyond what could easily be conveyed with a Type on their respective parent classes. Authority Documents and concepts should instead use the W3C's SKOS ontology rather than attempting to model knowledge organization using CRM. Information Carriers are only distinguished from Man Made Objects by the unknowable intent of the designer. Likewise, the distinction between E73 and E31 is that instances of E31 is that subset of E73s that make propositions about reality ... which is not a very useful or tractable distinction, and a similarly imperceptible difference with E29 Design or Procedure. While Purchase does have a property (had_sales_price), it is quickly insufficient for any non-trivial transaction or description common in the art market, including multiple buyers or sellers, commissions, part payment/part exchange, reserve prices, and so on. Given the need for a Payment class, and the use of dimension to relate other prices, Purchase becomes unnecessary. E83 is added to the overly specific set of classes, as there's nothing to distinguish the creation of a Type from the creation of any other conceptual resource. The additional properties might be useful in a vocabulary management system, however that is not the purpose of this profile (nor of CRM generally, one might argue, compared to SKOS or other more appropriate ontologies).

Visual Concept Classes: E34, E37, (E38)

There is a significant overlap between the classes E34 Inscription, E36 Visual Item, E37 Mark and E38 Image. The simplest approach is to use only E36 for visual or image content, and instead of E34, instead use E33 Linguistic Object to capture inscriptions. E38 Image, while a more appealing class name, has no additional features or meaning beyond that of E36, and was officially deprecated from the ontology for this reason. Similarly, E37 has no differences with E36. The use of E33 for inscriptions is more consistent with other modeling of textual information, assuming that the inscription really contains linguistic content. For the situations where it is uncertain if an inscription is linguistic, then E36 is preferred. Note that E37 "does not intend to describe ... an individual physical embodiment", which is modeled instead as a Man-Made Object.

Curated Holding Classes: E78, E87

The E78 Curated Holding class, formerly called Collection, is the subject of much debate as to the requirements for which sets of objects can be considered collections (curated holdings) and which are sets of objects that are not curated. In order to have a consistent approach, in the absence of a separate class to represent sets in the main CRM Ontology, the preferred class for all such aggregations is Linked Art's Set. Collections can be typed as such using the well established P2_has_type relationship to an appropriate vocabulary. This also obviates the need for E87, as an overly specific subclass of Activity. Set is preferred over E19 Physical Object for consistency with sets of other types of resource, and that a Collection which was never brought together stretches the limits of the definition. It also makes it very hard to distinguish between an object with physical parts (Painting with a Frame) and a Collection with members (Paintings Collection with a Painting).

Condition Classes: E3

Not only is there no current use case for E3 Condition State, it is too complex to use in any practical way, and lacks important additional structure in the ontology to make it worth the effort. For example, there is no way to create an identity for "Box with lid open" versus "Box with lid closed" for the purposes of associating measurements or photographs.

Incomprehensible Classes: E93

E93 Presence is basically incomprehensible. As such, it has no known use cases and is impossible to know whether it is useful or not.

The definition is:

This class comprises instances of E92 Spacetime Volume, whose arbitrary temporal extent has been chosen in order to determine the spatial extent of a phenomenon over the chosen time-span.

It has been explained as the "wormhole" through space and time that an entity occupies. With complete knowledge of a universe, this might be interesting to calculate relative positions in time and space ... however we lack the supercomputing power and panopticon sensors needed to do this.

Useful Classes

The remaining classes are actively used in mappings for the known datasets.

  • E4 Period: Activities such as Productions will often only fall within a named Period
  • E5 Event: Events can be depicted by Artworks
  • E6 Destruction: The event of the destruction of an Object
  • E7 Activity: Activities of Actors and their interactions with objects is a core feature
  • E8 Acquisition: Needed for Provenance
  • E9 Move requires information that is not often tracked - the explicit activities used to move objects between locations - to be useful. In a dedicated inventory management system it could be valuable to track shipping objects between venues or moving between galleries.
  • E10 Transfer of Custody: Needed for Exhibitions
  • E11 Modification: A significant change to an object, that did not destroy it, is worthy of description
  • E12 Production: The beginning of existence of a physical thing.
  • E13 Attribute Assignment: Used for recording previously believed values
  • E21 Person: Individual people
  • E22 Human-Made Object: Objects
  • E33 Linguistic Object: Statements
  • E33 E41 Linguistic Appellation: The class for Names, recently added to the ontology
  • E36 Visual Item: Used for images and image content
  • E39 Actor: Used when it is unclear if the actor is an individual or a group
  • E42 Identifier: Identifiers of things
  • E52 Time-Span: Collects the beginning and ending of time spans
  • E53 Place: Locations
  • E54 Dimension: Dimensions of objects
  • E55 Type: References to external vocabularies, such as AAT
  • E56 Language: Used when the text of a E33 is not available, but the language is known. When the value is available, it should use the RDF language tags instead.
  • E57 Material: The type of Material that makes up an object
  • E58 Measurement Unit: The unit of measurement for a dimension value, such as inches
  • E65 Creation: Similar to Production, an Activity that creates non-physical things
  • E66 Formation:
  • E67 Birth:
  • E68 Dissolution:
  • E69 Death:
  • E73 Information Object: References to standards and external documents
  • E74 Group: Married Couples, Organizations, Workshops, etc. that can take actions as a single entity
  • E79 Part Addition: Similar to Modification, adding parts can substantially change an object
  • E80 Part Removal: And the inverse, the removal of a Part is also important for denoting samples used for conservation research
  • E85 Joining: Primarily used for recording the time of getting married
  • E86 Leaving: Primarily used for recording the dissolution of a marriage
  • E89 Propositional Object: Used very sparingly, when there is no symbolic representation that makes sense for a proposition about reality, such as the promise to pay expressed by bidding on an object at an auction, indicated only by the bidder raising their hand.
  • E97 Monetary Amount: Recording an amount of money for a price or payment
  • E98 Currency: The currency of the monetary amount

Optional Classes

After analysis of the datasets available from multiple consortia and large individual organizations, the data available does not currently require using these classes. This is not to say that they will not be useful in the future, just that they are not used by any currently known instance. In particular:

  • E26 Physical Feature is useful for describing non-man-made non-objects such as arches or caves, however none of the datasets needed this and E22 is a reasonable approximation.
  • E81 Transformation might be useful in some situations where one object is transformed into another as part of the artistic process. We typically lack the knowledge of the object prior to the documented form, however.

Appropriated Classes

E30 Right

The definition of E30 Right in CIDOC-CRM doesn't fit any actual need that has been encountered to date. The summary is that E30 is conceptual and is not contextualized by space or time, however the legal status of objects changes all the time. This is covered in more, excruciating, detail in the note below.

Given that the class is not useful as currently defined, the approach has been taken to attempt to fix that usage within the context of Linked Art, and then submit the necessary changes with evidence from the community back to the ontology maintenance agency for consideration of a revised model.

The Problem of Rights

The basic problem with E30 Right is that it is a Conceptual Object, and Conceptual Objects cannot be destroyed. While there is any carrier of the object, including the CIDOC-CRM description of it or even within someone's memory, then the concept still exists somewhere. As it cannot be written down without persisting it, it cannot be destroyed and instead it can simply pass out of all knowledge. This means that the existence of the Right is not the same as the validity of the Right: the concept of slavery in America still exists, but it is no longer legally valid. There are no terms within the CRM to express the effective dates, and the CRM-SIG clarified that the right's effectiveness would be a different sort of resource. In particular that an E30 Right "is the formulation of the right, the terms", and not whether the right had any legal standing in any jurisdiction at any point in time.

It also means that for every combination of Right+Object+Actor, there are many instances, all of which exist at the same time. The Right of Ownership of the Mona Lisa has at least one instance per Actor that ever actually owned it, and given the conceptual nature of E30, there could be many Rights for Actors that never actually owned it.

There is also no way to distinguish jurisdiction or legal code under which the right would exist, if it was ever in force. The discussion of the SIG was inconclusive as to whether a Right can be conceived by anyone, or only by Actors with the potential to make them legally enforcable even if they never do so. In other words, if I conceive of the terms of a Right of ownership, that applies to the Mona Lisa, and is possessed by myself ... is that an E30 Right, or is it just a Conceptual Object that quacks like a Right. If I cannot conceive Rights into existence, the requirements for agents that can conceive them are unknown, especially given that they're not governed by legal jurisdictions nor time.

Finally, E72 Legal Object is not the parent of Conceptual Object but instead of Symbolic Object. This means that Rights cannot be applied to ideas, yet patents can provide legal protection for those ideas. Thus even if all of the above were solved, Rights would still not cover the correct set of classes without multiple instantiation.

In summary, CIDOC-CRM lacks the expressiveness to state what is required and the current definition of E30 Right is insufficiently clear for use as currently documented in the standard. If you're still not convinced, you can read the email thread that starts here (if you dare).