Re: s/xsd:string/plain literal/g

Steve Harris wrote:
> On Wed, Nov 30, 2005 at 02:50:40PM -0500, Eric Prud'hommeaux wrote:
>>I've updated the prototype for LANG to return a "simple literal" [SL]
>>instead of a typed node with a datatype URI of xsd:string. Following
>>the impact on the examples, I ended up changing most of the ops to use
>>"simple literal". I think this reflects most of the implementations. 
>>Test that works with this model, but not with LC:
>>  [] dc:title "solitario"@ES .
>>  [] my:supportsLang "FR", "ES".
>>  ASK { ?who dc:title ?title .
>>        ?app my:supportsLang ?lang
>>        FILTER ( LANG(?title) = ?lang ) }
>>I'm particularly interested in feedback from implementors. Comments?
>>Is this what you wrote anyways?
> It's what I wrote.


> This kind of thing lends weight to the opinion that SPARQL shouldn't
> distinguish between plain literals and xsd:strings IMHO.
> - Steve

I tried the following: (arq.qexpr takes an expression, evaluates it and prints 
the result or the error that occurs ).

arq.qexpr 'lang("solitario"@ES) = "ES"'

arq.qexpr 'lang("solitario"@ES)'
"ES" (so it is a plain literal)

arq.qexpr 'datatype(lang("solitario"@ES))'
   because rq23 makes that a special case

arq.qexpr 'datatype("solitario"@ES)'
Exception: datatype: Literal has language tag: "solitario"@ES

Taking the text as a challenge :-)
This would make "asdf" and "asdf"^^xsd:string indisguishable to standard 
SPARQL queries.
ARQ treats plain literals with no language and xsd:strings as equivalent.

I tried
arq.qexpr 'regex("foo"^^xsd:string, "oo")'

arq.qexpr '"a" < "b"'

But rq23 says:

A < B  	simple literal	simple literal

REGEX(STRING, PATTERN)  simple literal	simple literal

so it could be argued as wrong.

Some tools appear to be sensitive to the difference between plain, untagged 
literal or an xsd:string.  protege seesms to generate xsd:strings alot and may 
have problems reading in simple literals


Received on Thursday, 1 December 2005 12:51:18 UTC