Re: unsaid/not: any champions?

On Mon, Oct 04, 2004 at 04:09:14PM +0100, Seaborne, Andy wrote:
> 
> I also think it will have significant impact on the design and wouldn't
> want this feature to defocus our efforts.  It seems to force either a
> logical assertion view of the world or a procedural interpretation.  We
> have some implementation experience to go on (log:notIncludes in cwm and
> Euler) but are there any database-backed systems that provide something of
> this kind?

Algae does, but I was just being a geek and using it to test the
completeness of the logic engine. It works in that logic engine (the
ephemoral store).

I haven't implemented it in SqlDB (talks to both generic triple stores
and conventional normalized databases) but planned to impelement it
with an OUTER JOIN and some constraints. An over-simplified example
over a trivial generic triple store:
  ask (?x rdf:type foaf:Person .
       ! ?x foaf:mbox_sha1sum ?sum)
==>
  SELECT s1.subject
  FROM __Holds__ AS s1,
  LEFT OUTER JOIN __Holds__ AS s2 ON s1.subject=s2.subject
  WHERE s1.predicate='rdf:type' 
    AND s2.object='foaf:Person'
    AND s2.predicate='foaf:mbox_sha1sum'
    AND s2.id IS NULL

What makes this work in SQL land but not in SPARQL land is that the
SQL implementation has handles for each of the statements (s1.id,
s2.id). The SPARQL composer does not have a convention to identify
terms in the query. E.g. in
  SELECT ?x
  WHERE (?x rdf:type foaf:Person)
        (?x foaf:mbox_sha1sum ?sum)
    AND UNSAID(term2).
we don't have a way to tie "term2" to "(?x foaf:mbox_sha1sum ?sum)".
Algae didn't have it either, but it did have
  '!' triplePattern
  | '!' graphPattern

> Simon/Tom - does Kowari prvide any similar feature?  I have had requests
> for it in the past but it is not a common request (I guess I have had less
> than 5 such requests).
> 
> As it is an objective - "4.3 Non-existent Triples" - we have some room for
> manoeuvre.
> 
> http://www.w3.org/2001/sw/DataAccess/UseCases#d4.3
> 
> 
> I would note that limited cases can be with extension functions,
> particularly testing for the absence of a single triple after variables
> have been bound.  Optionals can be used as the basis for post-query
> checking by the application in some cases.  The ASK form is also relevant.
> 
> For this publishing cycle, I am inclined to leave a placeholder in the doc
> and possibly explicitly note that this feature may fall below the cut
> line.  The sort of feedback I'd like to see is real use cases to gauge the
> overall value.   If there is no feedback, then we drop it.

The current grammar does not have it.
(in an open world, maybe it's there but I can't see it.)

> Dan Connolly wrote:
> >We still have an unsaid issue...
> >  http://www.w3.org/2001/sw/DataAccess/issues#unsaid
> >
> >but recent design drafts don't say much about it...
> >  http://www.w3.org/2001/sw/DataAccess/rq23/#unsaid
> >
> >and if we're going to do it, I think it'll have significant
> >impact on the design; I'm disinclined to put the question
> >on the SOURCE issue until I have a clear picture of where
> >we're going with UNSAID.
> >
> >I thought maybe we had adopted a requirement to do UNSAID,
> >but I can't confirm from our requirements document.
> >  http://www.w3.org/TR/rdf-dawg-uc/#req
> >
> >If anyone would champion this feature, let him/her speak
> >now... or soon (in the next few weeks)... or... wait
> >until after we get a 1st version of SPARQL to REC.
> >
> >It's also in order to propose that UNSAID should not
> >be in SPARQL, or that it should be postponed until
> >a later version.
> >
> >
> 
> 
> 

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.