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? (01)
[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. 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. (02)
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. (03)
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. (04)
[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). (05)
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. (06)
Would there be a problem if we represented ISO15926 "Classes" as
subtypes of the COSMO "Set"? (07)
I think we can find translations, if each ontology component is
axiomatized in the same language. (08)
Pat (09)
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 (010)
_________________________________________________________________
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 (011)
|