[Crm-sig] issue 336 and spacetime volumes

Francesco Beretta francesco.beretta at cnrs.fr
Thu Mar 21 00:49:40 EET 2019

Dear Martin, all,

Applying the principles we generally use in conceptual modelling, a 
model of « CRM top hierarchy and space&time » like the one you’ll find 
in attachment seems plausible. I’ll comment the slides from the top to 
the bottom, for the sake of clarity.

Let’s start from the basic modelling principles Martin expressed on 
9/3/2019 :

« In the first place, E2 has a substance of "phenomena" something 
"becoming" "changing" "moving", "interacting". In addition, we interpret 
it now also more statically as including a sort of maintaining 
something. It is _necessarily connected_ to some "things" on which such 
interactions, changes or temporary, non-essential formation of 
properties happen, but we have seen so far no good general way to 
describe the ways of involvement at the level of E2.

E92 is nothing of that kind. It is just spacetime, the generalized space 
in which we live and think, not what is there not what happens there. It 
is just a "where". It is further a volume in that space, i.e., it must 
have some inner part, and a surface as fuzzy as it may be, and a way to 
identify it. »

As you can see in the attached slides (the more relevant being the first 
one), E77 Persistent Item and E2 Temporal entity are ‘phenomenal’ 
classes. In contrast, Place, Time-Span, STV, Dimension are ‘regions’ in 
a reference ‘space’, be this spatial, temporal or quantitative.

As we know, E77 Persistent Item instances are in principle not directly 
related to time (using properties) but they live in time : we model this 
using temporal entities related to these Persistent item instances « on 
which such interactions, changes or temporary, non-essential formation 
of properties happen » (Martin). Temporal entities are phenomena we 
usually perceive or observe in relation to some persistent item, be this 
a conceptual or physical one. A very general property ‘Pxx 
involves/concern’ would clearly express this basic phenomenon : 
persistent items live in time (and space) and we model this using 
temporal entities (Events for dynamic moments, Phases for static 
characteristics, both phenomenal).

E2 Temporal entities (having a phenomenal substance) are projected in a 
region in time and these contribute to define their identity (we stress 
here the phenomenal aspect, not the epistemological). This projection in 
time is modelled as an instance of E52 Time span.

Insofar as we are modelling conceptually we need to keep these two 
classes (E2, E52) separate in the model regardless their cardinality 
because they are expressions of significantly different substance. The 
implementation in an information system, if the (1,1;1,1) cardinality is 
chosen, can merge the two classes but this is about implementation not 
about the conceptual model : here we must keep both classes separate for 
the sake of clarity and consistency with the identity principles.

How do we model, in the next step, projection in physical space ? The 
crucial question is: are there any temporal entities without such a 
projection ? If yes (e.g. I2 Belief), we have two ways of modelling 
this : 1) with a (*1*,1:1,1/n) cardinality for /P7 took place at 
/associating it to E4 Period (slide 1) or 2) with a (*0*,1:1,1/n) 
cardinality associating it directly to E2 Temporal entity (slide 2). 
This second model would imply in some cases there is not a projection of 
a Temporal entity instance in a region in physical space, although 
fundamentally there can be one. In the perspective of simplicity, the 
second solution would be the preferable one. But for the sake of 
consistency with earlier versions of the CRM and for making the 
conceptual model more clear and explicit, the first modelling choice 
(using E4 Period) would probably be the best one.

Insofar as it has a projection in time and space, an instance of E4 
Period (which is composed by Events and Phases) is associated to a 
Spacetime Volume. As phenomenon, an instance of E4 Period makes a STV to 
be virtually present : if we want to make this explicit, and especially 
if we want to explicitly associate a time span with a place, providing 
this association with a specific identity, independently from any E4 
Period instance, we need a STV instance (and the E92 STV class). For 
this we would then need to have a property /Pxx has //spacetime//volume/ 
(1,1:1,1/n) modelled similarly to P4/P7.

Incidentally, for all these properties we have to decide if the maximum 
cardinality on the side of a Exx Region subclass has to be 1 or n. If we 
choose ‘n’ we provide a specific identity to the Exx Region instance, 
independently from the identity of the related Phenomenal Class 
instance. E.g. different E4 Period instances could be located in the 
same spatial region, i.e. E53 Place.

If we think an autonomous identity of E92 STV is not given, and time and 
space, and virtual spacetime volume (= time + space) are always related 
to at least one temporal entity or period (i.e. to a phenomenon), then 
we could deprecate the E92 Spacetime Volume class and use E4 Period 
instead as common point of meeting of time and space, in the phenomenal 
sense. A E53 Place being the ‘surface’ of a phenomenon during a given 
timespan. E93 Presence (as subclass of S4 Observation?) would be an 
intersection of time and space in the epistemological sense, providing 
an arbitrarily defined snapshot of a Period. As such, it would have a 
specific identity and would be modelled as a distinct class.

