W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2009

Re: [BLD] Review (completing ACTION-776)

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Mon, 18 May 2009 22:10:12 -0400
To: Christian De Sainte Marie <csma@fr.ibm.com>
Cc: RIF <public-rif-wg@w3.org>
Message-ID: <20090518221012.6ec7064e@kiferserv>
Thanks, Christian,

I am referring here mostly to the points that Harold hasn't already taken care
of (he marked them as --->Michael in his email

On Tue, 12 May 2009 11:03:20 +0200
Christian De Sainte Marie <csma@fr.ibm.com> wrote:

> Section 2. Direct specification...
> - 1st par., line 3, "The presentation syntax is normative, but it is not 
> intented to be a concrete syntax for RIF-BLD": this sentence is really 
> confusing. If it is not a concrete syntax, it should be called an abstract 
> syntax, not a presentation syntax. It should say something like: "We 
> define both an abstract and an XML syntax.The abstract syntax and the XML 
> synatx are normative. To make definitions and explanations easier to read 
> and understand we define a lightweight notation that blablabla. That 
> notation, or presentation syntax, is not normative."

This is water under the bridge. This group has been vacillating 
between abstract, concrete, semi-concrete, etc., for so long that it is not
practical to go back to this issue. As it stands, the syntax is not really
abstract, because of the various shortcuts, but it is not concrete either.

> - Section 2.2, 2nd par.: the definition of base term does not seem to 
> exclude atoms (plain or external);

Why should it?

> - Section 2.3, par. 2: the definition of an externally defined atomic 
> formula does not seems to exclude externally defined frames, equality, 
> membership or subclass atomic formulas. As far as I can see, the 
> well-formedness conditions (section 2.5) do not exclude them either; 
> neither do  the definitions of semantics structures (section 3.2, item 11) 
> or truth valuation (section 3.4, item 7). We have a resolution (from 
> F2F12) that "The only Externals in BLD (and Core, and PRD) will be 
> Predicates and Functions. No external frames, no external equality, etc.". 
> The EBNF allows only predicates and functions to be Externals, btw. The 
> spec of BLD as a specialisation of FLD does have the restriction as well 
> (section 6.3, item 3, 2nd bullet, 4th sub-bullet)

Take a look at the section "Terms," item 9.

> - Section 2.4 (annotation): it could (should?) be made more explicit that 
> the identifier is assigned to the term or formula to which the annotation 
> is attached, whereas the slots of the frames are about the object 
> identified by their object Id, which can be different from the Id assigned 
> to the term/formula that bears the annotation. Same in section 2.6.3 (EBNF 
> for annotations).

What does it mean "assigned to the term or formula ..."?
Nothing is "assigned" to anything. It is just syntax; annotations have no
Adding such stuff would only puzzle people, because you would be piling up one
informal thing on top of another.

> - I do not understand the Editor's note at the end of section 2.4. But the 
> question it raises must be resolved and the note removed.


> - Definition of Imported Document, in section 2.5: the locator, loc, is 
> not a rif:iri constant, but anyURI (as resolved during F2F13, day 2 [2]

This cannot be the case, since the resolution was that these locators would be
enclosed in angle brackets, but they would not be rif:iris.
<"..."^^anyURI> cannot be the right thing.
So, they must be unicode strings in the form of an iri and enclosed in <...>.
I don't see rif:iri in the current text. Maybe it was fixed after your review?

> - section 2.6, 1st par. The first two sentences reinforce the 
> understanding that the notation that is used from the beginning is the 
> (presentation) syntax of BLD. I am pretty sure that, in that context, the 
> last bullet in the subsequent list of items will be bewilderingly 
> confusing to the reader. Or, maybe, I am the only one who is stupid enough 
> to think this is confusing :-)

It is called a presentation syntax and it is a presentation syntax.
Why is it bewildering that a thing called A is indeed an A (whatever "A" might
mean -- there is no official definition of what a presentation syntax is in

> - Section 3, 2nd par.: "Recall that the presentation syntax of RIF-BLD 
> allows shorthand notation..."; you mean the non-normative notation 
> introduced along with the normative presentation syntax, I assume? :-)

Indeed. But I would rather be silent regarding the status of the shorthands.
It is going to be very confusing otherwise.
For the semantics, it does not matter whether the shorthand notation is
normative or not, since it assumes that all shorthands have already been
expanded. But it is an unnecessary complication to start distinguishing
normative from the very minor shorthand extension and insist on them being
non-normative. What purpose is it going to serve except to add to confusion?

> - Section 3.2, 1st par.: replace RIF framework by RIF framework for logic 
> dialects (here and everywhere it occurs);

ok. But it is too boring to repeat this every time. There is never a confusion
about it because each time a proper reference is provided.

> - section 3.2, definition of mapping I: shouldn't I(List(t1...tn|t)) be = 
> Itail(I(t1)...I(tn), IList(t))?

No. This would not be a well-formed definition. For instance, t could be List(a
b c) and Ilist(List(a b c)) is not even defined.

> Btw, I do not understand why the comments 
> about malformed lists, in section 2.2 (item 4 in the definition of Term) 
> and in section 3.2 (item 5 in the definition of semantics structures), 
> since it does not seem to make any difference, syntactically nor 
> semantically, whether a list is well- or malformed...

It is useful for people to understand that this construct is more general than
what some people might expect.

> - section 4, definition of conformance in XML form: that definition, if at 
> all useful, should be related to the definition of conformance, section 5; 
> maybe even moved there?

Good catch! This was, indeed seriously confusing, so we changed this to

    -- michael
Received on Tuesday, 19 May 2009 02:11:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:56 UTC