RE: Question about literals in subject position



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Birte Glimm
> Sent: 24 September 2009 10:56
> To: Steve Harris
> Cc: public-rdf-dawg@w3.org Group
> Subject: 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.

We could change the definition to allow literals as subjects - in order to maintain compatibility absolutely with the Query 1.0 spec, the restriction could be moved into the definition of simple entailment matching, freeing it up for other entailment regimes.

Query 1.0 notes that the RDF WG knew of no reason not permit them except the syntax issues with RDF/XML.

FYI: system that provide property function, built-in functions (various other names) put literals in the subject position 

> 
> 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. 

Ruling out in queries might be hard because of variables in the subject and object positions causing the literal to appear in the subject position because of the data. 

 Andy

> 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 Monday, 28 September 2009 13:06:08 UTC