not a test case. (was: 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?

Good question. Er.....  we aren't.

Pat

>
>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


-- 
---------------------------------------------------------------------
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 Friday, 1 November 2002 10:24:49 UTC