Matthew,
My take: (01)
(1) Re: Type:
>> MW: I note that this is more general than Barry seems to be looking
for. (02)
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.
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? The basic axiom is the
one I gave that is used in SUMO. (03)
(<=>
(subclass ?SUBCLASS ?CLASS)
(and
(instance ?SUBCLASS SetOrClass)
(instance ?CLASS SetOrClass)
(forall (?INST)
(=>
(instance ?INST ?SUBCLASS)
(instance ?INST ?CLASS))))) (04)
. . . where "subclass" would be our "isaSubtypeOf" (or, "subtype"), a
transitive relation. (05)
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. (06)
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. (07)
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. (08)
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: (09)
http://www-ksl.stanford.edu/knowledge-sharing/ontologies/html/frame-ont
ology/CLASS.html (010)
In that proposal, a Class (their terminology) could be considered as a
set of tuples of length one: (011)
-------------------------
A class can be thought of as a collection of individuals. Formally, a
class is a unary relation, a set of tuples (lists) of length one. 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. (012)
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'. (013)
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.
. . .
--------------------------- (014)
. . so that if you absolutely must use set theory (and I can't think
of any reason why we must) 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. (015)
*******
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.
******* (016)
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. (017)
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. (018)
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. (019)
I really hope we can just consider Type and Set as different things. (020)
======================================
(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. (021)
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. (022)
Pat (023)
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 (024)
-----Original Message-----
From: ontac-dev-bounces@xxxxxxxxxxxxxx
[mailto:ontac-dev-bounces@xxxxxxxxxxxxxx] On Behalf Of West, Matthew R
SIPC-DFD/321
Sent: Saturday, January 28, 2006 4:27 AM
To: ONTAC Taxonomy-Ontology Development Discussion
Subject: RE: Categorization (was RE: [ontac-dev] Representation of
attributes) (025)
Dear Pat, (026)
See below. (027)
Regards (028)
Matthew West
Reference Data Architecture and Standards Manager
Shell International Petroleum Company Limited
Shell Centre, London SE1 7NA, United Kingdom (029)
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@xxxxxxxxx
http://www.shell.com
http://www.matthew-west.org.uk/ (030)
> -----Original Message-----
> From: ontac-dev-bounces@xxxxxxxxxxxxxx
> [mailto:ontac-dev-bounces@xxxxxxxxxxxxxx]On Behalf Of Cassidy,
Patrick
> J.
> Sent: 27 January 2006 18:03
> To: ONTAC Taxonomy-Ontology Development Discussion
> Subject: RE: Categorization (was RE: [ontac-dev] Representation of
> attributes)
>
>
> Chuck -
> We have already established usages within the COSMO ontology for
> those three terms:
>
> Type - the main intensional grouping for entities in the ontology
-
> see the discussion and vote. The formalization should be available
> soon. (031)
MW: I note that this is more general than Barry seems to be looking
for. (032)
> Class - not used in the COSMO, reserved for translations of the
> COSMO to OWL and other ontologies that use 'Class' in the same sense
> that we use 'Type'. In informal discussion it could be
> considered as a
> synonym of 'Type'.
> Set - used in the mathematical sense, by OpenCyc, SUMO, and DOLCE
-
> and in the present COSMO, accepting that intended meaning. (033)
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. (034)
MW: If we are having both of these, we presumably also need a
supertype. How
about Universal?
>
> Of course, these could be used informally as you suggest,
> but I think
> it would be best not to vary our usage, even in informal discussion
> within the ONTACWG. It may be hard to avoid the use of "set" in some
> sense other than the mathematical, but it might be worth trying. I
> would use "grouping" myself, just to avoid confusing conflict with
> established uses of other terms referring to multiple entities
> considered as a whole.
>
> 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
> (035)
_________________________________________________________________
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 (036)
|