- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 24 Jan 2006 10:40:00 -0600
- To: franconi@inf.unibz.it
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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