Re: Datatyping literals: question and test cases

The subject line is question *and* test cases. This is
about the question, not the test cases.

Patrick

[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]


----- Original Message ----- 
From: "ext Brian McBride" <bwm@hplb.hpl.hp.com>
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>
Sent: 01 November, 2002 12:08
Subject: Re: Datatyping literals: question and test cases


> 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?
> 
> Brian
> 
> 
> At 09:48 01/11/2002 +0200, Patrick Stickler wrote:
> 
> 
> 
> >[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>; "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 
> >consideration
> >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
> >set.
> >
> >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.
> >
> >Patrick
>

Received on Friday, 1 November 2002 07:11:46 UTC