Re: singleton sets

Hi Ian

This is a nice illustration of the problems that arise when
"extra" classes of the form XType, YType, ... are created.  
This unnecessarily "corrupts" the concept hierarchy.

A simple alternative is to use sets or enums.
In this case, I recommend:

    EnumeratedVehicleType isany truck, cargo plane, ...;   # enum
    V isalt EnumeratedVehicleType;              # alternative

If you want to use sets:

    EnumeratedVehicleType isall  truck, cargo plane, ...;  # set
    V ismem EnumeratedVehicleType;         # member

Dick McCullough
Ayn Rand do speak od mKR done;
mKE do enhance od Real Intelligence done;
knowledge := man do identify od existent done;
knowledge haspart proposition list;
http://mKRmKE.org/

----- Original Message ----- 
From: "Ian Emmons" <iemmons@bbn.com>
To: "Semantic Web at W3C" <semantic-web@w3.org>
Sent: Wednesday, August 13, 2008 12:20 PM
Subject: Re: singleton sets


> 
> 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 23:06:02 UTC