Re: Editorial thread for BGP matching

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