Re: vocabulary for traditional sets

At 04:02 AM 11/6/01 -0600, Dan Connolly wrote:
>But I would like to be able to say that
>X and Y are sets, which allows you to conclude,
>from the fact that their extensions/membership
>are  the same that they are identical.

So far, OK.

>So I propose
>         rdfs:Set rdfs:subClassOf rdfs:Class.

I'm deeply suspicious of this.  It feels like a "layer violation" -- a 
class may be defined in terms of a set of values, but to define the set as 
a subclass of class feels wrong.

Hmmm... what does this imply:

   rdfs:Class rdf:type rdfs:Class .          [given by RDFS]

   <I(rdfs:Class),I(rdfs:Class)> in IEXT(I(rdf:type))

   rdfs:Set rdf:type rdfs:Class .            [subject of rdfs:subClassOf]

   <I(rdfs:Set),I(rdfs:Class)> in IEXT(I(rdf:type))

   x in ICEXT(I(rdfs:Set)) |= x in ICEXT(I(rdfs:Class))
                                             [meaning of rdfs:subClassOf]

   x in ICEXT(I(rdfs:Set)) |= EXISTS y = ICEXT(x)
                                             [Model theory class values are 
domain of IC]

So we have the denotation of a node with type rdfs:Set is some value x
such that ICEXT(x) are the members of the set.  I think you're trying to
add something like this:

   x,y in ICEXT(I(rdfs:Set)) and ICEXT(x) == ICEXT(y) |= x == y

this being the thing that distinguishes rdfs:Set from rdfs:Class.

(I'm not sure if this works if we require that the mapping from URIs to 
resources is 1:1 onto, as some people seem to claim.  The anyone says 
anything about anything means we can't prevent two people defining sets 
called (say) my:SetValue and your:SetValue that happen to contain the same 
members.  Now who is being inconsistent?)

...

>where
>         this log:forAll :x, :y.
>         { :x a rdfs:Set.
>         :y a rdfs:Set.
>         :x rdfs:subClassOf :y.
>         :y rdfs:subClassOf :x.
>         } log:implies {
>         :x ont:equivalentTo :y
>         }.

Rather than trying to define this broad notion of equivalence, why not 
introduce a notion of set equivalence that can be applied to the rdfs:Set 
subclass of rdfs:Class:

     set:equivalentTo rdfs:domain rdfs:Set .
     set:equivalentTo rdfs:range rdfs:Set .

     x set:equivalentTo y . |- y set:equivalentTo x .

     I(x set:equivalentTo y .)  if  <I(x),I(y)> in IEXT(I(set:equivalentTo))

     <I(x),I(y)> in IEXT(I(set:equivalentTo))
         iff ICEXT(I(x)) == ICEXT(I(y))
             and I(x) in ICEXT(I(rdfs:Set))
             and I(y) in ICEXT(I(rdfs:Set))

...

I can't say the above approach won't work, but...

My intuition about a set as opposed to a class is that the set simply is 
the denotation of a node, not "indirected" via ICEXT like a class.

E.g.

    I(my:PrimaryColour) = { I(my:red), I(my:green), I(my:blue) }

which does not have the same value structure as rdfs:Class.

Maybe it's the programmer in me... I tend to follow the programmers notion 
of type (e.g. described in Hoare's 1972 "Notes on Data Structuring" paper), 
in which a type (or class) designates not only a set of values, but also 
the operations on those types.  There is a richness of purpose here that is 
not true of simple sets;  having 'set' as a subclass of 'class' seems to go 
against this.  (Interestingly, I find it easier to see 'class' as a 
subclass of 'set'.)

...

And a parting shot:  the construction of classes allows a class value to be 
a member of its own extension.  Indeed, we have:

     I(rdfs:Class) in ICEXT(I(rdfs:Class))

Your proposal for rdfs:Set retains this structure, and nothing has been 
said to prevent a set value being a member of its own class extension.

#g


------------
Graham Klyne
GK@NineByNine.org

Received on Tuesday, 6 November 2001 09:25:59 UTC