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

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

From: Christian De Sainte Marie <csma@fr.ibm.com>
Date: Tue, 19 May 2009 11:28:24 +0200
To: kifer@cs.sunysb.edu
Cc: RIF <public-rif-wg@w3.org>
Message-ID: <OFBA023DD7.C6A51636-ONC12575BB.002D67F4-C12575BB.00340AE0@fr.ibm.com>
********* NOTICE **********
My new email address at IBM is: csma@fr.ibm.com
My ILOG email address will not be forwarded after June 8

Hi Michael,

Thanx for the replies. Some additional comments are in-lined below.

Michael Kifer <kifer@cs.sunysb.edu> wrote on 19/05/2009 04:10:12:
> > - Section 2.2, 2nd par.: the definition of base term does not seem to 
> > exclude atoms (plain or external);
> Why should it?

Because it is not unusual that, in logic, "term" refers to constants, 
variables or the result of acting on terms by functions... And because it 
is sometimes useful to distinguish between what can be an argument to a 
predicate or function, and what can not.

And, so, I thought that "basic term" was introduced for those reasons. 
Stupid me.

Btw, in PRD, the term "term" is used for constants, variables and 
functions, paralleling the use of TERM in the description of the EBNF and 
XML syntax. I removed the note, in PRD's section Atomic formulas, about 
the correspondence between the terminology used in BLD and PRD.

> > - 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. [...]
> Take a look at the section "Terms," item 9.
> http://www.w3.org/2005/rules/wiki/BLD#Terms

Yes. I saw that. Isn't there a risk that the confused reader might 
understand that the definition in section "Formulas" is meant to extend 
the definition in previous section "Terms"?

> > - Section 2.4 (annotation): it could (should?) be made more explicit 
> > the identifier is assigned to the term or formula to which the 
> > is attached, whereas the slots of the frames are about the object 
> > identified by their object Id, which can be different from the Id 
> > to the term/formula that bears the annotation. Same in section 2.6.3 
> > for annotations).
> What does it mean "assigned to the term or formula ..."?
> Nothing is "assigned" to anything. It is just syntax; annotations have 
> meaning.
> Adding such stuff would only puzzle people, because you would be piling 
up one
> informal thing on top of another.

Item (* identifier Frame *)

The identifier is meant to identify the Item, so that annotation Frames 
can be related to what they annotate (e.g. the Item), independently to 
where they are located. Is that correct?

If yes, my suggestion was to say that explicitely, because it is not 
intuitively obvious that the annotation may not be about the item to which 
it is attached.

> > - Definition of Imported Document, in section 2.5: the locator, loc, 
> > not a rif:iri constant, but anyURI (as resolved during F2F13, day 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 

Sorry, I pointed you to the wrong resolution. I meant the one that says 
"In the XML syntax (for Core, BLD, PRD), the xml-schema type of both 
arguments to import is an anyURI -- NOT rif Const element(s). "

[1] http://www.w3.org/2005/rules/wg/meeting/2009-04-16#resolution_7

> 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" 
> mean -- there is no official definition of what a presentation syntax is 
> general)?

If you called it a "vanilla ice cream", I would find it a bit strange that 
you would use a term that has a different connotation than what you use it 
for, but that would be less disturbing than "presentation syntax". Because 
there is nothing close-by that one would easily think _is_ a vanilla ice 
cream, but that is not what "vanilla ice cream" is defined to mean 
locally; whereas, there is something that the confused reader might quite 
naturally think is a presentation syntax, and that is the notation (but of 
course, that is not what "presentation syntax" means, here).

I am well aware how idiotic it is, to think that "presentation syntax" 
might refer to the concrete almost-syntax that is used for presentation 
purposes in the document, but I fear that that notion might be reinforced 
by the EBNF...

So, maybe, we should just replace "presentation syntax" by "vanilla ice 
cream" everywhere in the document?

Seriously: my point is that we, in the RIF WG, we might have grown used to 
call the PS something that might not be what the outsider might expect the 
PS to be. And this document is targeted to the outsider, isn't it?

So, yes, I am boring. I am still tempted to insist, but I am a little bit 
tired of trying; so, I will not come back to that subject anymore.

> Indeed. But I would rather be silent regarding the status of the 
> 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 
> non-normative. What purpose is it going to serve except to add to 

Ahem... No, no! I said I would not come back to the subject anymore! 
(but... isn't that exactly what I have been saying?)



ILOG, an IBM Company
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel. +33 1 49 08 35 00
Fax +33 1 49 08 35 10

Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 02430
Received on Tuesday, 19 May 2009 09:29:12 UTC

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