Re: Final text for Basic Graph Patterns

On 17 Jan 2006, at 21:42, Pat Hayes wrote:
>>> At this point it is becoming too late. We ask that either our  
>>> text is used (with possible editorial changes to discuss),
>>
>> In fact, I though we agreed to do this. I don't know of any  
>> technincal errors or issues with the proposed text, and many of  
>> the tweaks and variations being proposed for "clarity" have fall  
>> down. Hard. There are a *lot* of complex and subtle issues. We  
>> should go with what *works*.
>
> I agree. But I am not at all convinced, and have seen no argument,  
> that it will work as stated, without any adjustment, for other  
> entailments, in particular with OWL/RDF syntax and OWL entailment.  
> I am pretty sure it will not, in fact. (The syntactic restriction  
> to bnodeIDs in the dataset graph, that is hard-built-in to these  
> definitions, seems to me to be likely not be appropriate for OWL/ 
> RDF, which uses RDF bnodes in lists to encode OWL syntax. At the  
> very least, it is possible to take a rational position which would  
> make it inappropriate. If RIF finishes up with a rule language that  
> allows terms to be composed by matching, then this restriction will  
> be disastrously inappropriate.)

In fact, you are somehow right.
But, you probably did not pay attention to our text:
"In fact, with the proviso that bnodes are not allowed to appear in  
pattern solutions, SPARQL may be extended to provide a way to  
override the default "simple entailment" with "RDF entailment", "RDFS  
entailment" (as defined in [RDF-MT]), and "OWL entailment" (as  
defined in [OWL-Semantics], where the syntactic restrictions in OWL- 
DL or OWL-Lite should be reflected in suitable syntactic restrictions  
on the form of basic graph patterns)."

So, we suggest an upward compatible extension *without* bnodes in the  
answer, because it is the only one which we know is going to work for  
sure (it is easy to see this). As our latest interactions proved, it  
is an open research problem how to have a query language with bnodes  
in the answer based on entailment which can also smoothly work with  
simple entailment.

> Given that the entire point of writing these definitions is to  
> provide a smooth seqway to OWL and Beyond; and given that the parts  
> of the current definition which are potentially problematic are not  
> semantically motivated but rather are concerned chiefly with  
> reducing redundancy - which itself is an issue whose meaning  
> changes when we change the notion of entailment, so will almost  
> certainly need to be revisited when OWL-SPARQL is finally cast in  
> stone - given all this, it seems to be worth spending some effort  
> to try to find a way to phrase them which is less likely to get  
> caught on some detailed snags later.

We believe that our text provides such solution. In a sense, I agree  
with you that we would prefer to have time to do *research* and solve  
this interesting open research problem. But a working group aiming at  
a standardisation can not do that. We just use what we know for sure  
at best.

> We've already seen that premature optimizations can come back to  
> bite us (no literals in subject position, no bnodes in property  
> position) and I really don't want something we do almost as a side- 
> effect in SPARQL, and that is not required by our charter, to be  
> used as a lever to limit what RIF is going to be able to do. ("We  
> can't have rules like that or SPARQL wouldn't work right.") I've  
> been trying to find a more robust way to state the conditions which  
> would clearly separate the necessary semantic conditions on  
> answers, from aspects of the definition that are there only to  
> reduce redundancy. These are tightly woven together in these  
> definitions at present.

Again, your motivations are good. Our characterisation covers  
*exactly* subgraph matching, and can be smoothly extended (if bnodes  
are not in the answer) to other entailments (including OWL-DL). This  
makes everybody happy.

[Technical conjecture:] Apparently, when bnodes are involved in the  
answer, there is a substantial incompatibility between the semantics  
that is needed for simple entailment (namely the semantics needed to  
have a syntactic reading of the graph), and a semantics that would be  
needed when standard forms of entailment are involved (e.g., RDF  
entailment, OWL-DL entailment, etc). The latter could be  
characterised with entailment+possibly some form of minimisation.  
However, the discussions of these months showed that a semantics  
based on proper entailment can hardly capture the syntactic nature of  
simple entailment. This is all due to the presence of bnodes in the  
answer set.

> Let us agree that ANY wording we finish up with MUST support the  
> same results for basic SPARQL patterns, i.e. for the simple  
> entailment case.  In fact, I thought we had already agreed this  
> some time ago. So far, they all do. This will be the only normative  
> case in the current document. This should have been enabling  
> progress to go forward on the algebra, independently from these  
> discussions.

Our current text can be proved to be equivalent to subgraph matching,  
and it is normative only for the simple entailment case. So we agree  
on everything, do we?

cheers
--e.

Received on Tuesday, 17 January 2006 23:26:19 UTC