W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2011

Re: Plain literals and xsd:string

From: Steve Harris <steve.harris@garlik.com>
Date: Wed, 20 Apr 2011 13:59:33 +0100
Message-Id: <82EAF76D-5BB5-4CDA-A31D-DEB8B8135E57@garlik.com>
Cc: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
My temptation would be to say that CONCAT() always returns plain literal, but not say anything in particular about BIND(). I would hope that use of ""^^xsd:string will die out, and by RDF v+1 it would be legitimate to coerce to plain. 

- Steve

Sent on the move.

On 20 Apr 2011, at 12:11, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:

> Some good news:
> 
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#func-concat
> 
> Because we decided CONCAT tends to produce simple literals, not xsd:string on mixed simple/xsd:string combinations, we are
> 
> But should
> 
> concat("foo"^^xsd:string, "bar"^^xsd:string) ->
>  "foobar"^^xsd:string (current defn)
> or
>  "foobar"
> 
> What about
> 
> BIND("foo"^^xsd:string AS ?x)
> 
> 
> 
> On 20/04/11 09:47, Andy Seaborne wrote:
>> 
>> 
>> On 19/04/11 23:17, Steve Harris wrote:
>>> Hi all,
>>> 
>>> The RDF WG intends to recommend that xsd:strings be silently
>>> converted to RDF plain literals internally. See Resolution 1 in
>>> http://www.w3.org/2011/rdf-wg/meeting/2011-04-13.
>>> 
>>> This would have some impact on SPARQL deployments, as we go to some
>>> lengths in a few places to preserve the differences. I'm not sure it
>>> should necessarily affect the wording of any of the SPARQL texts, but
>>> it's probably worth bearing in mind. It could be that we can simplify
>>> some wording, but we should take care not to become dependent on a
>>> new RDF rec. for publication.
>>> 
>>> - Steve
>>> 
>> 
>> What should update do?
>> 
>> INSERT DATA { :s :p "foo"^^xsd:string }
>> 
>> 
>> It affects query. BGP matching is simple entailment.
>> The wording must change there surely?
>> 
>> Either that or
>> 
>> SELECT * { ?s ?p "foo"^^xsd:string }
>> 
>> will stop matching on data now converted to "foo" without a software
>> change to the query engine.
>> 
>> Existing databases + new software will see a change.
>> 
>> In my experience, it is OWL tools that will be affected as they like to
>> use xsd:string in RDF for ontologies.
>> 
>> Andy
> 
> Some good news:
> 
> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#func-concat
> 
> Because we decided CONCAT tends to produce simple literals, not xsd:string on mixed simple/xsd:string combinations, we are
> 
> The RDF-WG resolution says:
> 
> """
> Recommend that systems silently convert xs:string data to plain literals.
> """
> 
> So should
> 
> concat("foo"^^xsd:string, "bar"^^xsd:string) ->
>  "foobar"^^xsd:string (current defn)
> or
>  "foobar"
> 
> What about
> 
> BIND("foo"^^xsd:string AS ?x)
> 
> 
> 
> Less good news:
> 
> I hacked up a version of ARQ that parses xsd:strings to simple literals in data and SPARQL queries and got test failures in the SPARQL 1.0 test suite (as well as failures in ARQ's test suite).
> 
> The 3 failures are all data related, 2 in the DISTINCT tests and 1 in the REDUCED tests.
> 
>    Andy
> 
Received on Wednesday, 20 April 2011 13:00:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT