Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

SUO: RE: Basics of Process and Event, 3D and 4D




Matthew,
    I will respond here to the main questions
in your note, not in the original order, and
leaving out some things which don't seem to
require further discussion (resurrect them
if you think they do):


-------------------
 >>>MW: How can events and process have a location in space time
 >>>without taking up space time?
 >>>
 >>[PC2]   The "location" of processes and events is derived from the
 >>objects that participate in the processes and events.  That is
 >>also noted in the WonderWeb D17 paper.
 >
 > MW: Can you give a page and para reference please.
 >
[PC3] On page 12 of D17 in the paragraph headed "direct and
indirect qualities"  they say "perdurants have a well-defined
temporal location, while their spatial location seems to come
indirectly from the spatial location of their participants;"

[ I said "noted", not "explained" --  ;-) ]

I find it convenient to allow vague locations for objects
(e.g. "somewhere in Manhattan"), which then would imply that
there are also vague locations for Events (which in PUO
take up some interval of time).

-------------------------
[PC3]On using time intervals rather than time points:
 >> [PC]  The ?LOC location for the Event could be specified vaguely,
 >>as for example "in New York City" during the Event.  Then
 >>the location for the individual objects participating in
 >>the Event would only be able to be inferred vaguely at
 >>those times.  If one wanted to get more detail about the
 >>locations of participants at several time points within
 >>the Event, one would have to refer to the Process describing
 >>the AttributeValues of each participant in the Event, or break
 >>the Event down into smaller component Events (temporal parts).
 >>    The inference from the locations of the participant objects
 >>to the location of the Event would go in the reverse
 >>direction, but would require a different axiom.
 >
 >
 > MW: Why don't you just use the temporal parts of their life
 > histories?

  . . . and later:
 >>[PC]   As the AttributeValues characterizing the meeting
 >>Event, the representation of the event might include
 >>only be those changes (or non-changes) in the knowledge
 >>state of the participants shown above, plus the roles of
 >>the participants (speaker, listener) at each time point,
 >
 >
 > MW: It strikes me as very inefficient to only be able to
 > specify roles at time points, rather than for regions of
 > time.

[PC3]   Yes, assertions referencing time can use either time
points or time intervals, so in some cases it may be
simpler to refer to a property in a time interval.
That is possible in 3D, and it is particularly useful
when a property is constant for some time period.  But
as for the locations of temporal parts, when a location
is changing with time, the "region" that contains a moving
object *at some time* during a time interval will not be
the same as the spatio-temporal region occupied by a temporal
part of a 4D object.  To get the accurate equivalence
in 3D will, I think, require that the motion be traced for
each time point.


--------------------------
 >>>>[PC] (2) a "system" is any grouping of (one or more) objects plus
 >>>>    the attributes, relations, and processes related to
 >>>>    those objects.  An ontologist can select the objects
 >>>>     of a system and ignore those of no interest, even
 >>>>     if they are in close proximity.
 >>>
 >>>
 >>>MW: This does not seem to be more than a simple aggregate of
 >>>objects, which by implication are "atomic". Is that right?
 >>>
 >>[PC2]   Not just objects, but the relations between them and their
 >>attributes as well.  If it were a group just of the objects, it
 >>would be an "ObjectGroup" which is qualitatively just like an
 >>Object, but consists of more than one identifiable constituent
 >>Object.
 >
 > MW: That is a very unusual use of system then, but never mind. It
 > also seems to me to be redundant.
[PC3]   Yes, it is unusual usage.  It is intended to serve the
purpose of providing a high-level concept that can be used to
define a "State", from which I get a "Process" from which I get
a "Event".  Originally I had a concept of "System" that had
at least two objects in it, and I think such a concept is
useful, but that would be a subclass of the highest-level
"System".  If the name is misleading, it should be changed.


----------------------------------
 >>
 >>[PC2]   I read the paper and still haven't formed a good image
 >> of how the Activities and Events and States relate to each other.
