©CIDOC 2013 Event oriented analysis and modeling in documentation CIDOC CRM and FRBRoo This module provides an introduction to the CIDOC Conceptual Reference Model. Students should have completed at least one 300 level module or have some previous experience of database design. Topics covered include: Classes and properties – the basic design elements, Conceptual versus physical schemas, the event-centric model, the core CRM classes, Case studies of CRM applications.   Christian-Emil Ore Universitetet I Oslo Riksvantikvaren, 5. mai 2017

Introduction ©CIDOC 2013 In this section we will cover Facilities: Important logistical information, including Exits Agenda: What is going to happen Aims: Overall course aims Objectives: What attendees should be able to do after the course Audience: Who should be attending Course Prerequisites: Knowledge attendees are assumed to have Introductions: Individual introductions to break the ice and help the instructor understand participants expectations and experience Introduction

Agenda Introduction – Events and museums Background ©CIDOC 2013 Agenda Introduction – Events and museums Background Design Fundamentals Supported Functionality The CIDOC CRM Case Studies Performing arts, FRBRoo This is the agenda for the session.

Events and museums Internal events in a museum Acquisition Cataloguing Conservation Photographing Exhibition Storing Loan External events found in the object description Object provenance Usage Events found in the archives and in the grey literature

Chersonesos – events inside a museum https://www.google.no/maps/@44.6113696,33.491887,1059m http://www.discovering.chersonesos.org

©CIDOC 2013 Chersonesos

Event oriented analysis Objects Actors participate in Abstracts involved Events when Time-span where Places identify characterize Appellations Types

Overview over some central entities in the Chersonesos museum Actors Events Place Abstracts Person (actor) Photo classification (event) Fondi/labs/library/... (place) Controlled vocabulary (type) Book classification (event) Name (appellation) Department (actor) Preserved ruin locations (place) Find classification (event) Physical things Motif (image) (information object) Preserve structures (physical features) Find conservation (event) Subject (text) (information object) Find/artefact (physical object) Book conservation (event) Reports (text) (information object) Glass negative (physical object) Excavation (event) Drawing (physical object) Photo (shot) (event) Book/article/report (physical object) Digital photo (shot) (event) Paper card (physical object) Scan/digital repro (event) Digital (image) file (physical object) Move (sign out/in) (event)

Events inside the museum ©CIDOC 2013 Conservation report (information object) created used done by Conservation (event) person (actor) conserved in at Controlled vocabulary (types) used Move (signed out/in) (event) Conservation Lab (place) from to moved in Find classification (event) person (actor) done by classified in Move (signed out/in) (event) moved in Find/artefact (physical object) was found during Fondi/residence (place) to person (actor) done by shows Preserve structures (physical features) Excavated in shows Glass negative Condition assessm. and motif classif. (event) from Photo shot (event) Motif (image) (information object) created is carried by Preserve location (place) took place at Excavation (event) based on Book/article/report (physical object) Text + illustrations (information object) is about is carried by person (actor) directed Name (appellation) is identified by Glass negative (physical object) modified is about Digital (image) file (physical object) Scan (event) used produced Photo & motif description (information object) carries Old photo card (physical object)

Agenda Introduction – Events and museums Background ©CIDOC 2013 Agenda Introduction – Events and museums Background Design Fundamentals Supported Functionality The CIDOC CRM Case Studies Performing arts, FRBRoo This is the agenda for the session.

©CIDOC 2013 In this section we will deal with the background to the CIDOC CRM. Background

The Problem Cultural information is broad ©CIDOC 2013 The Problem Cultural information is broad Collection description: art, natural history Archives and literature: treaties, letters, poems Administration/preservation/conservation records Science & scholarship: investigation, interpretation Presentation: exhibitions, teaching, publication Cultural information is more than just a single domain. It covers:- Collection description (art, archeology, natural history….) Archives and literature (records, treaties, letters, artful works) Administration, preservation, conservation of material heritage Science and scholarship – investigation, interpretation Presentation – exhibition making, teaching, publication

