Dear Wolfgang,

Good question!

In order not to confuse things, we cannot make stements about the future, in whatever form.

The question about "ongoing" STVs and Temporal Entities of whatever kind, be it physical things, periods of events, needs a different treatment. The important information to distinguish is, if a temporal outer limit is "after the reported observation", or ends with it. Currently we cannot distinguish both cases. In the past, I had proposed a sort of "infinite" interval, but I think that does not work. May be we should use a sub or superproperty of P82b and P81b, a sort of "*P82b_before_end_of_the_end*" to report that up to this date, the STV or E2 needs not have ended, and "*P81b_before_begin_of_the_end*" to report that up to this date, the STV or E2 has not yet ended.

Any more recent report would supersede the previous one.

The problem with P133 as I see it is, that it is a negation, which requires a complete observation, or other physical constraints. That is not a problem per se, but noteworthy. It is prone to non-monotonic update.

Indeed, my body's STV was "spatiotemporally separated from" the state of Japan until 1983, when I went there. Only two ongoing STVs may overlap in the future, but this can be trivial.

For many instances of STV, complete observation is not a problem, therefore the property appears to be justified.

So, I think the FOL is correct, and we have to discuss this generally under negative knowledge.

On 12/17/2022 11:58 AM, Wolfgang Schmidle via Crm-sig wrote:
Dear All,

Since we want to deprecate properties such as "has current owner" where true statements 
may become wrong in the future, I was wondering about P133 "spatiotemporally separated 
from". If both STVs are still ongoing, such as the STVs defined by two objects that still 
exist, I think a P133 statement that is correct as of now may become wrong in the future, too. How 
to deal with this? Or is it unlikely that this situation will occur in practice?


If this property holds for two instances of E92 Spacetime Volume then it cannot 
be the case that P132 spatiotemporally overlaps with also holds for the same 
two instances.
P133(x,y) ⇒ ¬P132(x,y)

Furthermore, there are cases where neither P132 spatiotemporally overlaps with 
nor P133 is spatiotemporally separated from holds between two instances of E92 
Spacetime Volume. This would occur where only an overlap of the fuzzy 
boundaries of the two instances of E92 Spacetime Volume occurs and no other 
evidence is available.
(∃x,y) [E92(x) ∧ E92(y) ∧ ¬P132(x,y) ∧ ¬P133(x,y)]
If there are two concrete x and y that are not ongoing and where ¬P132(x,y) ∧ ¬P133(x,y) is true, will it always stay true or can it also become wrong in the future, for example when more evidence becomes available?
See above 😁


The P132 scope note contains the same statements, so the axioms would need to 
be repeated for P132:
P132(x,y) ⇒ ¬P133(x,y)
(∃x,y) [E92(x) ∧ E92(y) ∧ ¬P132(x,y) ∧ ¬P133(x,y)]

Would it make sense to say something like this in the P132 scope note instead: "For 
the relationship with P133 see there"?

Sure, if that helps.
This property is not transitive.
(∃x,y,z) [E92(x) ∧ E92(y) ∧ E92(z) ∧ P132(x,y) ∧ P132(y,z) ∧ ¬P132(x,z)]

(∃x,y,z) [E92(x) ∧ E92(y) ∧ E92(z) ∧ P133(x,y) ∧ P133(y,z) ∧ ¬P133(x,z)]


P133(x,y) ⇒ P133(x,y)
This seems to be an oversight? (Also in P132.)
What is the oversight?

Best,

Martin

Best,
Wolfgang


_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig


--
------------------------------------
 Dr. Martin Doerr
Honorary Head of the
 Center for Cultural Informatics
Information Systems Laboratory
 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
N.Plastira 100, Vassilika Vouton,
 GR70013 Heraklion,Crete,Greece
Vox:+30(2810)391625 Email:mar...@ics.forth.gr Web-site:http://www.ics.forth.gr/isl
_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Reply via email to