Issue 329: States and Situations

ID: 
329
Starting Date: 
2017-03-23
Working Group: 
3
Status: 
Done
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 6/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 .

Posted by Martin on 11/4/2017

Dear Robert,

The point I try to make is that we are easily confusing reality with description, and partial knowledge with reconstruction of what is in between:
To my understanding, the very existence of a state is an intellectual working back from the parameters of the observation.
Whereas the reality does not change, things evolve, move, interact as they do, the definition of state thereupon changes with the definition of the properties we apply to describe these things. The objective thing is the observation, the "state" an extrapolation of the latter. To start constructing a state, which in the sequence is observed, turns to my opinion things upside down. The lid is removed in the course of the measurement in order to measure thedimension without lid, and it was not observed that the lid was removed before the observation. The latter has a completely different status, a "criminalistic one": Who put down the lid?

Once the state is produced by the activity to measure, it does not have an ontological identity of its own.
Further, all the positions the lid can have wrt the container are continuous in space. The is nothing to mark
a specific position which everybody would recognize as being distinct from all others. Only by specifying artificially a position range as "lid open", it can be described and observed. Any definition of "lid-open-ness" produces another state on the very same unambiguous reality. Measuring the container without the lid may not even require removing the lid at all.

Therefore, I'd say your solution is not as effective or necessary to describe the respective measurement.
"States" are a "treacherous" concept in a world which we all very well know is never anywhere at rest. The art of ontology engineering is using the concepts that produce the most robust identities as reference under change of context and purpose, and not what we regard as the most analytical ones. We are all tempted in this culture to try to describe the world exhaustively by atomic elements, but no one has ever succeeded to do so .

Comments? 

Posted by Robert on 11/4/2017

As in physics, you can know either the state of objects in the universe or the forces that act upon them, but never both (  The proposal takes the former as more valuable for the work that we are attempting to do – describe the state of objects in our care either for conservation purposes or for simple descriptive purposes. The CRM seems to try to model the ephemeral forces, to the exclusion of the things being acted upon.

By which I mean that E11 Modification enables the description of the transforming force (the opening of the lid) but does not allow the identification of the resulting state.

_:LidOpening a Modification ;
    has_type <lid-opening> ;
    has_modified <box> ;
    carried_out_by <conservator> ;
    had_specific_purpose _:measurement1, _:measurement2 ;
    has_timespan <time> .

_:measurement1 a Measurement ;
    measured <box> ;
    observed_dimension _:height .

_:height a Dimension ;
    has_type <height> ;
    has_value 20 ;
    has_unit <inches> .

_:measurement2 a Measurement ;
    measured <box> ;
    observed_dimension _:width .

_:width a Dimension ;
    has_type <width> ;
    has_value 15 ;
    has_unit <inches> .

We have described the forces … the actions … of lid-opening and measuring, and linked the observed dimensions … but nowhere is there an entity that IS the box with its lid open.  We need to understand the LidOpening action’s purpose in order to deduce that the measurements, although they are of the box, pertain to some un-identified state of that object. We do not have anywhere to associate even a label “Box with Lid Open” with those measurements. 

We would not want to say that the opening of the lid somehow destroyed Box-with-Lid-Closed and created Box-with-Lid-Open (e.g. E81 Transformation is not appropriate) 

Posted by Dominic on on 12/4/2017

Dear Rob, Martin
 
A Comment:
 
Dimension is defined as a measurable extent of any kind. This could be the distance between two points on an object. I think this is the way it is also described in the CRM reference, e.g. "This class comprises quantifiable properties that can be measured by some calibrated means and can be approximated by values, i.e. points or regions in a mathematical or conceptual space..."
 
Skyscrapers tend to have different types of height dimension. For example, height to tip (where there is a spire or needle), height to architectural top, height to highest occupied floor. These are all different dimension types measuring from one point to another on a building. 
 
However, on the specific example, do I want to describe a state of 'openess' or am I just opening the lid to make it more convenient to measure the different dimensions of the same box which really hasn't changed  - height to top of closed lid, height to top of open lid. As Martin mentions the box is specifically opened in order to take a particular type of dimension measurement. The example of measuring these dimensions without opening the lid at all e.g taking two measurements in a closed position and adding them together) is also an important indicator that we don't really need to get into a state and I expect for many fragile items the measurement is done in this way - practically indicating that this is simply a type of dimension. 
 
I measured my tea caddy this morning. I measured with the "lid on" to the point where the lid starts and then again to the top of the lid. I then took the lid off and measured the main body of the caddy again. It was the same measurement as when the lid was on! It is the same caddy and the measurement was not affected. When I took the lid off it didn't really change the properties particularly.  The two measurements, one to the top of the main caddy body and one to the top of the lid are two different dimensions of the same thing, like the skyscraper. If the caddy was made of wood then these measurements might change in different conditions like, for example, heat and humidity compared to freezing conditions. In this case the same dimensions might have a different result but that would be a different situation.  
    
If I could only measure a dimension on the bottom of the box by turning the box over, is this a dimension of a particular state (i.e. upside down state)? - perhaps in common usage but this isn't the same as the context we talk about. 
 
I agree that the world is constantly changing (and our understanding of it changes). However, taking a slightly different line, it is not necessary, in my opinion, to be exhaustive in order to describe a valid and useful type of totality. Some things are more useful than others. I would therefore agree that we need to be careful about the use of states as this could have quite problematic implications for which, as Martin says, we are not equipped to deal with and technology hasn't really helped with (perhaps made worse), but in any event we don't need. 
 
I think we should update the definition of S16 - its a bit thin but I think it could be updated to a better state. :-)

