ontology-summit
[Top] [All Lists]

Re: [ontology-summit] The tools are not the problem (yet)

To: "'Ontology Summit 2014 discussion'" <ontology-summit@xxxxxxxxxxxxxxxx>
From: "Matthew West" <dr.matthew.west@xxxxxxxxx>
Date: Sun, 16 Feb 2014 08:33:10 -0000
Message-id: <001101cf2af1$baf929d0$30eb7d70$@gmail.com>
Dear Ed,    (01)

Matthew West wrote:    (02)

> If you are objecting to a temporal part of a state, that would depend 
> upon what meaning of "state" you are using.
> 
> A state (State1) could be a set of properties, in which case a state 
> is timeless, can not have a temporal part, and may be possessed by 
> different entities at the same or different times.    (03)

[EJB]  I think of the set of properties as a classifier/predicate State1 and
everything Matthew says is then true of State1, but I agree that people do
use the term 'state' in this sense.    (04)

> 
> A state (State2) could be a situation of some individual being in
(State1).    (05)

[EJB] That is, a slice of space-time in which State1(X) holds for a given
individual X.    (06)

> This could be an instantaneous state (State2a), an extended situation 
> during which the individual is in that state (State2b), or the maximal 
> temporal situation during which the individual is in that State1
(State2c).
> 
> A State2a can not have a temporal part.  A State2b can have a State2b 
> as a temporal part for which they both share a State1.  A State2c can 
> not have a State2c as a temporal part if they both share the same State1.
>  
> A State2c can have a State2c as a temporal part if the second State2c 
> has a more detailed State1 (e.g., the first State1 is that the oil 
> temperature is between 140C and 160C and the second State1 is that the 
> oil temperature is between 150C and 155C).  In this case the second 
> State2c is a temporal part of the first State2c.    (07)

[EJB] Ah!  This is the problem.     (08)

 I understand 'S is a temporal part of X' to mean:  there is some
characterization C such that C(X) holds over a time interval T, and S is
understood to be the triple holds(C, X,T).  And S1 is a different temporal
part of X iff S1 = holds(C1, X, T1) for some C1 and T1, where Not (C1 = C)
or Not (T1 = T).  There are clearly other possible relationships of
interest, to wit C1 implies C (class C1 is a subclass of C),  T1 is a
subinterval of T, and S1 is a part of S2, where X1 is a part of X2,  and
holds(C2, X2, T1) implies holds(C1, X1, T1), i.e. a state of the whole (X2)
implies a state of a part (X1).  [this is what I meant about the need for
axioms that describe isTemporalPartOf.]    (09)

>From the example below, Matthew apparently uses  'S is a temporal part of
X' to mean:  S is a state/situation that involves X in some role, which is
just a generalized view of "some C(X) holds".    (010)

But what Matthew says here is that S2c is a temporal part of S (not X!) if
S2c = holds(C1, X, T1) and C1 implies C and T1 is-within T!  I would expect
that temporalPartOf(S2c, S) would mean there is a C1 and a T1 such that
holds(C1, *S*, T1) !   In the generalized view, S2C (X having the narrower
temperature range) plays a role in S (X having the broader temperature
range).  I don't understand the ontological commitment that permits S2c to
be viewed as playing a role in S.  So, I don't know what temporalPartOf
means!    (011)

[MW>] I hope it is clear by now. There are no conditions on what states are
valid. A state is ANY temporal part of a whole life individual that is of
interest for any reason. Interesting ones may overlap, or not, may run in
sequences, or not. There really are no rules about what is valid beyond
being a temporal part.
> ... 
> > [MW] Consider the temporal part of pump with serial no. P1234 
> > (materialized physical object) that is installed as tag 21P101 
> > (functional physical object). It is a temporal part of each of these,
not just one.
> > The thing to note is that they are two different types of whole life 
> > individual, but you need all the elements of the type.    (012)