This way of modelling seems to be more robust and consistent with the 
domain : we model phenomena in cultural life associated to persistent 
items, phenomena having a projection in time and space, not 
time/space/STV as such, independently from phenomena. Also, this would 
avoid the issue of the redundancy of properties which was the starting 
point of this discussion : P4/P160 ; P7/P161. For these reasons I would 
advocate to abandon the E92 class, knowing that it is virtually present 
in E4 Period as its implicit spatio-temporal surface.

The last issue I see is the one related to modelling of a STV for a E18 
Physical thing. The /difference/ between the volume occupied by a 
physical body as such, be it moving or not, and the volume occupied by 
the body moving from one place to another, is not clearly defined if you 
make a E18 Physical thing a subclass of E92 Spacetime volume. In the 
well known case of the vessels’ fight in Trafalgar, the TSV of the fight 
can be treated as projection in time and space of the whole event, using 
P4/P7 and, if needed, the correspondent declarative properties : we have 
a phenomenon, the fight (E5 as temporal entity), and a document driven 
approximation of its STV using in SP10/SP2 (without necessarily the need 
of using a E92 Spacetime volume/SP7 STV classes as separated entities 
with an own identity).

On the one side, Nelson’s ship itself, as an instance of E18 Physical 
thing, would have a time related volume (STV), even being moored in a 
port without moving, and the wreck of it on the seafloor has a STV 
different from the navigating ship. But this is not about the position 
in the fight but about the volume of the Persistent item instance itself 
(this volume being a E53 Place instance, as specific « extent in 
space » : the 3D ‘surface’ of the ship) and can be modelled using a Exx 
Volume/Surface class, modelled as subclass of E3 Condition state. E3 
would be modelled directly as subclass of E4 Period or as subclass of 
the new Exx Phase class, expressing « phases during the existence and 
evolution of an instance of E18 Physical Thing characterized by a 
substantial appearance » (Martin). In this case the ‘appearance’ is the 
volume of the physical thing understood as a « surface » with a precise 
form. The movement of the ship, on the other side, can be modelled as an 
instance of E5 Event and associated to the fight E5 Event instance using 
P9 consists of.

This approach would allow to have a concise and straightforward model 
and avoid inconsistency with the CRM well established way of defining 
identity criteria, which isn’t the case if E4 Period and E18 Physical 
thing are modelled as subclasses of E92 Spacetime Volume (insofar as 
this is not a phenomenon but a ‘region’ in space and time).

All the best


