ontac-dev
[Top] [All Lists]

RE: [ontac-dev] ISO15926 and sets and types

To: "ONTAC Taxonomy-Ontology Development Discussion" <ontac-dev@xxxxxxxxxxxxxx>
From: "West, Matthew R SIPC-DFD/321" <matthew.west@xxxxxxxxx>
Date: Mon, 30 Jan 2006 20:53:36 -0000
Message-id: <A94B3B171A49A4448F0CEEB458AA661F02CE545A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Dear Pat,    (01)

This sounds much better.    (02)

See below.    (03)


Regards    (04)

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

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


> -----Original Message-----
> From: ontac-dev-bounces@xxxxxxxxxxxxxx
> [mailto:ontac-dev-bounces@xxxxxxxxxxxxxx]On Behalf Of Cassidy, Patrick
> J.
> Sent: 30 January 2006 18:45
> To: ONTAC Taxonomy-Ontology Development Discussion
> Subject: [ontac-dev] ISO15926 and sets and types
> 
> 
> Matthew,
>   Ok, try again:
> [MW] You missed my point. I was asking about what you saw as different
> in the
> relationship, rather than in the related objects. You seemed very
> adamant
> that there was a big difference, and I don't see it. So what 
> do you see
> as the difference in the instance relationship between 
> instance and set
> and instance and type?
> 
> [PC] It depends on how you define a Type.  As I mentioned, it can be
> coherently defined as in  the Frame-Ontology as a set of 1-tuples.  It
> can also be defined as a set of assertions of the form (T i) 
> where t is
> the name of the Type, acting as a one-argument predicate.      (07)

MW: I'm with Barry on this and prefer:     (08)

  instance_of(i, T)    (09)

Which conveniently allows types to be instances.    (010)

> In either
> such cases, one can extract the instances and they will behave exactly
> as we want them to, being inherited down the Type subsumption
> hierarchy.  But we want to avoid such ontological commitments, and we
> deliberately don't define Type that way, leaving the definition very
> general in such a way that, if you want to, you can define a 
> subtype of
> the general "Type" (which is actually a metatype) so that it has those
> peculiar properties, or you can define it so that it behaves
> extensionally, or you can define it so that it behaves as Barry Smith
> would like for biological classifications, as something that exists
> naturally whose members can be discovered.  For COSMO we minimally
> axiomatize the most general "Type" and where necessary users 
> can define
> more specific subtypes of that general Type.    (011)

MW: So anything that has instances is a type, and some types are sets,
some are natural kinds, some are defined by intension etc etc. Sounds
just right.    (012)

> 
> Therefore, the instances of a Type will only be identical to the
> members of the set which is a Type in the case where one uses the more
> restrictive definition in which the Type is defined extensionally.
> That is to say, it is sometimes true, and sometimes not true that they
> are the same.
> 
> When I say that the instances of a Type are not the same as 
> the members
> of a set, that means that they are not the same in the general case,
> using the minimal axiomatization of Type.  There may be special cases,
> where a Type is defined extensionally, when they are the same.  There
> will also be special cases, if the Frame-ontology definition of a Type
> (their "Class") is accepted, when the instances of a Type will *never*
> be the same as the members of the set that is that Type.  For
> generality and interoperability, we need to leave the most general
> "Type" underspecified.  As far as inheritance of properties goes, it
> will still behave the way it is expected to in SUMO, Cyc and 
> DOLCE, and
> OWL.    (013)

MW: And ISO 15926.
> 
> [MW] As for types and sets, why do they have to be mutually exclusive?
> You
> may want them like that in a 3D ontology, but why do you have 
> to impose
> that on me when we could leave that to later specific 3D/4D theories?
> Some 
> types are extensional anyway (e.g. real numbers).
> 
> They are not mutually exclusive, and no "disjoint" relation is
> specified in any ontology I know of.  In Cyc, SUMO, and 
> DOLCE, a Set is
> an instance of a Type (Collection, Class, Universal).  In the
> Frame-Ontology a Type is a subtype of a Set.  The definitions would be
> circular, if we didn't recognize different levels of definition -
> metatypes.  But the intended meaning of "Type" as used for the most
> general case in COSMO includes "Set" as an instance.  It would also be
> possible to create a subtype of "Type" (which itself is a metatype)
> that has axioms specifying that it is extensional.  I don't 
> see this as
> mutually exclusive.  But they are not identical.    (014)

MW: No I am happy set and type are not identical, just the types 4D folk
are interested in turn out to be sets (extensional).
> 
> Would there be a problem if we represented ISO15926 "Classes" as
> subtypes of the COSMO "Set"?    (015)

MW: What is going through my mind at the moment is playing around with
interpretations. If we can leave whether physical objects are 3D or 4D
until that stage then it really might be possible to share much of a
traditional type hierarchy. I'm just not sure how realistic that is.    (016)

> 
> I think we can find translations, if each ontology component is
> axiomatized in the same language.     (017)

MW: That would be the other approach.    (018)


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