[in 4D Epistle]
 >
 > MW: Activities cause changes in state, the start and end of
 > states are marked by events, so we say that the activities cause
 > the events.
 >
 > MW: Since the real world is not a state machine, there can be
 > indeterminate states. So when switching a light on, there might
 > be an indeterminate state when the light is neither on nor off.
 >  Our events mark when the light is definitely on. I think your
 > events mark the indeterminate state when it
 > is neither off nor on.
 >
[PC3]   Yes, that seems right.  The change of going from "off"
to "on" in some time interval  would be a 3D Event.  That
would be an AtomicEvent, with only "off" and "on" states
and the time interval represented.


------------------
 >
 >>[PC] The paper [MW's on activity and state]
 >>shows that Activities can extend over time, but do the "Events" that
 >>mark the start of a new state occur only at the end of the Activity?
 >
 > MW: Not necessarily.
 >
 >>If one Activity extending over time can cause many Events, each
 >>one leading to a new State, then Activity would be very close to
 >>what I call a "Process".
 >
 > MW: I would also see your process as close to our activity. I think
 > there is more difference between our views of event though.
 >
[PC3]    Yes, the term "Event" is very different in Epistle and PUO.
In fact, given that an Epistle Event can move in time and space,
I don't think I yet have anything equivalent.  Gotta think
hard about how to do that in 3D.  :-)


-------------------------
 >>>>[PC] (3) an "instantaneous state" of a system is the grouping
 >>>>    of the attributes (properties, relations, fluents,
 >>>>    whatever you call them) of the objects and
 >>>>    processes of the system.
 >>>
 >>>How do you say for example "The room was at 20C all day." ?
 >>>
 >>
 >>[PC2]    The instantaneous state (temperature) had the value of 20C
 >>at every time point during the day.
 >
 > MW: You haven't related that to the room yet. Will you relate it to
 > the 3D physical object room, or the room's life-history, or both?
 > If one, why not the other?
 >
     The temperature attribute would relate to the 3D physical object
"room" in a time interval and would be implicitly part of the
room's "life history" though such a life-history need not have
an explicit representation.  I may only be interested in
that particular time interval.  I'm not sure how much detail
you want, but here is some more:
     To get into more details, I have to assume that "room" refers
to both the container (walls, floor, ceiling) and contents (air,
furniture, fixtures) and that the temperature of all of those
things is the same, and that the temperature of any one can be
inferred from the temperature of the "room":
    Then one can enter the state into the system as a simple assertion,
and an instance of a NullEvent will then be created: the situation
would be represented as a PersistentState (Synonym: NullEvent)

Assertion:  (holdsInInterval  (hasAttribute room034 Temperature  20C) 
  T20030620.00.00  T20030621.00.00)
    [note that a time interval is represented by the enclosing time
points, but does not necessarily include those points. I prefer
time intervals that are closed at the lower end and open at the upper)

[Note: a PrimitiveNullEvent is one with only one attribute value 
represented, therefore the arguments are individual values rather than
groups of values]  The elements of the data structure are:
The entity with the attribute, attribute at beginning time, attribute 
at ending time, beginning time, ending time.

Datum In Knowledge base (a data structure or Object):
   Instance of PrimitiveNullEvent:
{
      label:      Event2003.12345
      Entity:     room034
      StartState: (Temperature  20C)
      EndState:   (Temperature  20C)
      StartTime:  T20030620.00.00
      EndTime:    T20030621.00.00
}

    The PrimitiveNullEvent could be translated directly back
into a "holdsInInterval" assertion if desired.  More complex
discrete events are composed of multiple PrimitiveEvents
(concurrent or sequential or both).  An Event that is
modeled as the result of continuous process will need a
mathematical equation to enable the calculation of the
state at any time point.

    The construction of the data structure can happen before
