Re: unsaid/not: any champions?

Steve Harris wrote:
> On Mon, Oct 04, 2004 at 04:09:14PM +0100, Andy Seaborne 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?
>>
>>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.
> 
> 
> It does not neccesarily have to be application level:
> 
> SELECT ?x
> WHERE (?x rdf:type foaf:Person)
>       (?x foaf:mbox_sha1sum ?sum UNSAID)   # playing with dave's syntax

Such a form will still have to deal with the situation where ?sum is part 
of some other triple pattern as well.  When unbound, this is a much wider 
pattern than when its bound leading to order dependences (procedural 
interpretation) or a more restrictive query having more solutions (logical 
interpretation).  I'd like to keep it so the two interpretations have the 
same answers.

> 
> SELECT ?x
> WHERE   (?x rdf:type foaf:Person)
>       [ (?x foaf:mbox_sha1sum ?sum) ]
> AND &dawg:unbound(?sum)
> 
> ( "AND ?sum IS NULL" if we go down the three value logic route )
> obviously the 2nd example is not as easy to read.

That's a good example - we can argue that the function evaluation happens 
after all attempts to bind the variable (pragmatically, we'll need a 
procedural interpretation to define function calling - I think that means 
in a logical view, functions may be called multiple times in the same 
solution for backtracking so no side effects but that is implementation 
dependent).

It is more readable (its just a style thing) to have constraints near the 
place where they make most sense.  Constraints already have to go with 
blocks and intermixing is possible.  Implementations can reorder to suit
- implementation freedom is a good reason for having query results not be 
order dependent.

This also recognizes the duality with the predicate view of constraints in 
the form of like math:lessThan.

>  
> 
>>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.
> 
> 
> I've seen a similar level of requests to Andy (3 or so IIRC), and they
> tended to be very special purpose, data maintainance type questions,
> rather than data-accessy things.

I have not come across the data maintainence type questions - not all 
requests make the usage clear - and I can see that it is more than 
reasonable there.  I'm prepared to focus just on the the data access side 
of things for this working group - we aren't addressing various data 
maintainence issues (like update!).

	Andy

> 
> - Steve
>

Received on Monday, 4 October 2004 19:21:07 UTC