Pat, (01)
Apologies for the lateness of my reply - but rather a lot of (real) work to
do at the moment. (02)
> If you are representing the state of the room, are you only
> representing
> the temperature of the room and no other property (e.g. atmospheric
> pressure, light intensity) in this illustration? If so, then this
> seems to
> be equivalent to an assertion of a temperature on a time-slice of the
> room
> for each time-slice, in the format I used, and either could be
> translated
> into the other without loss of information. (03)
Well, sort of.
There is a possibility of a little equivocation between the object and its
time-slice.
I would suggest that one clearly represent the object and its time slice, as
one is interested in both.
I think this is missing from your representation. (04)
If you find an advantage
> to the
> representation you mention, I would be interested to have (just a
> little)
> more detail. (05)
http://www.bbc.co.uk/weather/world/city_guides/results.shtml?tt=TT004430
If you look at the temperature bar chart here - you can see that it shows
both the object, the time-slice and the temperature. (06)
a) (hasTemperature Room23 (celcius 40))
b) (hasTemperature Room23 (celcius 40) t1)
c) (hasTemperature RoomSlice4023 (celcius 40)) (07)
So:
(a) does not mention the slice (or the time)
(b) does mention time but not the slice
(c) does mention the slice but not the room. (08)
My preference for slices over times is that then there is no (direct)
dependency on time. (This can also make a lot of sense in database
implementations - who wants to keep sorting on time.)
This is dependency is clear if one does the esoteric sci-fi thought
experiment where the room goes back in time - then time is no longer a
relaible basis for sequence the room slices. (BTW only using the thought
experiment as a mechanism to clarify the dependency.) (09)
Regards,
Chris Partridge
Chief Ontologist (010)
Mobile: +44 790 5167263
Phone: +44 20 81331891
Fax: +44 20 7855 0268
E-Mail: partridgec@xxxxxxxxxxxxxxx (011)
BORO Centre Limited
Website: www.BOROCentre.com
Registered in England No: 04418581
Registered Office: 25 Hart Street, Henley on Thames,
Oxfordshire RG9 2AR (012)
This email message is intended for the named recipient(s) only. It may be
privileged and/or confidential. If you are not an intended named recipient
of this email then you should not copy it or use it for any purpose, nor
disclose its contents to any other person. You should contact BORO Centre
Limited as shown above so that we can take appropriate action at no cost to
yourself. All BORO Centre Limited outgoing E-mails are checked using Anti
Virus software. (013)
> -----Original Message-----
> From: uom-ontology-std-bounces@xxxxxxxxxxxxxxxx [mailto:uom-ontology-
> std-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Patrick Cassidy
> Sent: 15 July 2009 14:48
> To: 'uom-ontology-std'
> Subject: Re: [uom-ontology-std] retitled: magnitude of a quantity
>
> Chris,
>
> [Chris Partridge] >
> > It seems to me the substance of your argument is that it is not
> useful
> > to re-ify these specific instances of quantitative properties, rather
> than
> > you find it difficult to represent them. Is that right?
> >
> Right - thus far. But my particular concerns center around making
> the
> ontology close enough to ordinary language to make interpretation of
> language as easy as possible. I would be interested in examples of
> where
> such reification actually is more useful than an assertion.
>
> [CP] >
> > The issue here is the old 3D/4D issue of change over time. If the
> stick/room
> > undergoes changes over time then it does not have the length /
> > temperature property simplicitur, it has it at a point or over a
> period
> > of time. The representation example you give above does not cater for
> this.
> >
> The issue of 3D/4D should not affect the point I was making, as in
> the
> assertion:
> (hasLength Rod23 (meters 1.3))
> The entity Rod23 could be a time-slice of a rod (though if it were I
> would
> name it differently), or the entire assertion could be wrapped in a
> 'isTrueInContext' wrapper that could include the time interval (as well
> as
> other context elements such as possible world, belief system etc).
>
>
> [CP] >
> > My experience is different, in that I have found that systems often
> > work more effectively if one does reify them. However, in a 4D
> ontology,
> > this is just a matter of reifying the states that have the property
> (the
> > specific property collapses into the state or that state being an
> instance
> of
> > the general property). So, where an room undergoes a series of (step)
> > temperature changes - it has a series of states that each are
> instances
> > of their general temperature property.
> >
> If you are representing the state of the room, are you only
> representing
> the temperature of the room and no other property (e.g. atmospheric
> pressure, light intensity) in this illustration? If so, then this
> seems to
> be equivalent to an assertion of a temperature on a time-slice of the
> room
> for each time-slice, in the format I used, and either could be
> translated
> into the other without loss of information. If you find an advantage
> to the
> representation you mention, I would be interested to have (just a
> little)
> more detail.
>
> Pat
>
>
> Patrick Cassidy
> MICRA, Inc.
> 908-561-3416
> cell: 908-565-4053
> cassidy@xxxxxxxxx
>
>
> > -----Original Message-----
> > From: uom-ontology-std-bounces@xxxxxxxxxxxxxxxx [mailto:uom-ontology-
> > std-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Chris Partridge
> > Sent: Wednesday, July 15, 2009 3:54 AM
> > To: 'uom-ontology-std'
> > Subject: Re: [uom-ontology-std] retitled: magnitude of a quantity
> >
> > Pat,
> >
> > > The more substantive issue is whether we want to have a class
> > > representing
> > > the specific instances of quantitative properties (length of a
> > > particular
> > > stick, temperature of a particular room at some particular time,
> > etc.),
> > > inasmuch as (even though they are logically distinguishable
> entities
> > -
> > > called 'tropes' in some treatments), I have never been able to find
> a
> > > way to
> > > use them to good effect.
> >
> > It seems to me the substance of your argument is that it is not
> useful
> > to
> > re-ify these specific instances of quantitative properties, rather
> than
> > you
> > find it difficult to represent them. Is that right?
> >
> > My experience is different, in that I have found that systems often
> > work
> > more effectively if one does reify them. However, in a 4D ontology,
> > this is
> > just a matter of reifying the states that have the property (the
> > specific
> > property collapses into the state or that state being an instance of
> > the
> > general property). So, where an room undergoes a series of (step)
> > temperature changes - it has a series of states that each are
> instances
> > of
> > their general temperature property.
> >
> > > When I want to assert that a stick has some
> > > particular length, I assert, e.g. (in SUMO SKIF notation)
> (hasLength
> > > Rod23
> > > (meters 1.3)) where 'meters' is used as a function.
> >
> > The issue here is the old 3D/4D issue of change over time. If the
> stick
> > /
> > room undergoes changes over time then it does not have the length /
> > temperature property simplicitur, it has it at a point or over a
> period
> > of
> > time. The representation example you give above does not cater for
> this.
> >
> > Representationally you can argue for an extra parameter in the
> > representation or a reification of the states. When one starts
> builing
> > systems that need to track changes over time, it is easier to take
> the
> > reification option.
> >
> > Regards,
> > Chris Partridge
> > Chief Ontologist
> >
> > BORO Centre Limited
> > Website: www.BOROCentre.com
> > Registered in England No: 04418581
> > Registered Office: 25 Hart Street, Henley on Thames,
> > Oxfordshire RG9 2AR
> >
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
> Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
> Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/uom-
> ontology-std/
> Shared Files: http://ontolog.cim3.net/file/work/UoM/
> Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard
> (014)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/uom-ontology-std/
Subscribe: mailto:uom-ontology-std-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/uom-ontology-std/
Shared Files: http://ontolog.cim3.net/file/work/UoM/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?UoM_Ontology_Standard (015)
|