any inferencing, and one can do a lot more with the data if
one wants -- like figuring out if the water in the glass is
solid or liquid, etc., or figuring out if this is new or old
knowledge, and whether it is consistent with prior knowledge.
    Of course, real assertions will be marked with their
source, time, reliability and perhaps other factors.


-----------------------------

 >>>>=======================================================
 >>>>[PC] (1) An "Object" is something that has an ObjectAttribute.
 >>>
 >>>
 >>>MW: Can an ObjectAttribute have an attribute? (severly limiting
 >>>if it can't).
 >>>
 >>
 >>[PC2]  Yes, there are types of "attributes" that modify
 >>other attributes.  The ones that come most readily to
 >>mind are magnitude or intensity modifiers:
 >>   Very large
 >>   deep red
 >>   gently curved
 >>   weakly effective
 >>   varyingly loud
 >>
 >>  . . . but some are qualitative:
 >>    greenish red
 >>    stunningly gorgeous
 >>    beautifully shaped
 >>
 >>    I haven't attempted to classify the adverbial-type attribute
 >>modifiers as yet.  They seem to be of different types, in
 >>part depending on how close to deverbal the adjectives they
 >>modify are.  If the adjectives that function as attribute labels
 >>are derived from verbs, the attributes that modify such
 >>adjectives can be the same adverbs that specify the modal
 >>variations in the activity described by the verb -- e.g.
 >>a "Cleverly written" novel or a "quickly executed" maneuver.
 >>There are complications depending on what one chooses as
 >>attributes to represent.
 >
 >
 > MW: Interesting, I would see these as subtypes of the original
 > property/quality. So if red is some range of colour, then deep
 > red is a subset of that range. But your qualities/properties are
 > not sets.
    Subtypes of attributes are tricky in 3D.  George Miller
and the WordNet group have looked carefully at how adjectives
relate to each other, and they don't even try to create
a hierarchy.  When I first looked at intensifiers, I wondered
if they would specify subtypes, but it doesn't seem so.
For cases where an attribute can be considered as falling on a
linear scale the intensifiers seem to specify relative location
on the scale (varying with context), not subtype:
    Height
      extremely high
      very high
      high
      somewhat high
      slightly high
      low
      very low
     . . . .

   To try to consider any of the modified "height" attributes as a
subtype of another seems to lead to a contradiction.
    For attributes that are qualitative or multidimensional,
it may be possible to define a Region and specify subareas
within the region.  Color may be one of those -- but getting people
to agree on the borders of the regions is a different question.
(Monochromatic colors can be ordered by wavelength, but that
is a special case).

    When we get to attributes which are labeled by adjectives
which are derived from verbs, it gets curiouser.  For the
example "cleverly written" -- it is reasonable to imagine
a set of "written documents" among which the "cleverly
written" ones are a subset.  But the adjective and its
modified form don't seem to fit the character of sets.
I'm not sure how to relate the adjectives, just the
objects with those properties.


--------------------------------
Attributes as particulars:

CYC has the class "AttributeValue" but it is not clear
to me from their documentation whether they consider
them as "particulars" inherent in the entities
they modify.


>>[PC2]  I should have said "changes in attributes, each **change**
>>occurring in some interval of time".  Can "attributes" themselves
>>occur in time??  There is a distinction that needs to be made --
>>I am referring to AttributeValues -- the things that change --
>>( I should have said "AttributeValue" but was speaking loosely)
>>as those things that stick to the objects they inhere in and follow
>>them around in space.  The terminology here is tricky, it seems
>>that no matter what words we use there will be a large constituency
>>that interpret them in a sense other than what we intend.  In the
>>WonderWeb paper D17 by Masolo and Guarino and others they call these
>>things "Qualities" and say:
>>
>>"Qualities can be seen as the basic entities we can perceive and
>>measure: shapes, colors, sizes, sounds, smells, as well as weights,
>>lengths, electrical charges. . . . 'Quality' is often used as
>>synonymous with 'Properly' but this is not the case in DOLCE: 
>>qualities are particulars, properties are universals.  Qualities 
>>*inhere* in
>>entities . . . "
> 
> 
> MW: interstingly, looking at Dolce D17 p12, I see that they see
> qualities like "the colour of my hair" which might have a particular
> value "brown". At one stage we had this concept and called it "aspect".
> In the end we found it unnecessary in our 4D approach. I'm not sure
> this is quite what I heard you saying above though.
> 
>>    There are I think three levels at which Attributes (Qualities,
>>Properties) have to be understood:  The most generic, e.g. Color,
>>which is an AttributeType; and instances of such AttributeTypes which
>>are specific Attributes, such as Red0223 on some industry color
>>chart.  Both of these are universals.  Then there are the 
>>"AttributeValues" as I think of them (or Qualities in DOLCE
>>terminology) which are inseparable from the objects they inhere
>>in, such as the red0223 color which we see on a specific woman's lips
>>at a specific time and place.  What should we call the last very 
>>specific sort of "Quality"??  The distinctions may be a little
>>slippery -- it's not what I think of as obvious common sense.
>>I think these qualify as "particulars" as I understand the term.
>>I think this is the same idea that some philosophers call "tropes"
>>
>>"Trope:  An abstract particular, or particularized property.  For 
>>example, the whiteness of a piece of chalk considered as a 
>>particular, 
>>not a universal.  It is an abstract feature of the chalk.  Both the 
>>chalk and its whiteness are particulars—they are not 
>>repeatables.  The 
>>chalk is a concrete particular and its whiteness is an abstract 
>>particular. "
> 
> 
> MW: Yes, when we had 3 dimensional tendencies we talked in terms of
> "possessed properties". Trope seems to be a reasonably well accepted
> term in the reading I have done, so I would suggest using it if it
> corresponds to what you mean.
> 

[PC3]   I have been using "AttributeValue" but I can include
"Trope" as a synonym.  I suspect the average person new to building
ontologies will not know what a trope is, and unfortunately the
word has been used in more than one sense.

--------------------------------------------
> 
> MW: Just for reference, let me give you the 4D equivalent (at least
> as we have it in EPISTLE). When we talk about a property, we mean
> something like a particular degree of hotness, e.g. that we describe
> as 20C. Properties are sets (including having unchanging membership).
> and some temporal parts of of some individuals are members of those
> sets (so property is a subtype of class_of_individual). Note this is
> a more specific use of the word property than is usually used in
> philosophical circles, but then I come from engineering circles.
> 
> You will see that your trope maps roughly to the classification
> relation between the property and the temporal part (state) of 
> the individual.
> 
> Note that there is no "change" in properties, if the temporal part
> of me for 19th June 2003 weighs 13 stone, it will always be true that 
> that temporal part of me weighs 13 stone. So membership of the properties
> does not change, so properties can be treated as sets. So we have
> properties/qualities on a firm foundation - set theory.
> 
[PC3]   Of course if you take a consistently 4D view of everything
there will be no "changes", but if you are interested in the
properties of specific different temporal parts of objects
there may be a "difference".  A change of AttributeValues
is just one kind of difference that one might see
between different temporal parts of the same 4D object.
     I think that Trope theorists also treat Properties as
sets (or classes) of AttributeValues ("Qualities" in DOLCE).
That's how I interpret the D17 paper.  So in 3D, for each
instance of AttributeValue (Quality/Trope) that does not
differ for some interval of time, there should be a corresponding
4D Property for the corresponding Temporalpart of the corresponding
4D Object.

-------------------------
>>>
>>>MW: Sounds like atomic event is a bit of a waste of time.
>>>
>>
>>    An explosion would be an AtomicEvent if one chose to
>>ignore what happened in the few seconds or minutes when the
>>explosion occurred and the dust settled.  Then the beginning
>>and ending states would be "Building - intact" and "Pile of
>>Rubble".  An Atomic explosion could also be an "AtomicEvent" ;-)
> 
> 
> MW: But it seems to me that I can always choose to look at a more
> detailed view of what is going on, even with an explosion, so as
> I say it seems to me to be a waste of time, an unnecessary 
> distinction.
> 
[PC3]   An AtomicEvent will be used when one does not want to
complicate the reasoning unnecessarily with irrelevant
data.  Of course, one can also use some control of
inferencing to only look at the beginning and ending states
of a complex Event.  The choice should be there for the
implementer to decide.  It is especially useful when one
doesn't really *know* anything but the start and end states.

-------------------------------
>>[PC2]   An Event is defined by changes in the attribute values of 
>>objects or processes (location, temperature, composition, velocity,
>>density, etc.).  The Event of PC traveling to Boston is characterized
>>by all the changes in location that the ontologist chooses to
>>distinguish during the time interval of the Event.  If it is
>>treated as an AtomicEvent, then only the before and after
>>locations are specified, plus the time interval.  The Event of
>>PC learning a fact may be characterized in more than one way --
>>either PC's state of knowledge changes, or the location of the
>>physical representation of the fact (an abstract proposition)
>>expands into PC's brain.  Both could be represented.  The ontologist
>>chooses the attribute values of the objects of interest which
>>define each class of event.  Relations between Objects (distance,
>>e.g.) are also considered "AttributeValues" for this purpose.
> 
> 
> MW: OK. If in your original statement you had said attributevalue, I
> think I would have got that, because the attribtuevalue is dependent
> on the object right?
> 
[PC3]   Yes, intimately dependent.  The AttributeValues characterize
the object, if one considers all instantiated relations as
AttributeValues (which are Tropes) too.  One doesn't have to be
a pure "bundle" theorist to believe that, for the purpose of a
practical ontology, no two objects can have identical
AttributeValues (the "Identity of Indiscernibles") -- if one
were able to measure **all** of the AttributeValues (including
position).  This may not hold for fundamental particles which
are bosons, and perhaps can occupy exactly the same point in
space (I don't know if they can), so we may not even in theory
be able to *distinguish* certain different subatomic objects
with the same AttributeValues, but that doesn't cause any
contradictions if we model the world that way, provided that
we have a realistic provision for experimental error -- which
means that we can't always *tell* two fundamental particle
from each other -- but from the attributes we can tell that
there are two rather than one.

-----------------------------------
>>
>>[PC2]  OK. It seems that Activities can extend over Time,
>>but it is not clear to me whether Events occur only at the
>>end of an Activity or at many points during an Activity.
>>(Much knowledge about 4D Events has not yet expanded its
>>location into PC's brain.)
> 
> 
> MW: Just a small point, but strictly we are talking about
> how EPISTLE uses the term event in its 4D interpretation
> of activity and change to identify certain features on the
> 4D landscape.
> 
[PC3]   So as I understand it now, in Epistle the "Events" separate
States of a 4D Object from each other, and Activities cause
the Events to happen.  If one Activity is defined such that
it can cause more than one Event to happen, it may be considered
as extending over some TemporalPart of the Object that
includes more than two States.
    Something like that?  That would be to me a perfectly
reasonable way to define the relations, if in fact that's
what is intended.

-------------------------------
>>[PC] if the Location were given as a particular room, and the
>>"participant" relation was one of the Attributes of the
>>Event that is represented (and is indexed to time) we could
>>infer that the participants were present in the room at
>>time points within the time interval of the meeting Event.
> 
> 
> MW: Note that in our 4D approach participant is a class of
> the person's temporal part, not a relation. The temporal part
> is a part not only of the person, but also of the meeting.
> 
    Right.  Roles differ in 3D and 4D.

    Thanks for all the comments.

     Pat


=============================================
Patrick Cassidy

MICRA, Inc.                      || (908) 561-3416
735 Belvidere Ave.               || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054        || (908) 668-5904 (fax)
				
internet:   cassidy@micra.com
=============================================