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

Re: Datatyping literals: question and test cases

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Fri, 01 Nov 2002 10:08:07 +0000
Message-Id: <>
To: "Patrick Stickler" <patrick.stickler@nokia.com>, "ext pat hayes" <phayes@ai.uwf.edu>
Cc: <w3c-rdfcore-wg@w3.org>, "Henry S. Thompson" <ht@cogsci.ed.ac.uk>

I'm not sure where this thread is going, but it has "test cases" in the 
subject line.

What test case are we discussing here?


At 09:48 01/11/2002 +0200, Patrick Stickler wrote:

>[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, 
>----- Original Message -----
>From: "ext pat hayes" <phayes@ai.uwf.edu>
>To: "Patrick Stickler" <patrick.stickler@nokia.com>
>Cc: <w3c-rdfcore-wg@w3.org>; "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
>Sent: 01 November, 2002 00:58
>Subject: Re: Datatyping literals: question and test cases
> > >[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.
>Sorry, Pat. No.
>If we want the SW to be non-monotonic, then folks are not licensed
>to change the semantics of resources they don't "own", otherwise
>interoperability goes right down the toilet.
>Of course, applications are free to do whatever they like, even
>assert value-based semantics on inlined literals ;-) but there needs
>to be the full realization that diverging from the authoritatively
>specified semantics means not playing by the rules and that the
>conclusions of your system may very well differ from everyone else's.
>If you don't care about that, fine. But in the context of a standard,
>and interoperability based on that standard, we need to be clear
>about this.
>Thus, adding order to a non-ordered datatype is not licensed and
>bad practice and will be detrimental to the SW (which IMO is all
>about consistent semantics and interoperability).
>If the anemically defined datatype not having order doesn't do it
>for you, then feel free to define your own. But don't presume that
>anyone else is going to respect the ordering you assert for someone
>else's datatype.
> > >
> > >>  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.
>Perhaps you misunderstand me.
>Yes, RDF class extensions are just sets. Therefore relations between
>members of those sets are based on inherent characteristics of the
>things in those sets, and if those things also belong to other sets,
>then they are the same things and will exhibit the same relations
>to any other thing which also occurs in the same sets.
>So, if we have set A and the members X and Y and X < Y and we also
>have set B and X and Y are also members of set B then X < Y in B
>as well, not because B specifies it but because of what X and Y are
>and those relationships hold between X and Y no matter where X and
>Y occur together.
>So this is why "foo:bar"^^xsd:string != "foo:bar"^^xsd:anyURI, because
>those two different things behave differently, they have different
>inherent characteristics.
> > >
> > >>  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.
>You misunderstand me, and I think agree. If we have A{X, Y} and
>B{X, Y} and in A, X = Y and in B, X != Y then it is fair to conclude
>that in fact X and/or Y are ambiguous and that we are talking about
>different things.
> > >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 look forward to his reply. If he doesn't CC me or the list, please
>pass it on. Thanks.
> > >
> > >>  >
> > >>  >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 don't think so.
>If you have two people (things) that have a given relationship (e.g. married)
>then that relationship holds whether those two people are considered as
>members of the set mamals, employees, etc. It may be that that relationship
>is not relevant to the particular set, but it still holds. The two people
>do not cease to be married just because marriage is not relevant to 
>as mammals. Eh?
>These are characteristics/properties of things in the universe, not of the
>sets in which those things are placed in.
>Yet it is the set by which we define which relations and characteristics
>are interesting from a particular point of view. Things are in sets because
>the *have* certain characteristics, but it is not membership in the set
>that gives them those characteristics, nor do they only have those
>characteristics only when considered form the perspective of a particular
>I'm still "male" even when considered as a member of the set "employee"
>even though the perspective of that set is gender neutral.
>In essence, I view RDF classes akin to Java interfaces. They allow me
>to interact with things from a particular perspective, and knowing that
>that thing conforms to the interface (is a member of that class) I know
>that it embodies the characteristics that are interesting with regards
>to that interface (class) -- but those characteristics are inherent in
>the thing irregardless of the interface.
> > >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.
>The URI documents unfortunately blur the lexical and value distinction.
>That is a shortcoming of those specifications which we need not repeat.
>Where they speak of serialization, they talk in terms of lexical
>forms. Where they speak of equivalence, they talk in terms of
>values. The ambiguity is unfortunate.
> > >, 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.
>Well, some folks were thinking that the value spaces of xsd:anyURI
>and xsd:string intersected, but it appears that they do not, so
>there are now more things in the universe than those folks thought.
>Is that necessarily a bad thing, that we have removed some ambiguity?
>Before we had X == Y and X != Y which was a problem, but now we see
>that actually we have X1 == Y1 and X2 != Y2 and now we see that all
>is well.
>Where's the problem?
> > >
> > >>  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?
>That, I think, is the reality, though RDF at present does not reflect
>it. If the surface lexical forms were the actual values, then why would
>the URI specs speak of equivalence, such that "foo:bar" and "FOO:BAR"
>denote the *same* resource?!
>RDF has punted on this issue from the start. I tried to bring it up
>a few times, but got slapped back into my corner. Well, it's still
>an issue that needs to be addressed...
> > 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.
>I guess it's something that has to be fixed in 2.0, if ever.
> > >  > 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.
>Yet when it comes to datatyping and reliability/precision, strong
>typing is IMO the only acceptable approach.
>Perhaps this is the real crux of the datatyping debate. Perhaps RDF
>is not and will never be acceptable for eCommerce and security and
>trust, because it takes to weak a view for such things.
>Perhaps I'm asking RDF to do something that it just cannot do.
Received on Friday, 1 November 2002 05:05:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:02 UTC