Le 20.03.19 à 14:19, Martin Doerr a écrit :
> Dear Christian-Emil,
> I am not sure this is a good idea. Moving time-span properties onto E2 
> just washes about the fact that the temporal projection of E2 and of 
> E92 are equivalent. If we make the paths more dissimilar, we just hide 
> that there are two alternative ways to formulate it. If the formal 
> rules of KR do not foresee the case, we just change the cardinality of 
> P4 / P160 to (1,1:0,n) or (1,1:0,2).
> I am hesitating to propose a common superclass of E92 and E2 just to 
> have one domain for P4/P160. It becomes an extremely abstract thing.
> Opinions?
> Best,
> Martin
> On 3/19/2019 1:19 PM, Christian-Emil Smith Ore wrote:
>> Hi Dan, all
>> The recommended way to model historical periods is as instances of E4 
>> Period. This recommendation is older than the introduction of E92.
>> The current model with E2 Temporal Entity, E52 Time-Span and E92 STV 
>> is not optimal and E92 is not the reason eventhough it is pretty 
>> abstract. In my opinion, E52 Time-Span is redundant and can be 
>> replaced by E2 Temporal Entity with an adjusted scope-note and change 
>> the domain of
>> P79 beginning is qualified by: E62 String
>> P80 end is qualified by: E62 String
>> P81 ongoing throughout: E61 Time Primitive
>> P82 at some time within: E61 Time Primitive
>> P83 had at least duration (was minimum duration of): E54 Dimension
>> P84 had at most duration (was maximum duration of): E54 Dimension
>> P160 has  temporal projection
>> P86 falls within (contains): E52 Time-Span can be replaced by P117 
>> occurs during (includes): E2 Temporal Entity
>> If E52 is removed the property P160 has temporal projection should be 
>> an injection into E2 and have the cardinality (1,1:0,1)
>> (in any case: P78 is identified by (identifies) should be deprecated 
>> since E49 Time Appellation is already deprecated.)
>> See also 
>> http://cidoc-crm.org/sites/default/files/issue%20326%20overview%20and%20thought.pptx 
>> for a graphical overview.
>> Best,
>> Christian-Emil
>> ********
>> E2 Temporal Entity:
>> This class comprises all phenomena, such as the instances of E4 
>> Periods, E5 Events and states, which happen over a limited extent in 
>> time.  This extent in time must be contiguous, i.e., without gaps.  
>> In case the defining kinds of phenomena for an instance of E2 
>> Temporal Entity cease to happen, and occur later again at another 
>> time, we regard that the former E2 Temporal Entity has ended and a 
>> new instance has come into existence. In more intuitive terms, the 
>> same event cannot happen twice.
>> In some contexts, these are also called perdurants. This class is 
>> disjoint from E77 Persistent Item. This is an abstract class and has 
>> no direct instances. E2 Temporal Entity is specialized into E4 
>> Period, which applies to a particular geographic area (defined with a 
>> greater or lesser degree of precision), and E3 Condition State, which 
>> applies to instances of E18 Physical Thing.
>> *********
>> E52 Time-span
>> This class comprises abstract temporal extents, in the sense of 
>> Galilean physics, having a beginning, an end and a duration.
>> Time Span has no other semantic connotations. Time-Spans are used to 
>> define the temporal extent of instances of E4 Period, E5 Event and 
>> any other phenomena valid for a certain time. An E52 Time-Span may be 
>> identified by one or more instances of E49 Time Appellation.
>> Since our knowledge of history is imperfect, instances of E52 
>> Time-Span can best be considered as approximations of the actual 
>> Time-Spans of temporal entities. The properties of E52 Time-Span are 
>> intended to allow these approximations to be expressed precisely.  An 
>> extreme case of approximation, might, for example, define an E52 
>> Time-Span having unknown beginning, end and duration. Used as a 
>> common E52 Time-Span for two events, it would nevertheless define 
>> them as being simultaneous, even if nothing else was known.
>> Automatic processing and querying of instances of E52 Time-Span is 
>> facilitated if data can be parsed into an E61 Time Primitive.
>> *********
>> ________________________________________
>> From: Crm-sig <crm-sig-bounces at ics.forth.gr> on behalf of Dan Matei 
>> <danmatei50 at gmail.com>
>> Sent: 19 March 2019 09:27
>> To: crm-sig at ics.forth.gr
>> Subject: Re: [Crm-sig] Space time volumes
>> Hi fiends,
>> On Mon, 18 Mar 2019 at 19:20, Martin Doerr <martin at ics.forth.gr> wrote:
>>> Nevertheless, we used the term informally in the CRM. We could name 
>>> E92 as "abstract".
>> For me, some E92 are not abstract. E.g. I instantiate "Byzantine
>> Period" (it is somwhat difficult to place it in South America :-) :
>> <#ByzantinePeriod> <isA> <crm:E92_Spacetime_Volume>
>> <#ByzantinePeriod> <crm:P160_has_temporal_projection> <330-1700>
>> <#ByzantinePeriod> <crm:P161_has_spatial_projection> <#EsternEurope>
>> <#ByzantinePeriod> <crm:P161_has_spatial_projection> <#Levant>
>> <#ByzantinePeriod> <crm:P161_has_spatial_projection> <#NorthAfrica>
>> Also:
>> <#BronzeAge1> <isA> <crm:E92_Spacetime_Volume>
>> <#BronzeAge1> <crm:P2 has_type> <#BronzeAge-Concept>
>> <#BronzeAge1> <crm:P160_has_temporal_projection> <p?1>
>> <#BronzeAge1><crm:P161_has_spatial_projection> <#JapaneseIslands>
>> <#BronzeAge2> <isA> <crm:E92_Spacetime_Volume>
>> <#BronzeAge2> <crm:P2 has_type> <#BronzeAge-Concept>
>> <#BronzeAge2> <crm:P160_has_temporal_projection> <p?2>
>> <#BronzeAge2><crm:P161_has_spatial_projection> <#Scandinavia>
>> Should I worry ?
>> Dan
>> _______________________________________________
>> Crm-sig mailing list
>> Crm-sig at ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>> _______________________________________________
>> Crm-sig mailing list
>> Crm-sig at ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20190320/8e6ed28b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: issue 326 Francesco_20190320.pdf
Type: application/pdf
Size: 47017 bytes
Desc: not available
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20190320/8e6ed28b/attachment-0001.pdf>

More information about the Crm-sig mailing list