- From: Graham Klyne <GK@ninebynine.org>
- Date: Tue, 06 Nov 2001 12:45:48 +0000
- To: Dan Connolly <connolly@w3.org>
- Cc: www-rdf-comments@w3.org
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