Posted by Robert on 12/4/2017

Hi Dominic, Martin,

Here’s two concrete use cases … how do you suggest that they be described in CRM?

1.  The object is a manuscript and for storage reasons I want to know the dimensions of it when closed (also this is the typical set of dimensions), and for exhibition planning reasons I want to know the dimensions of it when open, so I can lay it out in a display case. 

2. The object is a chest with hinged lid that sits, at rest, either completely open or completely closed. Same reasons as above – I want to display it open, but store it closed, so need to know the total height of the chest with the lid closed versus open.

Clearly there are many possible states for these objects that would result in different measurements – the height of the manuscript would depend on the number of pages turned, and the lid could be propped open to just about any height.

The difference with the skyscraper heights is that the skyscraper is not being manipulated to produce the different dimensions, they’re just heights of different parts. You could measure and record them separately and calculate the different totals.  The wooden tea caddy is also interesting regarding state … let me propose a simpler case though:

3. An umbrella can be folded into a cylinder needing length and radius dimensions, or open into (err…) an umbrella shape probably needing height, width and depth dimensions.

This case requires two _sets_ of dimensions to go together. Say that it’s a very carefully constructed umbrella where the appearance when folded is black, but the appearance when open is multi-colored. Same umbrella in two states, each of which has multiple properties beyond just dimensions.

If the P2 is the approach for the Dimension … is it also that we’d associate the same Type with a descriptive text for the color?
(And for all other features we want to describe about the same state?)

Posted by Martin on 12/4/2017

Dear Robert,

As we said, each measurement procedure defines a new Dimension type. In modern physics it became very clear that measurements in general do interact with the object itself. Therefore, do not separate the "state" from the procedure. E.g., if you measure the voltage of a battery with a Voltmeter, each Voltmeter with a different inner Ohm resistance will give you another value with very different diagnostic utility (a personal experience by the way, that puzzled me once for days!). Putting an object in a rectangular adjustable box gives you another height than the maximum spatial extent, and depending on the softness and elasticity, you may be quite puzzled by what you measure.

Therefore, we really do recommend that "lid-open" and "lid-closed" are two different types of Dimension, and that you describe with sufficient text and graphics or photos what that each type means ("is documented in"). Then, you simply measure the Dimension "lid-open" etc. I believe that defining artificial states are not of any help to do that better, but if you give me a query that you regard as relevant that can be answered only your way, can make clear how the state itself would be defined in an unambiguous way, and that this is possible for all kinds of measurements, I'll be glad to be convinced!

Posted by Steve on 13/4/2017

Robert
First thing to note is that this is not really the primary target of the CRM ie integration.
However, you could make the two different measurements that interest you for your different scenarios and then add a tag for the measurements that you need for storage and a different tag for display measurements. Of course measurements that are the same for both can be tagged with both tags. Then when you query ask for measurements that are tagged (ie p2 has type E55 Type) with the correct tag you have the measurements that you want.
Just a thought

Posted by Robert on 13/4/2017

The potential for ambiguity comes in when the pattern is adopted more generally for resources other than Dimension.  Consider this scenario:

As a conservator, I measure the [now wearing thin] chest with the lid closed, and I take a photograph of it in that state.  I then open the chest’s lid, measure the chest with the lid open and take a photograph in that state.

