W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2008

Re: SPARQL and literal matching woes - spec inconclusive

From: Richard Newman <rnewman@franz.com>
Date: Sat, 5 Jul 2008 11:15:07 -0700
Cc: public-sparql-dev@w3.org, public-rdf-dawg@w3.org
Message-Id: <27779B2C-BF9E-4E27-B767-01CE0CE6493A@franz.com>
To: Nuutti Kotivuori <naked@iki.fi>

Hi Nuutti,

The short answer is "it depends". Longer is "it depends on the  
entailment regime chosen by the implementation":

   http://www.w3.org/TR/rdf-sparql-query/#sparqlBGPExtend

Different entailment regimes can "expand" the graph against which a  
basic graph pattern matches.

* Under simple entailment, only ns:a is returned. Typed and untyped  
literals are entirely different, and literals without language tags do  
not match those with tags.
* Under a D-entailment regime which includes xsd:string and untyped  
literal equivalence, ns:a and ns:b would be returned.
* Under an entailment regime which not only entails that equivalence,  
but also can deduce that dt:datatype is a subtype of xsd:string, ns:a,  
ns:b, and ns:c would be returned.

It's also possible to conceive of an entailment regime which does  
something with language tags, but that would be less useful.

Now, an implementation-specific aside:

In AllegroGraph, we implement simple entailment, so you should get  
only the first result for a normal query. We also allow the user to  
apply wrappers to a triple-store -- e.g., an RDFS++ reasoner -- and  
this has the effect of making your SPARQL queries run against a  
different entailment regime (e.g., RDFS entailment with additions). It  
would be quite straightforward to write a new wrapper class that  
implemented xsd:string D-entailment.

HTH,

-R

On  5 Jul 2008, at 7:42 AM, Nuutti Kotivuori wrote:

>
> Hello,
>
> I am having some trouble matching literals with SPARQL. It seems that
> just about every implementation I tried manages to give me a differing
> set of answers for a very simple query. I have tried to verify this
> against the specification, but I haven't been able to find a
> conclusive answer there.
>
> I believe this could be an important interoperability blocker for
> several applications as the problem is easily triggered by the
> simplest of graph patterns.
>
> The issue is very simple do describe, but to be exact so it can be
> discussed reasonably, I will write it here somewhat verbosely:
>
> Assume the following RDF graph:
>
> ***
> @prefix dt:   <http://example.org/datatype#> .
> @prefix ns:   <http://example.org/ns#> .
> @prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
>
> ns:a ns:p "value" .
> ns:b ns:p "value"^^xsd:string .
> ns:c ns:p "value"^^dt:datatype .
> ns:d ns:p "value"@en .
> ***
>
> Now, if this graph is queried with the simple SPARQL query:
>
>  SELECT ?x where { ?x ns:p "value" }
>
> What should the result set be?
Received on Saturday, 5 July 2008 18:16:03 GMT

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