SPARQL semantics: open issues for basic query patterns

Hi all.

 From the latest DAWG minutes
<http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0384>:

""" PROPOSED: that http://www.w3.org/2001/sw/DataAccess/rq23/ 1.596
(section 2, @@NO TOLD BNODES options) addresses rdfSemantics, and that
it's sufficient to postpone owlDisjunction, contingent on acceptance
(including silence) by UMD and Free University of Bozen- Bolzano in a
week (by 27 Dec). ACTION PatH, DanC to respond to PFPS, Horrocks,
et. al.  """

FUB still wants to clarify the following points:

a) in the document only 'simple entailment' is used. We want a
parametric entailment, with simple, rdf, rdfs explicit at least, and
owl-dl and owl possible. The argument here is that due to the infinite
closure of RDF graphs (due to rdf:1, rdf:2, etc; or to the
reification), this document would not even allow to have
implementations that comply with the original RDF MT! Moreover, there
are explicit requests about this in the SWBP WG, for example
<http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0072>.

b) we want back the ability to label bnodes in a query as "told-
bnodes", in order to allow, e.g., for the use case "Publishing on the
Web" in <http://lists.w3.org/Archives/Public/public-rdf-dawg/
2005JulSep/0430>; also in the SWBP WG there are several requests to  
allow
for this, for example
<http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0176>.

c) we have to solve the problem about querying empty graphs:
see
<http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0386>
and
<http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0388>.
The argument here is that now we have embraced seriously the notion of
entailment, and therefore the RDF MT has to be taken seriously; please
note that still the use of simple entailment allows to satisfy Pat's
argument.

d) There should be a mention to the possibility to have systems that
satisfy the "interoperability" requirement (by PFPS):
- answers to equivalent graphs should be the same.
Please note that we can leave the implementors free to choose any
method he/she desires to satisfy this (optional) requirement, for
example using the notion of "minimality" as we were proposing some
time ago. With Pat we agreed that there may be alternative ways to
achieve this requirement, so we don't want to fix this.

cheers
--e.

Received on Tuesday, 27 December 2005 18:44:43 UTC