Issue 438: proposal to replace E18 isa E92 and E4 isa E92 with properties

Starting Date: 
2019-10-15
Working Group: 
3
Status: 
Open
Background: 

Following up issue 326

Posted by Christian Emil on 15/10/2019

Dear all,

This email describes the issue of replacing the  E18 isa E92 Spacetime volume  and E4 isa E92 Spacetime volume with properties. The main reason to do so is  based on the observation that for most of the (potential) users of CRM it is too abstract to identify a thing with its spacetime volume.
Below I start with a soft introduction and then present the issue(s). I have given links to documents which can be downloaded. These are ppt with 4 possible cases (case 3 is what is suggested) and  concordance of the phrase “spacetime volume” in the CRM document.
 ppt: http://www.edd.uio.no/nedlasting/cidoc-crm/STV_suggested_changes.ppt

concordance: http://www.edd.uio.no/nedlasting/cidoc-crm/kwic_spacetime_volume.txt

********

The concept of spacetime volume is taken from physics. The idea is intuitive.  Every physical thing has a volume, that is, occupies space (check your cupboard).  When a cup is moved  in the kitchen its volume will move relative to the kitchen floor and walls. Its place in the kitchen will depend on the time of the day. If the cup’s movement is registered in a 3D model, say every second , its whereabouts will look like some strange geometric figure. If the cups movement from it production to it is broken beyond recognition by a steamroller, this can also be a figure depending on time. So for any identifiable thing there will be a unique volume from it gets it identity until the identity is lost. This can be seen as a volume in a 4 dimensional space (X,Y,Z,T),  that is, a 3D figure evolving over time. It should also be evident that such a 4D volume is unique for a physical thing. Two things describing the exact same volume during their lifetime can be considered the same thing.

Instances of the class E92 Spacetime volume (STV among friends) are such 4 dimensional volumes.  It is a handy abstraction which makes it possible to talk about a ship’s travel  etc.  The one to one relation between an identifiable physical thing and a spacetime volume is the reason to make E18 Physical thing a subclass of E92 Spacetime Volume, that is, every instance of E18 Physical thing _is_ an instance of E92 Spacetime volume. However, practical experience has shown that this is considered to be very abstract for most users of CRM.  We have observed confusions and misinterpretations. It is reported to be very difficult to teach CRM with this construct. It is more intuitive to say that a physical thing has a spacetime volume than to say that a physical thing is a spacetime volume.

Proposal 1: Replace E18 isa E92 Spacetime volume with a property PXXX:

Pxxx has defining STV (is defining STV of) 

Domain:              E18 Physical Thing

Range:                 E92 Spacetime Volume

Quantification: one to one, necessary  (1,1:0,1)

In the current model we also have E4 Period isa E92 Spacetime volume. This is more intuitive since something happening has a time and a place but no physical substance. On the other hand, it is arguable that two events may happen at the same time and same place. A simple example technical example are instances of E8 Acquisition and E10 Transfer of Custody, which may happen at the same time and place. More generally and perhaps more philosophically, when documenting the past, it is not uncommon to interpret something happing at a place and time as more than one event. If one accept this, then an instance of E92 Spacetime Volume is not in one to one relation with an instance of E4 Period, two instances of E4 Period can share an instance of E92 Spacetime Volume

Proposal 2:  Replace E4 isa E92 Spacetime volume with a property Pyyy

Pyyy has defining STV (is defining STV of) 

Domain:              E4 Period

Range:                 E92 Spacetime Volume

Quantification: one to one, necessary  (1,1:0,n)

This construct will solve the problem of P4 vs P160.

Consequences for the current CRM (document):

There only two properties that are a sub property of a property with STV as domain or range:

1)      P46 is composed of (forms part of)

2)      P156 occupies (is occupied by)

P46 needs an adjustment of the FOL-definition (which also has an error as it is today). P156 is ok as it is (although its not so easy to understand)

The scope not of the two classes E4 Period and P18 Physical thing has to be adjusted. There is a almost identical paragraph which can be deleted and reused in the scope note for the new properties.

E18 Physical Thing:

