Re: Question about literals in subject position

[snip]

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

I am not advocating that literals in subject positions should be
allowed. If they are allowed, however, they are another source of
infinite answers under at least RDF(S) entailment regimes and we have
to have conditions in space to prevent infinite answers from this
source. The restriction that I have proposed would work for literals
in subject position, but we have discussions at the moment about we
should just restrict the use of rdf:_1, rdf:_2, ... which are the only
real source of infinite answers at the moment.

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

Good to know.

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

I think also the definition in 12.6 says that we should restrict
answers and not queries.

Birte

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



-- 
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:50:37 UTC