- 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 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 > 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, 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? Sorry, I pointed you to the wrong resolution. I meant the one that says [1]: "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" might > mean -- there is no official definition of what a presentation syntax is in > 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 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? Ahem... No, no! I said I would not come back to the subject anymore! (but... isn't that exactly what I have been saying?) Cheers, Christian 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 Courbevoie 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