The Requirement How to make a documentation standard? ©CIDOC 2013 The Requirement How to make a documentation standard? Each aspect needs its own approach Data overlap: common elements Single schema: massive Understand history from relationships Between people, events and things How to express them? How do we make a documentation standard from such a diverse range of material? Each aspect needs its own methods, forms and communication means. Data overlaps, but does not fit into a single schema We understand the lives of people, events and things from their relationships, but how do we express them?

Background Collaboration with ICOM ©CIDOC 2013 Background Collaboration with ICOM Ontology: 86 classes & 137 properties Explains hundreds of data formats Started with ISO TC46 in 2000/09 International standard ISO 21127:2014 Ongoing maintenance programme The development effort for the CRM was hosted by CIDOC an International Committee of the International Council of Museums. The CRM was submitted to ISO and became ISO Standard ISO21127:2006 in September 2006. A requirement for ISO standards is that they are maintained by a community of use. This is provide for the CRM by the CRM Special Interest Group (CRM SIG) which is hosted by CIDOC. So far the CRM has been used to explain/map more than two thousand data formats.

©CIDOC 2013 Design fundamentals

Agenda Introduction – Events and museums Background ©CIDOC 2013 Agenda Introduction – Events and museums Background Design Fundamentals Supported Functionality The CIDOC CRM Case Studies Performing arts, FRBRoo

Ontology Formalized knowledge Clearly defined Processed by ©CIDOC 2013 Ontology Formalized knowledge Possible states of domain Clearly defined Concepts (Classes) Relationships (Properties) Processed by Machines People

©CIDOC 2013 Conceptualization Acc. S.Stead

Conceptualization of classes Arena Purpose Intension Identity Substance Unity Existence Potential

Classes Category of items Individual items are “Instances” “Open” set ©CIDOC 2013 Classes Category of items Common traits Defined by scope note Intension Individual items are “Instances” “Open” set Open World Extension Name starts Exx

©CIDOC 2013 Class Scope Note

Properties Relationship between two classes Domain and Range ©CIDOC 2013 Properties Relationship between two classes Defined by scope note Intension Domain and Range Arbitrary choice Bi-directional Properties of Properties Allows typing Property A property serves to define a relationship of a specific kind between two classes. The property is characterized by an intension, which is conveyed by a scope note. A property plays a role analogous to a grammatical verb, in that it must be defined with reference to both its domain and range, which are analogous to the subject and object in grammar (unlike classes, which can be defined independently). It is arbitrary, which class is selected as the domain, just as the choice between active and passive voice in grammar is arbitrary. In other words, a property can be interpreted in both directions, with two distinct, but related interpretations. Properties may themselves have properties that relate to other classes (This feature is used in this model only in order to describe dynamic subtyping of properties). Properties can also be specialized in the same manner as classes, resulting in IsA relationships between subproperties and their superproperties. In some contexts, the terms attribute, reference, link, role or slot are used synonymously with property.   For example: “Physical Man-Made Thing depicts CRM Entity” is equivalent to “CRM Entity is depicted by Physical Man-Made Thing”. (CIDOC CRM v5.1)

Naming Properties Starts Pxx Domain to Range Range to Domain ©CIDOC 2013 Naming Properties Starts Pxx All lower case Most have bracketed part Unless symmetrical Domain to Range None bracketed part Range to Domain Bracketed part CRM has priority list for Domains First are E2 Temporal Entities

Property Scope Note ©CIDOC 2013 This is the scope note for P11 had participant (participated in) . It describes the intention of the property; its hierarchical relationships to other properties; the classes that are its domain and range; its quantification and some examples. The examples show the “E” numbers of the classes being linked.

