- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 4 Nov 2005 17:02:01 -0600
- 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