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: Sat, 15 Feb 2014 21:27:22 -0000
Message-id: <033401cf2a94$b706b430$25141c90$@gmail.com>
Dear David,    (01)

On 14 Feb 2014, at 22:03, Barkmeyer, Edward J <edward.barkmeyer@xxxxxxxx>
wrote:    (02)

> Matthew West wrote:
> 
>> 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.
> 
> [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.
> 
>> 
>> A state (State2) could be a situation of some individual being in
(State1).
> 
> [EJB] That is, a slice of space-time in which State1(X) holds for a given
individual X.
> 
>> 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.
> 
> [EJB] Ah!  This is the problem. 
> 
> 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.]
> 
>> 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".
> 
> 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!    (03)

If what you're getting from MW is that "temporal part of" means "there is
some characterization C such that C(X) holds over a time interval" then step
back ... that is not what it means. No such characterization is necessary
when creating parts and temporal part of relations.    (04)

'S temporal part of X' means 'S is a time slice of X' ... nothing more. To
make that time slice interesting, 
[MW>] The principle is that every possible temporal part you can construct
is out there, so the only question is which ones are you interested in, and
you care to record. There are no other requirements.    (05)

there are sometimes characterisations that hold, but in other cases not. For
example, in our Oil and Gas reporting app "NJORD A Platform during January
2013" is interesting and is TPO "NJORD A Platform during 2013" which is also
interesting, but there is no additional characterisation ... they are just
both interesting time slices (i.e. TPO) of the same whole-life thing "NJORD
A Platform whole-life".     (06)

So given triples    (07)

X a PossibleIndividual (with beginning and ending, and may be whole-life or
not) S a Possible Individual (with beginning and ending within period of X
beginning and ending) S TPO X C a Class S a C    (08)

there need not be any relation between "S a C" and "S TPO X" or between X
and C at all. In my example, "NJORD A Platform during January 2013" may have
stopped production of oil due to repair. However, that repair is only
related to the part, not the larger part or the whole-life platform. It
could also have been the case that the app only ever reported data monthly
so the "NJORD A Platform during 2013" individual and TPO relationship would
never have been instantiated. If you simply take "temporal part of"
literally then you are likely to get it right. The relation could have been
"temporal part of based on characterization" and all this discussion would
follow ... but that's not what 15926 says.    (09)

Clearly there's are philosophical debates, as described in
https://en.wikipedia.org/wiki/Temporal_parts, but 15926 TPO is the same
relation described in that Wikipedia article and it is reasonably
well-defined as a position.
[MW>] It's worth commenting on just one aspect of this. There are two common
positions taken about temporal parts, one is that they are infinitesimal
time slices, so an infinite number of them, and you string them together to
make up whole life individuals. I don't subscribe to this view on pragmatic
grounds that it is not convenient to store large numbers of such slices. So
I take the view that temporal parts, although they may be infinitesimal in
size, they may also have temporal extent. Generally the temporal parts that
are interesting are ones we want to say something about, but there is no
special rule about what may be a legitimate interest.
Regards
Matthew    (010)

Cheers,
David    (011)



> 
>> ... 
>>> [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.
> 
> 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.
> 
> Now, let us consider flowsInto(equipment1, equipment2).  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.  This is admittedly contrived.
But the problem is intrinsic.  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.  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.  
> 
> Using a language in which the only relationship to a State is
'isTemporalPartOf', 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.  So we have a FlowSource that is a temporal part of the Pump and the
FlowsInto state, 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'.  
> 
> Famous last words:  "It is not how I would have modeled it, but it works."
This is knowledge engineering in which the knowledge is contorted by the
engineering.  
> 
> -Ed
> 
> 
> _________________________________________________________________
> 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/    (012)


_________________________________________________________________
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/     (013)


_________________________________________________________________
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/     (014)
<Prev in Thread] Current Thread [Next in Thread>