Heirarchies Classes are arranged in a hierarchy ©CIDOC 2013 Heirarchies Classes are arranged in a hierarchy Superclass <> subclass relationship Inherit the properties of their superclass Properties are arranged in a hierarchy Superproperty <> subproperty relationship The class hierarchy in the CRM is presented in the following format:   Each line begins with a unique class identifier, consisting of a number preceded by the letter “E” (originally denoting “entity,” although now replaced by convention with the term “class”). A series of hyphens (“-”) follows the unique class identifier, indicating the hierarchical position of the class in the IsA hierarchy. The English name of the class appears to the right of the hyphens. The index is ordered by hierarchical level, in a “depth first” manner, from the smaller to the larger subhierarchies. Classes that appear in more than one position in the class hierarchy as a result of multiple inheritance are shown in an italic typeface. The property hierarchy in the CRM is presented in the following format: Each line begins with a unique property identifier, consisting of a number preceded by the letter “P” (for “property”). A series of hyphens (“-”) follows the unique property identifier, indicating the hierarchical position of the property in the IsA hierarchy. The English name of the property appears to the right of the hyphens, followed by its inverse name in parentheses for reading in the range to domain direction. The domain class for which the property is declared. The range class that the property references. The index is ordered by hierarchical level, in a “depth first” manner, from the smaller to the larger subhierarchies, and by property number between equal siblings. Properties that appear in more than one position in the property hierarchy as a result of multiple inheritance are shown in an italic typeface.

CRM Hierarchies ©CIDOC 2013 The CRM has hierarchies for both Classes and Properties

Multiple Inheritance ©CIDOC 2013 The use of multiple inheritance resolves the problem of having the same properties attached to different classes. Repetitive properties make searching difficult to resolve and make documentation difficult to compile and use.

Multiple Instantiation ©CIDOC 2013 Multiple Instantiation Item needs more classes Animal, Vegetable or Mineral Wooden handled iron knife with bone inlay Museum gains object E8 Acquisition E9 Move E10 Transfer of Custody When a real world item belongs to multiple classes, rather than create new classes which are the junction of two or more other classes we allow the item to belong to multiple classes.

Agenda Introduction – Events and museums Background ©CIDOC 2013 Agenda Introduction – Events and museums Background Design Fundamentals Supported Functionality The CIDOC CRM Case Studies Performing arts, FRBRoo

Types of Relationships (1) ©CIDOC 2013 Types of Relationships (1) Identification of items by names Observation and Classification Part-decomposition Objects, periods and places Participation of persistent items in temporal entities creates a notion of history

Types of Relationships (2) ©CIDOC 2013 Types of Relationships (2) Location periods in space-time physical objects in space Influence of objects on activities activities on objects Reference of information objects to anything

Relationships with Time ©CIDOC 2013 Relationships with Time Event time before P82 at some time within P81 ongoing throughout after “intensity” Duration (P83,P84)

©CIDOC 2013 In this section we will deal with the details of the CIDOC CRM. The CIDOC CRM

Agenda Event and museums Introduction Background Design Fundamentals ©CIDOC 2013 Agenda Event and museums Introduction Background Design Fundamentals Supported Functionality The CIDOC CRM Case Studies Performing arts, FRBRoo This is the fifth section of the agenda.

©CIDOC 2013 Core Classes These are the core classes of the CIDOC CRM.

Participation Properties ©CIDOC 2013 Participation Properties P12 occurred in the presence of (was present at) P11 had participant (participated in) P16 used specific object (was used for) P25 moved (moved by) P31 has modified (was modified by) P92 brought into existence (was brought into existence by) P33 used specific technique (was used by) P94 has created (was created by) P93 took out of existence (was taken out of existence by) P142 used constituent (was used in) P96 by mother (gave birth) P99 dissolved (was dissolved by) P143 joined (was joined by) P144 joined with (gained member by) P145 separated (left by) P146 separated from (lost member by) P14 carried out by (performed) P13 destroyed (was destroyed by) P100 was death of (died in) P124 transformed (was transformed by) P110 augmented (was augmented by) P108 has produced (was produced by) P112 diminished (was diminished by) P95 has formed (was formed by) P98 brought into life (was born) P123 resulted in (resulted from) P22 transferred title to (acquired title through) P23 transferred title from (surrendered title through) P29 custody received by (received custody through) P28 custody surrendered by (surrendered custody through) P135 created type (was created by) Specialization This shows the participation properties hierarchy.