We model E18 Physical Thing to be a subclass of E72 Legal Object and of E92 Spacetime Volume. The latter is intended as a phenomenal spacetime volume as defined in CRMgeo (Doerr and Hiebel 2013). By virtue of this multiple inheritance we can discuss the physical extent of an instance of E18 Physical Thing without representing each instance of it together with an instance of its associated spacetime volume. This model combines two quite different kinds of substance: an instance of E18 Physical Thing is matter while an instance of E92 Spacetime Volume is an aggregation of points in spacetime. However, the real spatiotemporal extent of an instance of E18 Physical Thing is regarded to be unique to it, due to all its details and fuzziness; its identity and existence depends uniquely on the identity of the instance of E18 Physical Thing. Therefore this multiple inheritance is unambiguous and effective and furthermore corresponds to the intuitions of natural language.

E4 Period:

We model E4 Period as a subclass of E2 Temporal Entity and of E92 Spacetime Volume. The latter is intended as a phenomenal spacetime volume as defined in CIDOC CRMgeo (Doerr and Hiebel, 2013). By virtue of this multiple inheritance we can discuss the physical extent of an instance of E4 Period without representing each instance of it together with an instance of its associated spacetime volume. This model combines two quite different kinds of substance: an instance of E4 Period is a phenomena while an instance of E92 Spacetime Volume is an aggregation of points in spacetime. However, the real spatiotemporal extent of an instance of E4 Period is regarded to be unique to it due to all its details and fuzziness; its identity and existence depends uniquely on the identity of the instance of E4 Period. Therefore this multiple inheritance is unambiguous and effective and furthermore corresponds to the intuitions of natural language.

 

 

Posted by Robert Sanderson on 15/10/2019

As the spacetime volume that is Rob, and the spacetime volume that is the next SIG meeting will unfortunately not intersect, I’d like to register my full support for this change, including case 3 as the preferred solution, in advance!

Posted by martin on 16/10/2019

Dear Christian-Emil, all,

This is a very good start.
In order to understand the problem, we need to have an overview of all properties inherited from STV, those raised to STV, and see the long-paths that will be consequence of the indirection, as well as ambiguities of choices of representation in time and space for those properties we have merged after the IsA.

Posted by Øyvind Eide  on 16/10/2019

I will not be there either, and even if I love STVs to the extent that my home wifi is called SpaceTimeVolume, I full support this change and also support case 3. 

To me some of the quantifications looks in conflict with the text but this might be just my evening brain and even if I happen to be right I am sure the details will be checked at the meeting — if after the meeting they still look strange to me I will address the issue with specific questions.

Have a nice meeting!

 

Posted by Christian Emil on 16/10/2019

This is the list of properties with STV as domain or range and their sub properties. The task will be to check the meaning of these properties  when the domain and range are moved down the class hierarchy. Since we keep the long paths via STVs, it seems to be a question of (re)establish properies as shortcuts of the long STV-based paths. 

ID Title Domain Range
P132 overlaps with E92 Spacetime Volume E92 Spacetime Volume
P9    -   consists of (forms part of) E4 Period E4 Period
P10    -   falls within (contains) E92 Spacetime Volume E92 Spacetime Volume
P166    -   -   was a presence of (had presence) E93 Presence E92 Spacetime Volume
P46    -   is composed of (forms part of) E18 Physical Thing E18 Physical Thing
P56    -      -   bears feature (is found on) E19 Physical Object E26 Physical Feature
P133 is separated from E92 Spacetime Volume E92 Spacetime Volume
P160 has temporal projection E92 Spacetime Volume E52 Time-Span
P164    -    during (was time-span of) E93 Presence E52 Time Span
P161 has spatial projection E92 Spacetime Volume E53 Place
P156    -   occupies E18 Physical Thing E53 Place
P167 was at(was place of) E93 Presence E53 Place
P168 Place is defined by (defines place) E53 Place E94 Space primitive
P169 defines spacetime volume (spacetime volume is defined by) E95 Spacetime Primitive E92 Spacetime Volume

 

Table 1 Properties with STV as domain or range and their sub properties.

 

 

Current Proposal: 

In the 45th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 38th FRBR – CIDOC CRM Harmonization meeting, the sig accepted to keep the E4 isA E92, replace the E18 isA E92 with a property and explore the resulting consequences for the model by this change. The relations declared in the Case 2, will appear in the next CRM official version (v.7.0). the minutes of this discussion can be found here.

 

Heraklion, October 2019