olive branch (was: Re: FUB on Pat's proposal for BGP matching (please read))

Enrico, I think we are much more in agreement than you fear. I also 
wish to have the general definitions be stated normatively (as they 
currently are) and to resolve the outstanding semantics issues. And I 
think this is what will be done. So let us try to have a truce and 
work to a commonly desired end.

Forgive me for presuming to read your thoughts; but thinking about 
some of our debates, I have the impression that you may be working 
under the assumption that anything written into definitions is 
normative, but text is only informative. That is not how the specs 
work. The only way to make anything be normative is to say so in the 
text itself by using language such as "must be" or "cannot be". So 
even if the very general conditions are written into section 2.4 or 
2.5, they will not be normative unless it is stated that something 
must conform to them. But it is absurd to state there that SPARQL 
itself must conform to them, since we will immediately have to say 
that SPARQL must conform to something much more restrictive, at which 
point those more general conditions become vacuous as far as SPARQL 
itself is concerned. They don't acquire normative force just by being 
general: they obtain normative force only by being applied 
normatively to something. But to what? The only sensible thing to say 
is that something else, not SPARQL itself, must conform to them. That 
is why I suggested using the term 'SPARQL extension' when stating the 
general definitions, just to provide a handle for the things that we 
can apply them normatively to. This isn't a plot to weaken the force 
of the general definitions, or to render them merely informative: it 
simply comes from trying to think about how to make the overall 
document make internal sense. We had a similar issue when writing the 
RDF specs, and I'm suggesting that we use the same wording trick we 
used there, which seems to have been fairly robust.

The operational effect of such language in a spec is that 
implementors of, say, a SPARQL-like OWL-DL data query language (who 
cannot, of course, say that they conform to SPARQL itself, under any 
reading of the spec) are obliged to satisfy the general definitions 
if they want to be able to describe their system as a conforming 
SPARQL extension, or as in conformance with the SPARQL specification 
documents. No doubt in practice the word "extension" will tend to get 
dropped, and the name "SPARQL" will be used loosely to refer to the 
entire family of such extensions, just as people now refer to RDF, 
RDFS and the OWLS as the "RDF family" of languages. But for now, we 
have to write the actual spec so that it is internally coherent, and 
to do so requires that the term "SPARQL" refer to a single language: 
so we need some way to refer to the other members of this 
hypothetical family that havn't been born yet.

Also, BTW, referring to 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0249 , 
the paragraph in 
http://www.ihmc.us/users/phayes/Section2.4revized.html which reads

"Extensions to SPARQL may modify this definition by using other forms 
of entailment and imposing extra restrictions on answer sets, while 
retaining the essential form of the definition and the rest of the 
SPARQL constructions: see <<either later section reference or other 
document>> for details. "

was not intended to replace or eliminate the general definitions, as 
your response seems to presume. The suggestion was only that those 
definitions would be moved, so would be in the referenced section or 
other document, stated there at length in full generality, with some 
justification, commentary and examples, and stated as normative if, 
as now seems likely, that is what the WG feels should be done. I 
never intended to suggest eliminating this material, only to move it 
out from section 2.4 to something more like section 12, or (following 
Andy's suggestion) to a companion document. It can be just as 
normative there it is in its present location.

Pat



-- 
---------------------------------------------------------------------
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, 24 January 2006 16:40:14 UTC