# Re: On told-bnodes in queries

From: Pat Hayes <phayes@ihmc.us>
Date: Fri, 4 Nov 2005 17:02:01 -0600
Message-Id: <p06230907bf9178e65ac6@[10.100.0.9]>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: Enrico Franconi <franconi@inf.unibz.it>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
```
>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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:49 UTC