ontac-forum
[Top] [All Lists]

RE: [ontac-forum] Type vs. Class - last chance to vote.

To: <rick@xxxxxxxxxxxxxx>, "ONTAC-WG General Discussion" <ontac-forum@xxxxxxxxxxxxxx>
Cc:
From: "Cassidy, Patrick J." <pcassidy@xxxxxxxxx>
Date: Sun, 22 Jan 2006 13:16:32 -0500
Message-id: <6ACD6742E291AF459206FFF2897764BE815902@xxxxxxxxxxxxxxxxx>
Richard,
  Just a note to clarify two points:
  (1)[RM]  I don't know anything about OpenCyc, but 
I'm guessing that Collection must mean something different than 
rdfs:Class because the RDF Schema differentiates class from collection.    (01)

"#$Collection" in Cyc means, as best I can tell, exactly the same thing
as "Class" in SUMO and OWL -- i.e. it behaves computationally exactly
as those classes do: a subcollection relation in Cyc ("genls") is
transitive, and the instances propagate up the class hierarchy.  It
looks like a class, walks like a class, and quacks like a class.  Cyc
actually calls it a "class":    (02)

>From OpenCyc 0.7:    (03)

OPENCYC: MAY 23, 2002 "Collection"
The collection of all Cyc collections. Cyc collections are natural
kinds or classes, as opposed to mathematical sets; their instances have
some common attribute(s). Each Cyc collection is like a set in so far
as it may have elements, subsets, and supersets, and may not have parts
or spatial or temporal properties. Sets, however, differ from
collections in that a mathematical set may be an arbitrary set of
things which have nothing in common (see #$Set-Mathematical). In
contrast, the instances of a collection will all have in common some
feature(s), some `intensional' qualities. In addition, two instances of
#$Collection can be co-extensional (i.e., have all the same instances)
without being identical, whereas if two arbitrary sets had the same
elements, they would be considered equal. As with any Cyc constant, an
instance of #$Collection should be created only if it is expected to
have some purpose or utility. Moreover, the `best' collections to
create are the ones which are impossible to define precisely, yet about
which there are rules and other things to say. E.g., `WhiteCat' is not
a good element of #$Collection to create, because it's easy to define
with other Cyc concepts, and there's not much to say about the
collection of white cats; but `WhiteCollarWorker'; could be a good
instance of #$Collection, because it is hard to define exactly, yet
there are many things to say about it.     (04)


A "collection" in OWL, however, is something different.    (05)

We know there are terminology differences among the various ontology
builders, and in the indented list for Toplevel2:
   http://colab.cim3.net/cgi-bin/wiki.pl?CosmoWG/TopLevel2
. . .  I have tried to indicate such variation where there appears to
be classes having the same intended meaning but labeled differently.
  In the formal COSMO we will use for inferencing, I plan to cut back
each name to a single unique name for each such class.  This will make
everyone unhappy, but is probably better than living with those long
aggregated names.  If members want to keep the long aggregated names,
we can decide that as a group.  But the multiple origins of those
classes will be indicated in the comments, they don't have to also be
in the name - this is just a device for the indented list which has no
comments directly appended to each entry.    (06)


(2) Voting procedure
[RM] >> Also, I think it's a useful development that we're voting. Have
we 
considered adopting the Apache voting approach?    (07)

  We can adopt formal and more structured voting if the members think
it worthwhile.  I would suggest we spend no time on this issue right
now and see how the less formal votes work as we try to make some
progress on actual ontology-building (closer to ontology-element
choosing).  As soon as it appears important, feel free to bring it up
as a formal issue to decide.    (08)

  The current vote count is:
   Type   10
   Class   7.    (09)

  I will aggregate and report the result at midnight EST tonight.    (010)

Pat    (011)

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    (012)


-----Original Message-----
From: ontac-forum-bounces@xxxxxxxxxxxxxx
[mailto:ontac-forum-bounces@xxxxxxxxxxxxxx] On Behalf Of richard murphy
Sent: Saturday, January 21, 2006 8:32 PM
To: ONTAC-WG General Discussion
Subject: Re: [ontac-forum] Type vs. Class - last chance to vote.    (013)

Hi Pat:    (014)

A few points from a respectful student of all the great work going on 
here. I'm getting an education money can't buy here at ONTAC and thanks    (015)

to all who contribute to this list.    (016)

I'm with Chris Menzel and Michael Gruninger even without the CL axioms.    (017)

rdf:type means something different than Type in Information Flow speak 
and I think semiotics as well. I don't know anything about OpenCyc, but    (018)

I'm guessing that Collection must mean something different than 
rdfs:Class because the RDF Schema differentiates class from collection.    (019)

See http://www.w3.org/TR/rdf-schema/#ch_type    (020)

More importantly, it seems to me like we're at the meta-level of
solving 
a recurring problem and there's a pattern here and maybe a pattern 
language to evolve: language, logic, theory, and model. Seems like
we're 
still faced with symbolic representation in different languages that 
require truth mappings to the conceptualizations they represent.    (021)

Also, I think it's a useful development that we're voting. Have we 
considered adopting the Apache voting approach?    (022)

http://www.apache.org/foundation/voting.html    (023)

-- 
Best wishes,    (024)

Rick    (025)

email:  rick@xxxxxxxxxxxxxx
web:    http://www.rickmurphy.org
cell:   703-201-9129    (026)

Cassidy, Patrick J. wrote:
> In order to resolve a terminological question, we are in the process
of
> voting whether to use the term "Type" or "Class" to refer to those
> intensionally-defined groupings called:
> 
>   Class in Ontolingua and Protege
>   Class in RDF and OWL
>   Class in SUMO
>   Collection   in OpenCyc
>   Universal    in DOLCE
>   Property in Ontology Works' IODE system
>   ---------------
> 
> The only contenders put forward are:
>    Type
>    Class
> 
>    if "type" then  the subsumption relation will be subtype
>    if "class" then the subsumption relation will be subclass
> 
> 
>  Thus far the preferences expressed have been:
>    Type  10
>    Class  4
> 
> I will tally the vote on Sunday night (Jan. 22nd).
> If you have any preference and haven't yet voted, send me a note
> directly:
> 
>     pcassidy@xxxxxxxxx
> 
> 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
>  
> _________________________________________________________________
> Message Archives: http://colab.cim3.net/forum/ontac-forum/
> To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
> Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-forum/
> Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
> Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatin
gWG
> 
> 
>     (027)



_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatin
gWG    (028)

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