If S is a temporal part of the FPO named 21P101, then S =
holds(instantiatedByP1234, 21P101, T) for some T.  And if S is a temporal
part of the Pump named P1234, then S = holds(placedAs21P101, P1234, T) for
the same T.    What we really have here is that instantiatedBy(fpo, po) =
placedAs(po, fpo), or more accurately:  forall (T) instantiatedBy(fpo, po,
T) iff placedAs(po, fpo, T).  So the State S is an instance of both ternary
relations.  And S can be described as a temporal part of both the pump and
the place.  And to carry any semantics, S must be an instance of the class
Placement, or something like that.  Further, the fact that S is a temporal
part of Pump and Place tells me how to formulate the relation, but only
because the 'types' of the arguments to placedAs are disjoint.    (013)

[MW>] There is no instantiated by here. Identity for spatio-temporal extents
is the spatio-temporal extent, i.e. if two individuals have the same
spatio-temporal extent, they are the same object. So the temporal part of
the installed pump is also a temporal part of the tag it is installed as.
There are not two spatio-temporal extents with a relationship. The Tag in
turn consists of the temporal parts of the equipment installed.    (014)

Now, let us consider flowsInto(equipment1, equipment2).  
[MW>] What does this mean? That equipment1 has a connection to equipment2?    (015)

And suppose that at time T, Pump P1234 is connected to HeatExchanger H5678,
in such a way that the process fluid flows from P1234 to H5678.  Then we
have a FlowsInto state that is a temporal part of P1234 and a temporal part
of H1234 for the same time interval T.  But which is the source and which is
the destination?  They are both Equipment, so we can't tell.  
[MW>] In principle, the flow can be either way, and in practice, you need to
understand the pressure differentials in the system, usually generated by
pumps and compressors, but occasionally by gravity. So you can do some
reasoning once you understand what those are.    (016)

This is admittedly contrived.  But the problem is intrinsic.  
[MW>] Yes, but not difficult.    (017)

The state that is a temporal part of two things represents a ternary
relation that involves them in distinct roles over a common time interval. 
[MW>] A state may include temporal parts of multiple objects, and so it may
look like an n-ary relation, but it is a state, and not an n-ary relation.
It might have been modelled as an n-ary relation in a 3D approach, so this
relationship between different ways of modelling is worth noting.    (018)

 In general, the types of the non-temporal arguments to the ternary relation
represented by the state may not be distinct.  So the relationship between
the State and the participants is not just isTemporalPartOf, but rather some
refinement of it that represents each role in the ternary relation.  
[MW>] Yes. Much the same as in an activity (which also consists of the
temporal parts of its participants playing roles in the activity). Indeed
you should check that you are not talking about an activity instead of a
state. A state is something about which what you say does not change during
the period of the state, whereas an activity is something that brings about
change to something (e.g. brings about a new state in something).    (019)

Using a language in which the only relationship to a State is
'isTemporalPartOf', 
[MW>] Then you are obviously not using ISO 15926.    (020)

the solution will be to create things that are instances of a class
representing a role in the state, and make the role things temporal parts of
the role players and also temporal parts of the state thing.  
[MW>] They may not be temporal parts of the state thing. If you have a state
that consists of a temporal part of a pump and a temporal part of a heat
exchanger, then those states are spatial parts of the whole, not temporal
parts.    (021)

So we have a FlowSource that is a temporal part of the Pump and the
FlowsInto state, 
[MW>] I'm still not sure what you think Flowsinto actually means in plain
English.    (022)

and FlowDestination that is a temporal part of the HeatExchanger and also a
temporal part of the FlowsInto state.  Thus the state thing involves things
of two distinguished types, and the ternary relation can be properly
reconstructed.  It is a work-around, and most modeling languages force such
contrivances from time to time.  But coupled with the above confusion about
relationships between states, I can't be sure that anyone can reconstruct
the intent of 'isTemporalPartOf'.  
[MW>] Is temporal part of is very simple, and should by now be clear. What
is less obvious are all the layers you are trying to impose on it, and the
reasoning for that, unless you are just trying to make it a lot more
difficult than it actually is so that you can discredit it.    (023)

Regards    (024)

Matthew West                            
Information  Junction
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
https://www.matthew-west.org.uk/
This email originates from Information Junction Ltd. Registered in England
and Wales No. 6632177. 
Registered office: 8 Ennismore Close, Letchworth Garden City, Hertfordshire,
SG6 2SU.    (025)




_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014  
Community Portal: http://ontolog.cim3.net/wiki/     (026)
<Prev in Thread] Current Thread [Next in Thread>