Re: [NEW ISSUE?] NAF & !BOUND issues#unsaid, nestedOptional

On Sep 12, 2006, at 5:33 AM, Bijan Parsia wrote:
> I welcome pointers to past discussions.

We accepted a relevant objective in July 2004:
[[
4.3 Non-existent Triples

It must be possible to query for the non-existence of one or more  
triples or triple patterns in the queried graph.

Status: Accepted 2004-07-15.
]] -- http://www.w3.org/TR/rdf-dawg-uc/#d4.3

That resulted in the unsaid issue...
   http://www.w3.org/2001/sw/DataAccess/issues#unsaid

We closed that issue in the Jan 2005 meeting:
   RESOLVED: BOUND keyword and no UNSAID to address common UNSAID  
issues. KendallC  abstaining
   http://www.w3.org/2001/sw/DataAccess/ftf4.html#item04

It's actually a combination of OPTIONAL and UNSAID that addresses the  
UNSAID use cases,
so the http://www.w3.org/2001/sw/DataAccess/issues#nestedOptionals  
issue is
relevant too.

I was going to say that I don't see much new information here, but  
nestedOptionals
has been reopened for other reasons. And whether you count this as one
or two open issues probably doesn't matter much.

> I'm raising this mostly on behalf of Jorge Pérez, Axel Polleres, and  
> myself, though we all have slightly different perspectives. I
>
> http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#func-bound
>
> """One may test that a graph pattern is not expressed by specifying an  
> optional graph pattern that introduces a variable and testing to see  
> that the variable is not bound. This is called Negation as Failure in  
> logic programming."""
>
> The main concern is that if we are going to allow NAF (which we  
> currently do), then we should allow for it in a more convenient form,  
> e.g., a not or \+ operator. I think if we stick with it in this  
> limited form, then we should call it out better as it's a pretty  
> fundamental (though very useful) shift in SemWeb philosophy at the  
> W3C.

Yes, we discussed that when addressing the nestedOptionals issue...

[[Jos observed a closed-world assumption in the latter interpretation,  
and asked if it was by design. AndyS and EricP said that yes, it was.  
DanC said he thought the WG was aware of this in design discussions  
around optionals, but suggested noting it explicitly in the spec.  
ACTION AndyS: to clarify 5.4 w/r/t closed world assumption]]
  -- http://www.w3.org/2001/sw/DataAccess/ftf5-bos.html

The text you quote above results from that action, I believe. It leaves  
a funny taste
in my mouth too, but I never found inspiration to propose a replacement.

>  We might also want to coordinate with the RIF about it as they will  
> almost certainly be defining NAFy operators.

Yes, I think it's important to get RIF review of this aspect of SPARQL.  
When we
originally considered the UNSAID (and SOURCE) issue, I did specifically  
seek
review from the SemWeb Best Practices WG. The feedback I got (from  
individuals,
not as a WG decision) was something like "yes, that's consistent with  
the state of the art in
database query stuff; it's safe enough to standardize."

BP input to DAWG/SPARQL (esp SOURCE, UNSAID) still wanted
31 Jan 2005
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Jan/ 
0026.html


> The other option is to kill bound and unbound. Jorge claims that bound  
> is never useful, i.e., never alters results; I haven't worked that out  
> myself yet. Jorge also claims "some of the hard results of complexity  
> are heaviily involved with the use of !bound", which isn't *too*  
> surprising as  nonmon typically raises complexity.

BOUND gives me the heebie-jeebies; I'd rather not standardize it either,
but I don't see a straightforward way to get consensus around taking
out a feature that we said we wanted to give to them (by accepting
the objective) and that, in fact, we gave them...

[[
This query matches the people with a name but no expressed date:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
SELECT ?name
  WHERE { ?x foaf:givenName  ?name .
          OPTIONAL { ?x dc:date ?date } .
          FILTER (!bound(?date)) }
]]
  -- http://www.w3.org/TR/rdf-sparql-query/

I'm all for health warnings of the form "we don't know the formal  
semantics
of this. BEWARE."


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Tuesday, 12 September 2006 23:53:30 UTC