Re: Final text for Basic Graph Patterns

>On Jan 14, 2006, at 10:11 AM, Enrico Franconi wrote:
>
>>Hi,
>>we ask to finalise the text of Section 2.5.
>
>Me too.
>
>[snip rebuttal of pat]
>
>>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.) 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'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.

>>or that the DAWG does not conclude the work on the 31st of January 
>>and we'll have a F2F during the W3C tech plenary in France at the 
>>end of February.
>>We recall that our text provides the use of entailment, the 
>>correspondence with the subgraph matching based implementations, 
>>and uniqueness of solutions for interoperability; its core 
>>definitions are stable since its appearance on the 2nd of November 
>>2005 <http://www.inf.unibz.it/krdb/w3c/sparql/>.
>[snip]
>
>While allowing for a reasonably clean extension to more expressive 
>languages from RDF and RDFS through OWL (and others, really). In 
>fact, it would be rather simple for us to produce a submission 
>(working group?) explaining how to do this.
>
>It would be nice to settle this as it would be nice to make some 
>progress on the algebra.

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.

Pat


>
>Cheers,
>Bijan.


-- 
---------------------------------------------------------------------
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 Tuesday, 17 January 2006 20:42:28 UTC