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

Re: Question about literals in subject position

From: Steve Harris <steve.harris@garlik.com>
Date: Thu, 24 Sep 2009 11:57:25 +0100
Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-Id: <7D335357-7381-4B60-B645-999AD1F4877E@garlik.com>
To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
On 24 Sep 2009, at 10:56, Birte Glimm wrote:
> 2009/9/24 Steve Harris <steve.harris@garlik.com>:
>> On 24 Sep 2009, at 10:16, Bijan Parsia wrote:
>>
>>> On 24 Sep 2009, at 10:01, Steve Harris wrote:
>>> [snip]
>>>>
>>>> My understanding is that it is a legal query, it's prohibited  
>>>> neither by
>>>> the syntax, nor the query algebra.
>>>>
>>>> However, it can't ever match any RDF triples in the query  
>>>> processors
>>>> data, as there can be no legal triples with literal subjects.
>>>
>>> Without inference. In the presence of RDFS interpretations, there  
>>> are
>>> situations where one might reasonably think that
>>>        "<foo/>"^^rdf:XMLLiteral rdf:type rdfs:Literal.
>>>
>>> is entailed by:
>>>        :s :p "<foo/>"^^rdf:XMLLiteral.
>>>
>>> The only thing preventing that entailment would be a syntactic  
>>> restriction
>>> on the form of things entailed (e.g., if we restrict ourselves to  
>>> legal RDF
>>> graphs.)
>>
>> SPARQL/Query 1.0 is restricted to legal RDF graphs though, as per (my
>> reading at least) of section 12.6.
>
> Well, but according to the RDFS semantics the tuple Bijan mentions is
> entailed. It cannot be stated in any input graph, but it is an
> entailment und RDFS entailment (never under simple entailment). Now as
> Axel said, we have the restriction on extensions of SPARQL to other
> entailment regimes (Section 12.6 of the current spec) that says:
> "For any basic graph pattern BGP and pattern solution mapping P,
> P(BGP) is well-formed for E."
> So for the query
> SELECT ?x WHERE { ?x rdf:type rdfs:Literal . }
> I would get a mapping of "<foo/>"^^rdf:XMLLiteral for ?x if I consider
> all entailed tuples (which is natural since we do entailment), but
> since P(BGP)="<foo/>"^^rdf:XMLLiteral rdf:type rdfs:Literal . is not
> well-formed for RDFS, I would rule it out as an answer.

Agreed.

> Another question that came up when reading the restriction from

> Section 12.6 above was whether I should rule out answers or rule out
> queries. In my current understanding I read it as every SPARQL query
> is valid for all entailment regimes, but I can rule out answers that
> would lead to solutions that are not well-formed for the entailment
> regime. This becomes even more interesting if we look at OWL 2 DL
> because there we have quite a lot of restrictions on what RDF tuples
> constitute a valid OWL 2 DL ontology. There I can either allow all
> queries and those with a BGP that can never be instantiated into a
> valid OWL 2 DL statememt will just always have no answers or I can
> rule out such queries. I personally prefer the latter approach since I
> can then raise an error that explains to the user that the query is
> not well-formed for OWL 2 DL for reason X. If I just return no answer,
> users might not understand what is wrong and why they do not get
> answers. As I understand the restrictions from 12.6 though, I should
> take the return an empty answer approach.

I think that 12.6 more indicates that you should rule out answers, but  
nothing stops you from issuing a warning to the user that the query  
can return no results due to the expression.

We do that, e.g. if someone tries to apply a regex to a URI, which is  
common for people new to SPARQL.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD
Received on Thursday, 24 September 2009 10:58:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:08:28 GMT