Issue 329: States and Situations

Starting Date: 
2017-03-23
Working Group: 
3
Status: 
Open
Background: 

Posted by Martin on 14/3/2017

CRMSci defines:


S16 State

Subclass of:         E2 Temporal Entity
Superclass of:     E3 Condition State
                          
Scope note:         This class comprises the persistence of a particular value range of the properties of a particular thing or things over a time-span.             

In First Order Logic:
               S16(x) ⊃ E2(x)

This does not clarify a lot.

I propose: This class comprises the persistence of a particular value range of the properties of a particular thing or things over a time-span.  The identity of an instance of S16 State is given by prescribing the properties and value ranges under consideration, such as "me being in my office". From this prescription of properties results the ability to observe the time-span, and possibly the spatial area, for which the specified properties hold.

SXX Situation:

I propose: This class comprises the persistence of a particular value range of the properties of a particular thing or things over a time-span. The identity of an instance of SXX Situation is given by prescribing kinds of properties and a particular time-span and possibly the spatial area. From this prescription of properties results the ability to observe thevalues of the kinds of properties which hold in the specified time-span and spatial area.

Comment: Observations typically describe situations. States need "complete observations" and are often inferred from interpolating between observed situations.

Posted by Robert Sanderson on 3/4/2017

Dear all,

One of our use cases which we are having trouble modeling with just the core CRM ontology is measurements of an object in a particular state.  For example, we would like to record the measurements of a chest with the lid open, rather than those with the lid closed.  It is the same object, just in two different states, resulting in different measurements.

The proposed scope note does certainly clarify more than the rather terse original, but if there is any feedback or guidance as to the above situation, we would be greatly appreciative.

Posted by Martin on 3/4/2017

Dear Robert,

The standard way to describe this in the CRM is to type the Dimension with the procedure:
a) Lid-open
b) Lid-closed

The Measurement procedure type can be documented by a detailed text.

In biology, one would measure "wingspan at life" and "winspan dead" of a bird, etc. 

Posted by Robert Sanderson  on 3/4/2017

Thanks Martin

If I understand correctly, both the type of dimension (height vs width) and the state of the object being measured (lid-open vs lid-closed) would both end up as external P2_has_type URIs?

_:h a Dimension ;
  label “Height of the box with the lid open” ;
  has_type <height> , <lid-open> ;
  has_value 14 ;
  has_unit <inches> .

And as the width doesn’t change depending on <lid-open> or <lid-closed> ness:

_:w a Dimension ;
  label “Height of the box with the lid open” ;
  has_type <width> , <lid-open>, <lid-closed> ;
  has_value 8 ;
  has_unit <inches> .
 
It seems a little jarring to have a core museum activity being treated with (from my perspective) little regard, compared to some of the existing distinctions made between classes with very little practical value. When the <height> and <lid-open> URIs are not understood, let alone the unit URI, the only thing the ontology actually captures is the value… and as E60 can be a string, there’s not all that much value (ha!) there either.

When the answer to all questions is “Just put it in P2”, doesn’t that give one pause that P2 is so broad as to be meaningless?

Posted by Dominic on 3/4/2017

Hi Rob,

...and this is the problem that CRM addresses. This is the problem that everyone uses different vocabularies which has made it difficult for us to integrate data. In contrast, CRM creates a semantic framework of entities for integration. The incorporation of vocab through E55 is a solution, often far better than that actually used in collection management systems that prioritise vocabularies. In a CMS we simply pick a vocabulary term from an authority to populate a field. In other words we implicitly use P2 with authority terms and we add no framework semantics to the field value pairs. e.g. Field:Dimension, Value:height,  or for the BM and others, a field label that is hard to decipher.

In CRM, Dimension is explicitly typed and the vocabulary attached to it is typed as Type -  we make use of skos through E55 Type (or skos:Concept) - which is a good place for vocabulary. If you incorporated vocabulary terms into the ontology itself then you would simply create the unmaintainable schema that CRM was created to solve. P2 is far better than having specialised vocabulary based properties. We sometimes specialise P2 in rare occasions with a property associated with a particular vocabulary term which is a one off - perhaps to differentiate types applied to the same domain.