Without an entity to represent the state of the chest, as a data modeler, I have to use the Type as the integration point between the dimensions and the photograph.  Thus I associate the lid-open type with the Dimension (meaning that the Dimension is of the Object in the state Lid-Open), and with the Photograph (meaning that the Image depicts the Object in the state Lid-Open) so I can cross-reference with the Dimension).  If there is a type that applies to both Image and Object, it would be ambiguous which it applied to… and the same for any other resource that should be associated such as a Title, Description, etc.

How about … the ambiguity of the dimensions of a Framed Painting (Dimension P2 Framed), with a Framed photograph (Photograph P2 Framed -- meaning the photograph) of the Unframed Painting (Photograph P2 Unframed -- meaning the painting)?

{
  "@type": "ManMadeObject",
  "dimension": {
    "@type": "Dimension",
    "has_type": "x:Framed" // meaning the MMO measured in “framed” state
  },
  "has_representation": {
    "@type": "Image",
    "has_type": "x:Framed" // ambiguous whether the Image is framed or the MMO depicted is framed
  }
}

This sort of ambiguity is typically solved by having a new entity which can have dimensions and representations (and titles, and…) associated with it, which is my “State” … I don’t care about the name, and am happy to change the definition to philosophically aligned … but the current “just use P2 to tag everything” seems to either result in an infinity of interrelated Types (making them no longer usable) or likely ambiguity when applied to real world use cases.

Posted by Steve on 13/4/2017

The integration point in your first scenario is the set of activities that are done together: The measurement and the creation of the immaterial object that documents the measurement activity. It is an interesting step to move away from the object centric modelling we have done for years to event-centric modelling paradigm of the CRM.

In your second example I would suggest that there should be a clear distinction between the immaterial object that documents one part of a complex object and the physical carrier of that immaterial object. Then there is no ambiguity. The ambiguity only comes when to many distinct things are described in one cluster of attributes.

Posted by Robert on 13/4/2017

I agree… and the activity is the non-identity-changing manipulation of the object, resulting in an outcome. I can describe the activity (opening the lid, framing/unframing the painting), but I can’t describe the outcome of that activity.

And I was unclear about Photograph as MMO versus Image carried by an individual print … Images can have frames in the same way that physical carriers do. You do make my point though – there is ambiguity when multiple distinct things (the object as a persistent entity, the state of the object at a point in time) are described in one cluster of attributes.
The state of the object at a point in time is a distinct intellectual resource from the persistent entity because assertions made about it would not be true of the object as a whole, and vice versa.

Consider the trivial assertion:  The framed painting is composed of two parts, the canvas and the frame. 

Following the P2 method to the logical conclusion:

Painting a ManMadeObject ;
   is_composed_of Frame, Canvas ;
   has_dimension D ;
   has_representation I .

D a Dimension ;
  has_type Framed . // meaning the dimension describes the framed painting

I a Image ;
  has_type Framed . // meaning the image is of the framed painting

Frame a ManMadeObject ;
  has_type Framed . // meaning this part is part of the framed painting.

Now imagine you take that Frame and put it inside another Frame…

Frame a ManMadeObject ;
  has_type Framed . // meaning this frame is framed, not that the parent painting is framed

And we have resulted in an ambiguous state of what is framed.

QED?

Posted by Martin on 13/4/2017

Dear Robert,

I do not get the point. The frame has a URI, and the frame of the frame another. The aggregate painting - frame-1-frame2 has another URI from the painting-frame-1. If you measure painting-frame1, you do not measure painting, etc. How many frame-frames do you have? Do I miss something?

Anyway, any ambiguity is local to the object, a simple photo is much better than a great logical model.
This is a principle by the way: Do not overmodel details that have no bearing beyond the thing itself.
The important thing is to model relations to distant things correctly, for instance, who may have seen this object in the past, does someone keep a part of it I do not know, where may it come from? where does the technique come from?

Half of the potential CRM clients do not use it because it is too complicated, and the other half, because it is not complicated enough;-) 

Posted by Robert on 13/4/2017

Okay, my last message on the topic and I’ll move on.

By overloading P2 to describe the state of a separate resource from the one that the type is associated with, any instance in which there are multiple relationships to the resource with the Type will result in ambiguity.

The dimension is tied to the object in a 1:1 relationship, thus there is no ambiguity.  But as soon as you have 1:n, such as if there are several properties or the same property with several different resources, it’s ambiguous as to which of the related resources the type applies to.

Imagine a photograph of three paintings, two of which are framed. The image carried by the photograph is a representation of the first two paintings in their framed state, and the third in an unframed state.  So I have to record the meaningless Image P2 framed-state, unframed-state

It is certainly arguable that CRM is too complicated where it doesn’t matter, and not complicated enough where it does.

Posted by Martin on 18/4/2017

