ontac-forum
[Top] [All Lists]

RE: [ontac-forum] Neutrality Principle

To: "ONTAC-WG General Discussion" <ontac-forum@xxxxxxxxxxxxxx>
From: "West, Matthew R SIPC-DFD/321" <matthew.west@xxxxxxxxx>
Date: Wed, 30 Nov 2005 09:41:35 -0000
Message-id: <A94B3B171A49A4448F0CEEB458AA661F02A80C43@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Dear John,    (01)

I've been thinking about this for a few days because I always
have an intended interpretation when I model. So this is a bit
of a departure for me.    (02)

If I've got you right, I should look at the UF, and be happy as long
as it makes sense with a 4D interpretation, whilst others should be
able to look at it with a 3D interpretation.    (03)

And actually me looking at it from that perspective would be useful 
in making sure that the UF did not have an implicit interpretation.    (04)

Right?    (05)

If so, it should be interesting to see how far we get.    (06)


Regards    (07)

Matthew West
Reference Data Architecture and Standards Manager
Shell International Petroleum Company Limited
Shell Centre, London SE1 7NA, United Kingdom    (08)

Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@xxxxxxxxx
http://www.shell.com
http://www.matthew-west.org.uk/    (09)


> -----Original Message-----
> From: ontac-forum-bounces@xxxxxxxxxxxxxx
> [mailto:ontac-forum-bounces@xxxxxxxxxxxxxx]On Behalf Of John F. Sowa
> Sent: 27 November 2005 17:49
> To: ONTAC-WG General Discussion
> Subject: Re: [ontac-forum] Neutrality Principle
> 
> 
> Dear Matthew,
> 
> In my recommendations for UF, I suggested that
> it could be *huge*, but with very few axioms.
> 
>  > Are you aware just how small the UF really is?
> 
> I would expect it to include pump, but with very
> little specification.
> 
>  > Take something like pump. In a 4D ontology this would
>  > be represented by a set (unchanging membership) of
>  > spatiotemporal extents. In a 3D ontology the members
>  > are occupents. Now you could of course have a class
>  > that was the superclass of these two, but you wouldn't
>  > get a sensible answer from it for how many pumps there are.
> 
> And by the way, some people use the word "class" and some
> use the word "type".  I prefer type because class is often
> used as a synonym for "set", except when it isn't. In any
> case, classes are typically defined extensionally, but the
> types in an ontology should be definable even when there
> aren't any examples (for example, when you're specifying
> a design for a type of entity that hasn't yet been built).
> In any case, the question of whether to use type or class
> as a metalevel term should not have any influence on what
> is included in the UF.
> 
> Comments:
> 
>   1. I would define a pump as "PhysicalObject", which would
>      be a top-level undefined category.
> 
>   2. You could define PhysicalObject as a spatiotemporal extent,
>      and Barry could define it as an occurrent.  Nothing in UF
>      would refer to either spatiotemporal extents or occurrents.
> 
>   3. I would not expect *anybody* to use UF by itself for any
>      kind of reasoning.  They would just import whatever they
>      want and combine it with the more detailed axioms in
>      whatever system they prefer.
> 
> John
> 
>  
> _________________________________________________________________
> Message Archives: http://colab.cim3.net/forum/ontac-forum/
> To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
> Subscribe/Unsubscribe/Config: 
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki: 
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG    (010)



_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config: 
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki: 
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG    (011)
<Prev in Thread] Current Thread [Next in Thread>