E2Temporal Entity ©CIDOC 2013 This shows the E2 Temporal Entity hieararchy.

©CIDOC 2013 E70 Thing This shows the E70 Thing hierarchy. Note its division into material and immaterial things.

©CIDOC 2013 E39 Actor This shows the E39 Actor hierarchy. Note the presence of E21 Person which is also present in the E70 Thing hierarchy: remember multiple inheritance.

Temporal Entity- Main Properties E2 Temporal Entity Properties: P4 has time-span (is time-span of): E52 Time-Span E4 Period Properties: P7 took place at (witnessed): E53 Place P9 consists of (forms part of): E4 Period P10 falls within (contains): E4 Period E5 Event Properties: P11 had participant (participated in): E39 Actor P12 occurred in the presence of (was present at): E77 Persistent Item E7 Activity Properties: P14 carried out by (performed): E39 Actor P20 had specific purpose (was purpose of): E5 Event P21 had general purpose (was purpose of): E55 Type

©CIDOC 2013 E52 Time-Span This shows key classes and properties related to E52 Time-Span. Note the part-decompositions of E52 Time-Span, E4 period and E3 Condition State.

©CIDOC 2013 E7 Activity This shows key classes and properties related to E7 Activity. Note the inheritance of P2 has type (is type of) and P3 has note. It can also be seen that P3 has note has a property of a property P3.1 has type. This links to E55 Type; indeed all such .1 links in the CRM link to E55 Type.

©CIDOC 2013 E16 Measurement

©CIDOC 2013 E8 Acquisition

E53 Place E53 Place A place is an extent in space, determined diachronically with regard to a larger, persistent constellation of matter, often continents - by coordinates, geophysical features, artefacts, communities, political systems, objects - but not identical to A “CRM Place” is not a landscape, not a seat - it is an abstraction from temporal changes - “the place where…” A means to reason about the “where” in multiple reference systems. Examples: figures from the bow of a ship African dinosaur foot-prints in Portugal where Nelson died

©CIDOC 2013 E53 Place

©CIDOC 2013 E9 Move This shows key classes and properties related to E9 Move. Note the P54 has current permanent location (is current permanent location of) which clearly shows the museum heritage of the CRM.

E11 Modification and E12 Production ©CIDOC 2013 E11 Modification and E12 Production This shows key classes and properties related to E11 Modification and E12 Production. Note the ability to use plans and to use materials that do not become part of the E24 Physical Man-Made Thing (for instance the wax in a lost wax casting).

The CIDOC CRM Visual Content and Subject P62.1 mode of depiction E55 Type P62 depicts (is depicted by) E1 CRM Entity P67 refers to (is referred to by) E24 Physical Man-Made Thing P128 carries (is carried by) E73 Information Object P138.1 mode of depiction P65 shows visual item (is shown by) P138 represents (has representation) E84 Information Carrier E36 Visual Item E38 Visual Image

©CIDOC 2013 In this section we will show some case studies of the us of the CIDOC CRM. Case Studies

Agenda Event and museums Introduction Background Design Fundamentals ©CIDOC 2013 Agenda Event and museums Introduction Background Design Fundamentals Supported Functionality The CIDOC CRM Case Studies Performing arts, FRBRoo This is the sixth section of the agenda.

The CIDOC-CRM: Images – Visual Items From the collection of art plates at the University Library, Oslo The young Augustus [Bottom middle with ink:] Augustus // In the Vatican // [Relief in the paper: bottom right:] ENRICO VERZASCHI / EDITORE FOTOGRAFO / ROMA / VIA DEL CORSO 133 A 136 Before 1877 Black background, ¾ format