Dear Robert,

I would prefer to discuss this in a physical meeting, I do not feel in a position to write an expose in e-mail
about the whole reasoning wrt to this issue. I assume you mean this topic seriously. Then, you could help us writing a document after a meeting which clarifies these issues for others that have the same concerns.
We do have art conservation applications, and have always taken them very seriously. 

Posted by Martin on 20/9/2017

Dear All,

I suggest to redefine E3 Condition State not to be a "state" but a phase defined by structural characteristics of the object. This can be extended to phases of living beings, and configurations as Robert described.

 

 

Posted by Martin on 26/9/2017

Dear All,

I have made a list of properties in the CRM which may have a shorter time of validity than domain AND range instance. To be discussed in the meeting.

CRM Properties that may have shorter temporal validity than their domain and range.

The list is here

 

 

Posted by Martin on 8/10/2017
 
Dear All,
 
Here my final proposal:
 
 
S16 State. My new scope note is the following:
 
“This class comprises persistence of particular value ranges of 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 held. In general, there are no natural boundaries to the combination of property values under consideration in the definition of a state. Therefor this class is only epistemological in nature, describing arbitrary units of considering the world”
 
 
"Martin Doerr and Maria Daskalaki were at ICS-FORTH, Heraklion 4/10/2017 from 14:00 to 16:15"
 
SXX situation. My new scope note is the following:
 
“This class comprises the persistence of particular value ranges 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 the values of the kinds of properties, which hold in the specified time-span and spatial area. An instance of SXX Situation can be considered as a snapshot of an instance of SXX State defined by the property values observed in the respective situation. In other words, any instance of SXX Situation can be expanded into a State describing the maximal extent in time and space for which the combination of property values observed in a particular situation held. In general, there are no natural boundaries to the combination of kinds of properties, the space and the time-span under consideration in the definition of a situation other than the interest and ability of an observer. Therefor this class is only epistemological in nature, describing arbitrary units of considering the world”
 
Example:
 
"Martin Doerr and Maria Daskalaki were at ICS-FORTH, Heraklion 4/10/2017 15:22:05"
 
"Martin Doerr and Maria Daskalaki and George Bruseker were at ICS-FORTH, Heraklion, in the Stelios Orphanoudakis Room at 4/10/2017 14:44"
Posted by Martijn van Leusen on 9/10/2017
 
Hi Martin,
 
just so that I'm sure I understand the distinction between State and Situation: when I conduct a field survey of a particular field, which happens to be ploughed during that visit, would that be its State or its Situation? 
Posted by Martin on 9/10/2017
 
On 10/9/2017 3:34 PM, van Leusen, P.M. wrote:
> Hi Martin,
>
> just so that I'm sure I understand the distinction between State and Situation: when I conduct a field survey of a particular field, which happens to be ploughed during that visit, would that be its State or its Situation?
The Situation: When I saw it on 23/11/15, it was ploughed. The State: It has been ploughed from 25/9/15, and sewed in in 10/3/16. The event: It was ploughed 25/9/15 by the farmer.
Posted by Martin on 9/10/2017
 
On 10/9/2017 9:13 PM, martin wrote:
> On 10/9/2017 3:34 PM, van Leusen, P.M. wrote:
>> Hi Martin,
>>
>> just so that I'm sure I understand the distinction between State and Situation: when I conduct a field survey of a particular field, which happens to be ploughed during that visit, would that be its State or its Situation?
> The Situation: When I saw it on 23/11/15, it was ploughed. The State: It has been ploughed from 25/9/15, and sewed in in 10/3/16. The event: It was ploughed 25/9/15 by the farmer.
Sorry: sown , not sewed

In the 39th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 32nd FRBR - CIDOC CRM Harmonization meeting, the sig reviewed and accepted Martin’s proposal  for state and situation and the need to create properties for state and situation based on the given definitions. Situation would be the range of an observation. 

Decision on these: 
- Martin will continue to look at models of situations together with temporality of property
- The class situation will go to CRMinf
 
Heraklion, October 2017

In the 40th joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 33nd FRBR - CIDOC CRM Harmonization meeting, the crm-sig  decided to postpone  the HW assignment until observations will have been modelled more explicitly in CRMSci and will have been discussed sampling issues  relative to   survey extension to CRM proposed by Martijn van Leusen.  Also it is decided this text to be saved as accepted as a background doc 

Cologne, January 2018

Outcome: 

Note by the editors: 

The issue is closed on the grounds of it being superseded by Issue 425 (definition of I11 Situation for CRMinf). 

 

March 2023