- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Mon, 23 Jan 2006 18:29:14 +0100
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Andy Seaborne <andy.seaborne@hp.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
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, which is why I prefer the > simpler wording: and then we don't need this odd notion of ordered > merging at all. In fact, I'd suggest that the simpler wording > should be normative, as it expresses the intended meaning more > directly and straightforwardly. Also, it keeps distinct issues > separate. Exactly how an engine handles bnode scoping (what gets re- > written, or maybe use hash-tables, whatever) really is an > implementation decision. We shouldn't build into the entailment > clause what is in effect an implicit decision about how to > implement bnode scoping. This is not about irrelevant stuff, this is about being precise and non-ambiguous. We have to be as precise as possible when writing down a definition, and not leave it to the verbal part. That's why I am proposing to have *my* precise definitions, and adding a verbal part explaining with *your* simpler wording: since they are equivalent for simple entailment, everybody is happy. I repeat that we need all the ingredients in the spec, since they allow us to introduce a terminology that future user have to refer to in order to make their choices - if they want to say that they are (backward) compatible with SPARQL. Future implementors have to declare, for example, what is their kind of entailment *and* their scoping set B, since they are in the spec. So again, why don't you like my proposal of having precise definitions with the simple wording explaining them? --e.
Received on Monday, 23 January 2006 17:29:19 UTC