W3C home > Mailing lists > Public > semantic-web@w3.org > August 2008

Re: singleton sets

From: Frank Manola <fmanola@acm.org>
Date: Wed, 13 Aug 2008 17:07:54 -0400
To: Ian Emmons <iemmons@bbn.com>
Message-Id: <D9407362-9907-4F9B-8F3D-2BF796891F0A@acm.org>
Cc: Semantic Web at W3C <semantic-web@w3.org>


+1 to concrete examples!  (This is why I referred to section 3.1.3 of  
the OWL Guide in a (much) earlier response.)  As you note, it's  
possible to raise questions about the need for this modeling technique  
in specific examples, but it's often useful (and natural).


On Aug 13, 2008, at 3:20 PM, Ian Emmons wrote:

> Frank,
> Thanks for making this distinction clear -- I had a suspicion that  
> the discussion was confusing these concepts, but I skipped several  
> of the intervening messages, and I wasn't sure.
> This may or may not be a useful interjection, but the level of  
> abstraction in this discussion is a little high, so I thought a  
> concrete example might help.  I encountered a situation where "X   
> type  Y;  X  subClassOf  Z;" seemed to be useful.  Our application  
> modeled transportation assets, and it also drew its data from a  
> relational database.  So, we had a table of vehicles that had (in  
> the ugly manner of an RDB) a column VehicleType, which contained one  
> of an enumerated list of possible types (1 for truck, 2 for cargo  
> plane, 3 for containerized cargo ship, etc.).  Once a row from this  
> table was translated into RDF, we wanted to classify the type of  
> vehicle via an RDF class, so we created a taxonomy of vehicle  
> classes with an entry for each of the enumerated vehicle types.   
> This yields the following:
>    x type V;  V subClassOf Vehicle;
> Where things got messy was when we realized that our RDF  
> representation needed to retain the enumerated vehicle type code.   
> To do this we added the type code as a data type property of the  
> vehicle class, like so:
>    x type V;  V subClassOf Vehicle;  V hasTypeCode t;
> As we usually do, we gave the hasTypeCode property a domain  
> (EnumeratedVehicleType), and so the obvious inference yields the  
> following:
>    x type V;  V subClassOf Vehicle;  V hasTypeCode t;  V type  
> EnumeratedVehicleType;
> In particular:
>    V subClassOf Vehicle;  V type EnumeratedVehicleType;
> I'm sure we could have modeled this differently so as to eliminate  
> the subclass-and-type pattern, but this seemed to be the nicest way  
> to handle it to us.  Hopefully it's a compelling use case for this  
> discussion.
> Cheers,
> Ian
> On Aug 13, 2008, at 10:59 AM, Frank Manola wrote:
> On Aug 12, 2008, at 5:05 PM, Richard H. McCullough wrote:
>> Here's someone else who doesn't like singleton sets,
>> and hence doesn't like classes which are individuals.
>> John Barwise & John Etchemendy (1992), "The Language of First-Order  
>> Logic",
>> Third Edition, Revised & Expanded, Center for the Study of Language  
>> and Information, Stanford, Page 212
>> Suppose there is one and only one object x satisfying P(x).   
>> According to the
>> Axiom of Comprehension, there is a set, call it a, whose only  
>> member is x. That is,
>> a = {x}.  Some students are tempted to think that a = x..  But in  
>> that direction lies,
>> if not madness, at least dreadful confusion.  After all, a is a set  
>> (an abstract object)
>> and x might have been any object at all, say Stanford's Hoover  
>> Tower. Hoover is
>> a physical object, not a set.  So we must not confuse an object x  
>> with the set {x},
>> called the singleton set containing x.  Even if x is a set, we must  
>> not confuse it with
>> its own singleton.  For example, x might have any number of  
>> elements in it, but {x}
>> has exactly one element: x.
> Whoa!  What we were originally talking about wasn't singleton sets,  
> it was the following question:
>>>>>> 2. X  type  Y;  X  subClassOf  Z;
>>>>>> Another neat property: X is an individual and a class.
>>>>>> Now I can ... What?  I don't know.
>>>>>> Why do you want to do that?
> Wanting to be able to treat a class X as an individual may or may  
> not be a good idea, but this isn't the same as wanting to treat a  
> singleton set as *the same* individual as its only member.  To  
> paraphrase your quotation above, in the direction of subtle subject  
> changes like this lies, if not madness, at least dreadful confusion.
> --Frank
Received on Wednesday, 13 August 2008 21:08:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:49:44 UTC