The CIDOC-CRM: Images – Visual Items P7 took place at P17 was motivated by E12 Prod. event E53 Place E21 Person Activity: “creation of the bust” ”Rome” “Octavianus” P138 represents P62 depicts P53 has former or current location E27 Man Made object E36 Visual Item E53 Place “The young Augustus” P62 depicts E27 Man Made object “Plate” P65 shows visual item “Bust” ”Vatican” E27 Man Made object “Dig.photo” P62 depicts Activity: E12 Prod. event “The plate” E21 Person “Enrico Verzas” E53 Place ”Rome” P14 carried out by P7 took place at P12 was present at P108 has produced E21 Person “May B. Guleng” E12 Prod. event “Digital repro” P55 Has current location E53 Place ”Oslo”

Some drafts Christian-Emil Ore 13.04.2017 Modelling exhibitions Sketch for mapping NM’s Primus exhibition database to CIDOC-CRM Some drafts Christian-Emil Ore 13.04.2017

Detailed model for exhibitions E55 Type “Exhibition” E35 Title “Discords. Norwegian..” E52 Time-Span “14.09.2012 - 15.01.2013” P1 is identified by P2 has type E42 Identifier “no0006525319” P4 has time-span E7 Activity “Exhibition” P7 took place at E22 Man-Made Object “Some painting” P12 was present at E42 Identifier “NMK.2008.0730” E55 Type “painting” P1 is identified by E5 Event “at display” P10 falls within E52 Time-Span “20.10.2012 - 15.01.2013” E41 Place Appellation “Oslo etc ” E53 Place “Oslo” E73 Information Object “Exhibition catalogue” P67 refers to “Catalogue entry 23” P148 is component of P14 carried out P14.1 role of resp. institution E7 Activity “Setting up exhibition” P10 falls within E40 Legal Body “National Museum” E29 Design or Procedure “Plans for the exhibition” P33 used specific technique P14 carried out P14.1 role of curator E21 Person “Curator” E65 Creation “planning & editing catalogue” P14 carried out P94 created E36 Visual Item “The motif of 6786” P65 shows visual item E7 Activity “painting” E21 Person “Hansen” P14 carried Art history info from the cataloguing system, not important here

Mapping DC to the CRM (1) Example: DC Record about a Technical Report ©CIDOC 2013 Mapping DC to the CRM (1) Example: DC Record about a Technical Report Type: text Title: Mapping of the Dublin Core Metadata Element Set to the CIDOC CRM Creator: Martin Doerr Publisher: ICS-FORTH Identifier: FORTH-ICS / TR 274 July 2000 Language: English This is the Dublin Core Record for a report about how to map DC records to the CRM.

Mapping DC to the CRM (2) ©CIDOC 2013 This is the corresponding CRM data-graph for both the explicit and implicit information in the DC record.

Mapping DC to the CRM (3) ©CIDOC 2013 This is the Dublin Core Record for this painting.

Mapping DC to the CRM (4) ©CIDOC 2013 This is the corresponding CRM data-graph for both the explicit and implicit information in the DC record. Note that is very different to the one for the report.

Conclusion CIDOC CRM Should be used as:- Transport format Compact, functional , ISO-standard Coherently integrates information at varying degrees of detail Designed for mediation of cultural heritage information Enables story telling / provenance of cultural objects Supports all information categories suggested by ObjectID Formal ontology – supports deduction systems e.g. investigation databases Should be used as:- Intellectual guide Analysis language Transport format

Summary Where it came from Properties, classes and design principles ©CIDOC 2013 Summary Where it came from Properties, classes and design principles The event centric model Use in:- Designing new systems Analysing existing systems Enabling access These are the key points covered in the course Please take a moment to review them and ask your instructor if any points are unclear

Further Reading Definition of the CIDOC Conceptual Reference Model v6 www.cidoc-crm.org Patrick Le Boeuf, Martin Doerr, Christian Emil Ore, Stephen Stead (current main editors), Definition of the CIDOC Conceptual Reference Model, November 2012 available at http://www.cidoc-crm.org/official_release_cidoc.html [accessed 5th May 2017]

Thank You Contact details: Email:- c.e.s.ore@iln.uio.no ©CIDOC 2013 Thank You Contact details: Email:- c.e.s.ore@iln.uio.no CIDOC web site:- http://network.icom.museum/cidoc/