Re: equating simple literal and xsd:string

On Mon, 2005-12-19 at 09:58 -0500, Eric Prud'hommeaux wrote:
> Exploring the consequences of
>   "asdf" = "asdf"^^xsd:string
> 
> UNIFY:
> We could be ambitious and say, for SPARQL's purposes, they are the
> same term.

That would be pretty radical; i.e. it would involve surgery
on RDF graphs that are parts of SPARQL datasets. The RDF core
specs say that they're different terms, and while many days
I'd like to change that, not today.

But following the precedent of XQuery, in all the places
where any type coersion/promotion is going on, they should
get coerced to the same type or whatever...


>  At that point, we need to define answers to:
> 
>   ð	test			  current interpretation
>   1. "asdf" < "asdf"^^xsd:string	type error		???

false; i.e. the same as
  "asdf" < "asdf"

>   2. DATATYPE("asdf")			type error		xsd:string

I thought the current was "", which I'm OK with.
I could also be happy with xsd:untypedAtomic.

>   3. DATATYPE(STR(<asdf>))		type error		xsd:string

same as 2.

>   4. LANG("asdf"^^xsd:string)		""			???

"" seems ok

>   5. xsd:string("asdf")			"asdf"^^xsd:string	"asdf"

huh?


> ð 1 comes up when ordering ("Alice", "Alice"^^xsd:string) .
> 
> 
> OVERLOAD =:
> Another approach is to define a couple more = operators:
>   simple literal = xsd:string
>   xsd:string = simple literal
> 
> This seems a lot shorter to me, though skirts around the big issue of
> whether DAWG should tell the world that THEY ARE THE SAME.
> 
> 
> Andy, Steve, your implementations were cited as proof that the world
> already does it this way. Do your implementations conflate the two
> terms?

That's not the relevant question. The relevant question is:
do your implementations coerce the two so that they work
the same in FILTER expressions?

>  My guess is that Steve's does, and Andy's does something more
> like test positive for
>   sameTermAs("asdf", "asdf"^^xsd:string)
> 
> DanC, which are you advocating, and do you have specific textual
> changes that we can evaluate?
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 19 December 2005 16:26:48 UTC