Re: Question about literals in subject position

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.

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.

Birte

>>> I don't remember the exact motivation, though I seem to remember that it
>>> came up in discussion in the DAWG group, but it does give us a level of
>>> future proofing, and allows systems which allow literal subjects to easily
>>> extend SPARQL to query their full data.
>>
>> I guess the relevant question is do we want RDFS entailment in SPARQL
>> queries to work strictly on RDFS graphs, in which case:
>>        ASK WHERE {"<foo/>"^^rdf:XMLLiteral rdf:type rdfs:Literal.}
>> is always false, or work with ground BGPs, in which case that query would
>> sometimes return true. (E.g., against the above triple).
>>
>> In other words, are we in the future we proofed against :)
>
> Heh, perhaps :)
>
> I think currently it's always false, due to 12.6.
>
> Certainly there are RDF-like systems which permit literals in the subject
> position, so for some people at least it is significant.
>
> - 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
>
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Thursday, 24 September 2009 10:03:44 UTC