W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2002

Re: Datatyping literals: question and test cases

From: pat hayes <phayes@ai.uwf.edu>
Date: Thu, 31 Oct 2002 16:58:46 -0600
Message-Id: <p05111b24b9e75fcaf407@[65.217.30.130]>
To: "Patrick Stickler" <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org, ht@cogsci.ed.ac.uk (Henry S. Thompson)

>[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, 
>patrick.stickler@nokia.com]
>
>
>----- Original Message -----
>From: "ext pat hayes" <phayes@ai.uwf.edu>
>To: "Patrick Stickler" <patrick.stickler@nokia.com>
>Cc: <w3c-rdfcore-wg@w3.org>
>Sent: 31 October, 2002 21:32
>Subject: Re: Datatyping literals: question and test cases
>
>
>>  >[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690,
>>  >patrick.stickler@nokia.com]
>>  >
>>  >
>>  >>  >Inlined literals and rdfs:range will *never* work together, except
>>  >>  >in the single case of rdfs:StringLiteral. I wonder if folks appreciate
>>  >>  >that oddity.
>>  >>
>>  >>  You seem to be assuming that it is impossible for two different
>>  >>  datatypes to have the same value space.
>>  >
>>  >Not at all. But see below.
>>  >
>>  >>  I wasn't aware that this was
>>  >>  a general rule. I would have no problem for example saying that
>>  >>  rdfs:StringLiteral and xsd:String had the same value space. (NOt the
>>  >>  same lexical space, but the same value space.)
>>  >
>>  >I am presuming, perhaps incorrectly, that for one value space
>>  >to intersect with another value space that for any two values
>>  >X and Y which occur in the intersection of those value spaces
>>  >the same relations hold for them in terms of either datatype.
>>  >
>>  >I.e., if X < Y in datatype 1 then X < Y in datatype 2.
>>  >
>>  >If one datatype has an ordered value space and the other does
>>  >not, then can they really intersect?
>>
>>  Well, what does it mean to say that the space doesn't have an
>>  ordering? I mean, its not *impossible* to define an ordering on
>>  URIrefs.
>
>No, but it's a matter of authority. If the "owner" of the datatype
>(the agency that has the authority to define it) says there is no
>ordering for the members of its value space, then it doesn't have
>an ordering.

I can't make sense of this. It sounds to me like saying that because 
Im not interested in the colors of the bindings of my books, that 
therefore they have no colors. Look, I can take one of these 
unordered value spaces and *I* can define an ordering on it. Of 
course it *has* an ordering. In fact, if its finite with cardinality 
N, it has N-factorial orderings. Authority is fine, but its unwise to 
claim authority over Platonic abstractions.

>
>>  I think you have a picture here where a 'space' is something
>>  like an algebra, ie a set together with some operations or relations
>>  on the set, rather than simply a set or class of things.
>
>That is my understanding of how XML Schema defines datatypes as
>well. As sets with relations on the sets, and subsets share the
>relations of their supersets.

But that doesn't jibe with the RDF picture.  RDF class extensions are 
just sets . They aren't OO inheritance taxonomies: they don't come 
with anything to get inherited.

>
>>  Two
>>  different algebras can have the same underlying set. (I think its
>>  called the 'carrier' of the algebra, but it was years ago :-)
>>
>>  >If X = Y in one value space yet X != Y in the other value space
>>  >can they really intersect?
>>
>>  Well, not if that really means identity, but then if it meant that,
>>  this would be impossible.
>
>Exactly. And that is my point. xsd:string defines a different equality
>than xsd:anyURI and therefore they cannot intersect.

No, there is no such thing as 'different equality' in classes. 
Equality is equality: it means, the same thing. It doesn't come in 
flavors.

>And in fact, the recent feedback from the XML Schema WG indicates
>that their value spaces are in fact disjunct.

Well, yes, I wrote back to Henry about that. I don't think what he 
said makes sense, given the wording in the XSD spec.

>
>>  >
>>  >I think not, in both cases.
>>  >
>>  >Since I do not consider the value space of rdfs:StringLiteral
>>  >to be ordered, then I do not see that it can intersect with
>>  >that of xsd:string.
>>
>>  HOw about saying that xsd:string has an ordering defined on it which
>>  isnt relevant to rdfs:StringLiteral?
>
>Well, I may be viewing this wrongly, and certainly this is not my
>strongest area, but I'm thinking along the lines that relations
>between members of a value space are characteristics of the values
>themselves and not contextual for the datatype.

Well, OK, we could go there. But then xsd:integer wouldn't contain 
integers, for example. They would be integers-with-a-particular 
ordering, to be distinguished carefully from 
integers-with-a-different-ordering. I really don't think this would 
work in RDF: in effect, it forces all class extensions to be 
disjoint, since the 'things' in the class inherit their class-ness. 
People-as-family-members are different *things* from 
people-as-mammals or people-as-employees. Yuk.

>I.e. they are members
>of that value space because they exhibit those characteristics, and
>they will exibit those characteristics in whatever value space or
>subset thereof in which they occur. If there is some other "thing"
>which does not exibit the same characteristics, no matter how similar,
>it is not the same thing. Thus even though one may think that the
>string "foo:bar" is just like the URI "foo:bar" we can test that
>they are differen

Well, they sure *look* the same. How do you tell the difference, when 
you see them in isolation? The URI documents say explicitly that URIs 
are character strings in several places, in fact: they even tell you 
which characters you can use in them. Dave's syntax document has a 
BNF for them.

>, that they are different things, because they
>exhibit different characteristics in relation to other things in
>the universe.

That begs the question, because if we take your view then there are 
more things in the universe.

>
>>  The reason for being so careful about this terminology is that the
>>  operations are defined on the whole space, sure; but the things IN
>>  the space are just what they happen to be, which ever category you
>  > put them into. So with the operations-over-the-carrier-set picture,
>>  any particular rdfs:StringLiteral is indeed an xsd:string and vice
>>  versa, even if it makes sense to distinguish the two classes for some
>>  'global' reason.
>
>I may be wrong, but I'm not viewing them as the same thing.

Well, can you tell me how to tell them apart? When my email editor 
recognizes a URI and highlights it in blue, does it stop being a 
character sequence? It still seems to *act* like a character sequence 
as far as the editor is concerned.

Or is the 'real' URI in an abstract space somewhere, and the 
character sequences just surface lexical forms for rendering it, or 
something? Then we have a lot more classes to consider, and RDF/XML 
denotation is at least a two-step matter (xml syntax -to- uri -to- 
denotation) instead of simple denotation. Im not even sure if two are 
enough. We would have to rewrite the entire spec if we take this 
seriously.

>  > This is the 'weak typing' view Im giving you here, of ocurse.
>
>Ahhh, right. I'm definitely taking a strong typing view.

The problem is, seems to me that the 'weak' view is kind of built 
into RDF (and all the rest of them: DAML, OIL, OWL,...) These are 
logics for reasoning about categories, not OO modelling languages. 
There is a fundamental clash between thinking of classes as Venn 
diagrams and thinking of them like an OO method-inheritance taxonomy. 
Strong typing only makes sense in the second way of thinking.

>Patrick

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam
Received on Thursday, 31 October 2002 17:59:04 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:52:36 EDT