- From: Patrick J. Hayes <phayes@ihmc.us>
- Date: Mon, 23 Jan 2006 23:40:40 -0600
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 23 Jan 2006, at 18:17, Pat Hayes wrote: "In the case of simple entailment, if the scoping graph G' is such that it does not share blank nodes with BGP, then the above definition can be simplified to take the union between G' and BGP, instead of an OrderedMerge." This works for any kind of entailment, No. It does not work for the extension with told-bnodes, I didn't refer to told bnodes - which is about bnode scopes, not different entailment modes - but to other kinds of entailment. unless you make exceptions :-) ...which hampers the smooth extensibility. We have no plans to cover told bnodes in any SPARQL documents. But in any case, something has to be altered to handle told bnodes, with either definition. 1. using 'union' definition. (G' has been defined to share no bnodes with BGP.) If the same G' is used for multiple queries, as for example if G' were always identical to G, then the effect of relaxing the above condition in the definition of G', allowing G' to share bnodeIDs with BGP, would be that answer bnodeIDs from a query would have the same scope in a later query. 2. Using 'ordered merge' definition. If the definition of 'ordered merge' is changed so that not all the bnodes in the merged pattern are re-named, then ... (etc. as above) They seem about equally exception-ish. In either case we ought to add some further explanation, perhaps pointing out that this makes bnodeIDs act very like IRIs, and that servers can create the same functional effect by using all the same definitions of answer, etc., but having G' be an instance of G rather than equivalent to G, i.e. by skolemizing the dataset and using that as the scoping graph. Pat --e.
Received on Tuesday, 24 January 2006 05:40:24 UTC