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

Starting Date: 
Working Group: 

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.



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.