When we applied specialisation to internal vocabularies (in particular, association vocabulary)  we realised that it led to a problem in which the vocabulary started to dominate the ontology schema (large numbers of specialisation of P2 has type) and make it unsupportable without any benefits over and above - P2_has_type >E55 (skos:Concept) > skos:prefLabel. The specialised properties we created from the vocabularies served no practical purpose when comparing vocabulary terms and probably made matters worse. I am happy to send some early examples of this.

In comparison in many base systems I see, the additional vocabulary is not even normalised and resides in the same field  - something like 20 x 10 (open) or (open lid) or some other vocabulary term. If you look at the Met's recent public data you will see that that have variations of dimension with descriptions in brackets. I think sometimes these are physical features, but appear like this,  Dimension: 30H x 10W (base); 20 x 5 (clock face) - and so on.  Dimension type, value, unit and additional type reflects CDWA (except with semantics), but in CDWA the only mandated field is "dimension description" (free text).

Vocabulary alignment is a separate issue but actually made a little easier by employing a CRM framework first.

Posted by Martin on 5/4/2017

Deasr Robert,

No, the issue is very serious. The Dimension is ultimately determined by the procedure.
"Height with box open" is not a label, but the very type of dimension. This is not a work around.
It is a substantial understanding of what a dimension is. "height" is not a dimension. It has not verifiable identity condition.

Using P2 has type must never be interpreted as "little regard", but as a need for further standardization.
But I am sorry I do not see a way to formalize in another way the potential complexity of measurement procedures. When they become comparable, they must be categorical, and then they form a type. If you cannot agree on standard measurement procedures, you cannot compare results, isn't it? At least my understanding as an experimental physicist by education;-) 

Posted by Robert Sanderson on 5/4/2017

Thanks Martin, as always

So I agree completely, but we seem to have come to different conclusions?

The way I think about the procedure is as follows:

X is an object.
At time T, X was in a state S.
When in state S, object X was measured.
The measurement activity M, performed by actor A, resulted in a dimension D, with value V and unit U.

And for the majority of these capital letters I can trivially assign CRM classes … other than state S.

X:  the box    (Man Made Object)
T:  2015-09-10 (TimeSpan)
S: upright, lid open (?????)
M: the activity (Measurement)
A: curator ( Person)
D: the Dimension with P2 of height (Dimension)
V: 14 (Number)
U: inches (Unit)

Or something like …

X a ManMadeObject ;
  has_state S ;
  has_dimension D .

S a State ;
  label “Lid Open” ;
  has_type (external Type for lid-open) ;
  timespan T .

D a Dimension ;
  has_type <height> ;
  for_state S ;
  has_value 14 ;
  has_unit U . 

(and add in the Measurement activity in the obvious way, if desired)

I agree that we should not try to catalog the vocabulary level of all possible states of all possible types of object (!!) but it seems to me (and I believe to others) like a valid concern with practical use cases and requirements, that a simple P2_has_type on the Dimension would not be sufficient to solve.

Current Proposal: 

In the 38th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 31st FRBR - CIDOC CRM Harmonization meeting, the crm-sig reviewed the  proposed by MD scope note and decided that further work and potential examples are needed for finding real instances in order to test the definition.  

HW is assigned to MD, Fransesco, George, to contact to Aldo Gangemi for opinion.
HW is assigned to CEO and Carlo for logical formulation and MD to define a property that would associate the state with the proposition set. A comment was that Property holding over time does not imply it is temporal.
The sig accepted that another linked issue is:  how to associate with belief state and intention to apply state? These seem not to be only epistemological / declarative as the above definition suggests.
Then the sig reviewed the scope note of the proposed new class about  SXX situation. 
The sig decided that before both  scope note are modified, the homework and the research should be  completed.  
The details of the discussion are listed in the minutes.(see here the related section)
 
Heraklion, April 2017

Posted by Robert on 11/4/2017

A clearer example, reversing the for_state predicate, demonstrating it follows the same pattern as parts:

X a ManMadeObject ;
  label “Chest” ;
  was_in_state S ;
  composed_of P .

S a State ;
  label “A particular state of X”
  has_type <lid-open-ness> ;
  has_timespan T ;  // when X was in this State
  has_dimension D ;

D a Dimension ;
  label “Height of X with lid open” ;
  has_value V ;
  has_unit U . 

P a PhysicalObject ;
  label “Lid of X”
  has_dimension D2 .

D2 a Dimension ;
  label “Height of Lid of X”
  has_value V2 ;
  has_unit U2 .

Reference to Issues:

Meetings discussed: