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? (01)
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. (02)
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). (03)
I may have time later tonight to add to this. (04)
Pat (05)
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 (06)
-----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) (07)
Dear Pat, (08)
See below. (09)
Regards (010)
Matthew West
Reference Data Architecture and Standards Manager
Shell International Petroleum Company Limited
Shell Centre, London SE1 7NA, United Kingdom (011)
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@xxxxxxxxx
http://www.shell.com
http://www.matthew-west.org.uk/ (012)
> -----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. (013)
MW: Class in ISO 15926 is broader, it doesn't insist on the intensional
bit. (014)
> 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? (015)
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). (016)
> 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. (017)
MW: None of these are problematic (for the more general thing I have in (018)
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. (019)
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. (020)
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. (021)
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: (022)
MW: Please No!
>
> -------------------------
> A class can be thought of as a collection of individuals. (023)
MW: This is OK, but what does "collection" mean? I would just say all
types
are collections. (024)
> Formally, a
> class is a unary relation, a set of tuples (lists) of length one. (025)
MW: This is about representation in a formalism, not what it is. (026)
> 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) (027)
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 ... (028)
MW: I'm not trying to insist that they are sets for you. Only that they
can be for me. (029)
> 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. (030)
MW: Why? (why is it different, and why the restriction on
interpretations?) (031)
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. (032)
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? (033)
> *******
>
> 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. (034)
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. (035)
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. (036)
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. (037)
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. (038)
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? (039)
_________________________________________________________________
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/OntologyTaxonomyCoordinatin
gWG (040)
_________________________________________________________________
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 (041)
|