Re: On told-bnodes in queries

>Seaborne, Andy wrote:
>>
>. . .
>
>>
>>-------
>>
>>Bijan's example [1] is a single basic graph pattern.
>>
>>Suggestion: for this version of SPARQL, entailment beyond what can 
>>be done by logical closure only applies to queries with a single 
>>basic pattern matching Maybe some restricted set of FILTERs as well.
>>
>>The rest of the algebra applies to abstract syntax queries (and 
>>hence over logical closures).  We hope a later working group will 
>>extend the algebra to entailment uses based on reseach done between 
>>the end of the WG and the start of the next.
>>
>>Question to everyone: the best way to this would be a concrete use 
>>case for entailment beyond RDFS that isn't covered.  Anyone got one?
>>
>
>More - there could be further restrictions such as:
>
>1/ No told bNodes - I guess this is necessary
>2/ Even no bNodes in the query at all - that might be restrictive on 
>syntax but may be acceptable.

I really think we can handle everything we need by the construction I 
suggested. (Im still trying to convince Enrico :-)

The semantic condition is, S is an answer to the query pattern Q 
against the graph G when :

G simply entails (G union Q[S])

If G and Q share no bnodes, which let us assume mut be the cas for a 
'first query' to a graph, then this is exactly the same as saying

G simply entails Q[S]

which is the simple, clear basic form that the logic folk want us to 
have, and which generalizes nicely to other entailments. So, now, how 
can it ever be that the query and the graph share a bnode? The only 
way this can possibly happen is by the server revealing one of its 
bnodeIDs to the client by providing it in an answer binding. If it 
does, then the condition guarantees that that bnodeID will refer to 
the same bnode in subsequent queries. But the server is not obliged 
to do this: it can answer the first query quite correctly and 
accurately by using a different bnodeID in its answer, one generated 
for just that purpose. Ths follows from the fact that if G entails H 
and S is any 1:1 bnode-bnode renaming, then G also entails H[S]. 
Basically, the server has the option of revealing its 'private' 
bnodeIDs, or not. Either strategy satisfies the entailment conditions 
and provides the same semantics for a single query. If it never does, 
then the queries will always have distinct bnode populations from the 
graph G, and bnodes in an answer simply indicate an existential, and 
have nothing in common with bnodes in any other answer. BUt if it 
decides to reveal the True Name of one of its bnodes in an answer, 
then it is obliged to recognize that name when it sees it again. So, 
we are saying to servers: your call: if you reveal the bnodeIDs to 
the public, be prepared to recognize them when you see them again.

Now, this isn't 'told bnodes' exactly, since a query that 'tells' a 
bnode out of the blue, i.e. one that didn't occur in a previous 
answer binding, doesn't make sense IMO. It doesn't require any 
special syntax or fake URI schemes, and it has the very same 
entailment condition, so it generalizes to other forms of entailment 
very nicely. But it allows the "tell me more about _:345" mode that 
several folk have said that they want, and it does so simply by 
re-using the bnode that you get from one query in another query, 
which seems simpler to me than having to morph it back into a URI and 
then hope that the server knows what you are talking about. The chief 
advantage, in fact, is that on this scheme the client doesnt have to 
do anything out of the ordinary at all: all the initiative is taken 
by the server.

Pat


>
>>     Andy
>>
>>(*)
>>[1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0498.html
>>
>>>
>>>cheers
>>>--e.


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 4 November 2005 23:02:07 UTC