W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: Editorial changes in Section 2.5

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 13 Feb 2006 15:12:12 -0600
Message-Id: <p06230906c016a13931fe@[]>
To: andy.seaborne@hp.com
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>

>On 13 Feb 2006, at 15:22, Dan Connolly wrote:
>>>That text (in the definition) was something that the WG made a 
>>>decision about.
>>>   I don't think I have license to make changes without further a WG decision
>>>(and you weren't there on Tuesday).
>>>Dan - can I apply the changes?
>>>Or apply them for WG review?
>>It's been very difficult to get all the interested parties on this
>>issue in sync. I'm not inclined to re-consider our 26 Jan decision
>>without a really compelling argument that it's broken.

I'm now looking at version 1.638, section 2.5, and seeing this:

Definition: E-entailment Regime

An E-entailment regime is a relation between a subset of RDF graphs 
and a subset of basic graph patterns.

A basic graph pattern in the range of an E-entailment is called well- 
formed for the E-entailment.

Was this in version 1.623 when we took the vote?? If so, I apologize 
for not noticing it at the time, but this is broken. Entailment is a 
relationship between graphs, because *by definition* it refers to 
truth of the graph in an interpretation. Patterns don't have 
truthvalues in interpretations. So what it should say is that an 
E-entailment regime is a relation between RDF graphs, defined on a 
subset of RDF graphs. The graphs in the subset are called well-formed 
for the entailment regime. (I'd avoid the use of 'range' here, see 

This has to be fixed. If that means reconsidering the vote we took 
then that has to be done.

>>If this is only an editorial problem, it can get fixed during CR.
>>A test case showing it's a substantive problem would be a compelling
>>argument to re-consider the decision.
>>Andy, I'd rather you did _not_ change the decisions that we
>>agreed on 26 Jan.
>>Enrico, I hope you find this acceptable.
>Not really.
>These are editorial problems, that make the current definition
>(a) slightly imprecise from the formal point of view:
>>>>>1) missing explicit quantification (some term has not been properly
>>>>>introduced before being mentioned: B and BGP')
>>>>>2) the notion of "introduced by" should be replaced by the more
>>>>>precise "in the range of"
>(b) not fully understandable:
>>>>>3) we need to emphasise that G' and B are somehow fixed - so that
>>>>>we can ignore mentioning them from now on (as we actually do
>>>>>whenever we mention matching in the rest of the document).
>I don't see why we want to go public with an imprecise document, 
>while we have spotted the imprecision in advance.
>Why should we be so rigid for an editorial problem?

Precision and readability are often at odds. I do not myself find 
'introduced by' any less precise in meaning than 'in the range of': 
the former is a form of words often used in mathematical texts and 
articles when referring to the results of applying a mapping. And the 
use of the technical word 'range' here is itself imprecise, since 
there is no single accepted definition of it (one commonly accepted 
usage in mathematical text is different from its use in the 
RDF/RDFS/OWL documents, for example.) Moreover, if we use this word 
without explanation, a reader of a W3C spec would be likely to assume 
that the word was being used in the same sense that it is used in 
other related W3C specs, which would make the phrase "the range", 
using the definite article, meaningless, and would not convey the 
intended meaning.

We cannot assume that our readers are familiar with math-speak, which 
is a language all its own. Overall, this change is likely to make the 
spec both less precise and less comprehensible.


>Attachment converted: betelguese2:smime 26.p7s (    /    ) (00237804)

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 Monday, 13 February 2006 21:12:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC