Dear Pat, (01)
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? (02)
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). (03)
Regards (04)
Matthew (05)
> -----Original Message-----
> From: ontac-dev-bounces@xxxxxxxxxxxxxx
> [mailto:ontac-dev-bounces@xxxxxxxxxxxxxx]On Behalf Of Cassidy, Patrick
> J.
> Sent: 30 January 2006 17:18
> To: ONTAC Taxonomy-Ontology Development Discussion
> Subject: RE: Categorization (was RE: [ontac-dev] Representation of
> attributes)
>
>
> Matthew,
> Just to give one quick answer for the moment:
> [MW] >> MW: What for you is the distinctive difference in nature
> between being
> an instance of a set and being an instance of a type?
>
> The characteristic of an intensionally defined Type as I believe it is
> used in OpenCyc, SUMO, and DOLCE is that the membership can be defined
> in such a way that it changes with context. A real-world
> time interval
> is only one of many contexts that can affect the membership of a Type,
> though it is the most salient context when 3-D objects are
> represented.
> I think that the representation and use of contexts will differ for
> Types defined intensionally and ISO15926 classes defined extensionally
> as sets. There will probably be an accurate translation, but it would
> take some time to work out the details.
>
> Mathematical sets are represented in Cyc, SUMO, and DOLCE, and if
> ISO15926 classes are sets, then each of those classes would be
> presumably an instance of "Set" in COSMO. How difficult it
> would be to
> find a translation depends on the way specific ISO15926 classes are
> represented and axiomatized (or otherwise defined).
>
> I may have time later tonight to add to this.
>
> Pat
>
>
> Patrick Cassidy
> MITRE Corporation
> 260 Industrial Way
> Eatontown, NJ 07724
> Mail Stop: MNJE
> Phone: 732-578-6340
> Cell: 908-565-4053
> Fax: 732-578-6012
> Email: pcassidy@xxxxxxxxx
>
>
> -----Original Message-----
> From: ontac-dev-bounces@xxxxxxxxxxxxxx
> [mailto:ontac-dev-bounces@xxxxxxxxxxxxxx] On Behalf Of West, Matthew R
> SIPC-DFD/321
> Sent: Monday, January 30, 2006 4:47 AM
> To: ONTAC Taxonomy-Ontology Development Discussion
> Subject: RE: Categorization (was RE: [ontac-dev] Representation of
> attributes)
>
> Dear Pat,
>
> See below.
>
>
> Regards
>
> Matthew West
> Reference Data Architecture and Standards Manager
> Shell International Petroleum Company Limited
> Shell Centre, London SE1 7NA, United Kingdom
>
> Tel: +44 20 7934 4490 Mobile: +44 7796 336538
> Email: matthew.west@xxxxxxxxx
> http://www.shell.com
> http://www.matthew-west.org.uk/
>
>
> > -----Original Message-----
> > From: ontac-dev-bounces@xxxxxxxxxxxxxx
> > [mailto:ontac-dev-bounces@xxxxxxxxxxxxxx]On Behalf Of Cassidy,
> Patrick
> > J.
> > Sent: 28 January 2006 17:30
> > To: ONTAC Taxonomy-Ontology Development Discussion
> > Subject: RE: Categorization (was RE: [ontac-dev] Representation of
> > attributes)
> >
> >
> > Matthew,
> > My take:
> >
> > (1) Re: Type:
> > >> MW: I note that this is more general than Barry seems to be
> looking
> > for.
> >
> > The basic function of Type as I understand what we are aiming at is
> to
> > serve as an intensional grouping to which we can assign attributes
> and
> > relations which inherit down to subtypes. This serves the same
> > function as Class etc, and I have not noticed any variation in usage
> > for that basic thingy in any ontology I have examined (though I am
> > still shaky on usage in ISO15926), though it has different names.
>
> MW: Class in ISO 15926 is broader, it doesn't insist on the
> intensional
> bit.
>
> > Instances of a subtype are also instances of all parent types (and
> > ancestor types, subtype being transitive), and any attribute or
> > property assigned to all instances the parent type inherit down to
> > instances of the subtypes. That is the basic functionality needed
> for
> > that thingy (whatever it is called), and I thought that was long
> > settled. Is there actually any disagreement?
>
> MW: But all that is true for the broader object ISO 15926 recognises.
> (But of course the ISO 15926 object is extensional, so you will need
> something even broader that is not).
>
> > The basic axiom is the
> > one I gave that is used in SUMO.
> >
> > (<=>
> > (subclass ?SUBCLASS ?CLASS)
> > (and
> > (instance ?SUBCLASS SetOrClass)
> > (instance ?CLASS SetOrClass)
> > (forall (?INST)
> > (=>
> > (instance ?INST ?SUBCLASS)
> > (instance ?INST ?CLASS)))))
> >
> > . . . where "subclass" would be our "isaSubtypeOf" (or, "subtype"),
> a
> > transitive relation.
>
> MW: None of these are problematic (for the more general thing
> I have in
>
> mind)
> >
> > The other essential characteristic of a Type is that it is
> a grouping
> > (whatever one wants to call it), and has a cardinality, which can be
> > zero. Of course, we may not know the cardinality and it can change
> > over time, but in any given context (e.g. time interval -
> > assuming time
> > is relevant to the definition of a particular Type and its
> > instances),
> > it will have some cardinality.
>
> MW: Again not problematic.
> >
> > Types differ in behavior from mathematical sets. The latter are
> > identical if they have the same instances, but there can be many
> > different Types with the same instances. This has been the accepted
> > understanding for a long time to the extent that I am aware,
> > and is the
> > reason why Types (or their equivalents, Class or Universal) are
> > distinguished from mathematical sets in Cyc, SUMO, and DOLCE.
>
> MW: And this is a key difference between 3D and 4D (or at least our
> approach to it).
> >
> > An instance of a Type is not the same as a member of a mathematical
> > set. However, the cardinality of a Type is the same as the
> number of
> > its instances, which are **not** set-theoretic members of the Type.
>
> MW: What for you is the distinctive difference in nature between being
> an instance of a set and being an instance of a type?
> >
> > If we must at some point consider how to represent Types as
> some kind
> > of mathematical "set", there was a proposal in the Ontolingua
> > Frame-Ontology:
> >
> > http://www-ksl.stanford.edu/knowledge-sharing/ontologies/html/
> > frame-ont
> > ology/CLASS.html
> >
> > In that proposal, a Class (their terminology) could be considered as
> a
> > set of tuples of length one:
>
> MW: Please No!
> >
> > -------------------------
> > A class can be thought of as a collection of individuals.
>
> MW: This is OK, but what does "collection" mean? I would just say all
> types
> are collections.
>
> > Formally, a
> > class is a unary relation, a set of tuples (lists) of length one.
>
> MW: This is about representation in a formalism, not what it is.
>
> > Each
> > tuple contains an object which is said to be an instance of the
> class.
> > An individual, or object, is any identifiable entity in the
> > universe of
> > discourse (anything that can be denoted by a object
> constant in KIF),
> > including classes themselves.
> >
> > The notion of CLASS is introduced in addition to the relation
> > vocabulary because of the importance of classes and types in
> knowledge
> > representation practice. The notion of class and relation are
> > merged to
> > unify relational and object-centered representational conventions.
> > Classes serve the role of `sorts' and `types'.
> >
> > There is no first-order distinction between classes and unary
> > relations. One is free to define a second-order predicate that makes
> > the distinction. For example, (predicate C) could mean that
> the unary
> > relation C should be thought of more as a property than as a
> > collection
> > of individuals over which one might quantify some statement.
> > Logically,
> > all such predicates would still be instances of the
> metaclass CLASS.
> > . . .
> > ---------------------------
> >
> > . . so that if you absolutely must use set theory (and I can't
> think
> > of any reason why we must)
>
> MW: If you want to exclude 4D then this is one of the fastest ways to
> do
> it. If you take a 4D view, it turns out that the things that you think
> of
> as types turn out to have the same properties as sets. So if it quacks
> like
> a duck ...
>
> MW: I'm not trying to insist that they are sets for you. Only
> that they
> can be for me.
>
> > then you can define a "Type" as a "Set" of
> > tuples of length one, and the instances are the elements which are
> > contained in each tuple, but the instances are not the tuples
> > themselves. The tuples are the "members" of the set.
> >
> > *******
> > The critical point is that being an instance of a Type is not the
> same
> > as being a member of a mathematical set, in any interpretation.
>
> MW: Why? (why is it different, and why the restriction on
> interpretations?)
>
> MW: One of the things I think we might get a lot of mileage out of is
> allowing different interpretations. Actually it is the only way I can
> see
> of having a common object of rabbit (say) is if 3D people are allowed
> to
> interpret it has being a bunch of 3D furry animals, and 4D people are
> allowed to interpret it as a bunch of 4D furry animals.
>
> MW: So a question to John Sowa. How do interpretations fit into the
> lattice
> of theories? When and how do they get attached to an ontology?
>
> > *******
> >
> > Of course, it is possible to define a set which happens to contain
> the
> > same members as the instances of a Type. But that set
> would not be a
> > Type, it would be a set, which is distinct from the Type.
>
> MW: Why? Why does it have to be distinct (I am happy that it
> can be for
> you, but why do you have to impose that on me?)
> >
> > Now, if we must, *must*, **must** define a "Type" as a type of
> > mathematical set, according to the above interpretation, then "Type"
> > would be a subset of "Set" as described by the Frame-Ontology. But
> as
> > we have noted, Cyc, SUMO and DOLCE are content to leave the
> notion of
> > "Collection", "Class" or "Universal" as a primitive, not thus
> defined,
> > and the inferential behavior, which is what is important for
> > reasoning,
> > is defined by the axioms that relate instances to Types, as above.
>
> MW: I'm happy that we need something broader than set
> (something whose
> identity is defined by the extension of its instances) to accomodate
> the
> 3D position (though 4D folk don't need that).
> >
> > I think that to try to relate Types to sets will add
> > unnecessary axioms
> > to the ontology, probably lead to a lot of discussion which has no
> > impact on the performance of the ontology (except, perhaps
> to degrade
> > the performance if we add superfluous axioms to specify that
> > relation),
> > and take up time which could be used for other issues that have real
> > impact on how the ontology will perform.
>
> MW: The most important thing that will impact on how the ontology
> performs
> is whether it is right or not (or more precisely how accurate it is).
> >
> > I really hope we can just consider Type and Set as
> different things.
>
> MW: Different (for you), but not necessarily disjoint (for me).
> >
> > ======================================
> > (2) Re: Set
> > MW: There is quite a lot to do here too. By set do you just mean
> > anything
> > defined by its extension (e.g. non-well-founded sets)? Or
> do you mean
> > the
> > stricter sets of standard set theory? We will I think need both.
> >
> >
> > Since there are two (or more) interpretations of "Set" used by
> > Mathematicians, then we should have a general "Set" and specific
> > subtypes, with more specific names ("Set-ZF", "Set-VNBG",
> > "Set-NonWellFounded", whatever) defined according to the meanings
> > attached to them by those who are knowledgeable. But I
> > didn't think we
> > were going to get into set theory in these discussions, since
> > it is not
> > necessary to do the knowledge representation and reasoning
> > that will be
> > the main purpose of having a COSMO. The main structural
> > element of the
> > COSMO is the Type, not the Set. If it turns out that there is
> nothing
> > in common for all of those specific subtypes of "Set" then the
> general
> > Type "Set" can be a mere union of the more specific types. I don't
> > know enough to argue the merits of what kinds of sets should be
> > represented and didn't think that this was a topic that needed
> > discussion at this point, since the axiomatic definition of
> > "Type" does
> > not depend, for computational inferencing purposes, on what
> > mathematicians think Sets should be. OpenCyc 0.7 has no
> > subclasses for
> > the general "Set" and SUMO has only one - "FiniteSet". If it
> > turns out
> > that different kinds of mathematical sets are required to be able to
> > specify meanings in domain ontologies, then we will probably need to
> > worry about the specifics of mathematical set theory at some
> > point, but
> > I think we have more immediate concerns that are of broader
> > consequence
> > that we should discuss first.
>
> MW: That depends on what you are trying to do. Are you trying to build
> Yet Another Upper Ontology, or something that will enable the existing
> ontologies to interoperate?
>
>
> _________________________________________________________________
> 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/OntologyTaxonomyCo
ordinatin
gWG (06)
_________________________________________________________________
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 (07)
_________________________________________________________________
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 (08)
|