- From: Axel Polleres <axel.polleres@deri.org>
- Date: Wed, 03 Jun 2009 02:23:57 +0100
- To: kifer@cs.sunysb.edu
- CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Here a summary on how my comments on BLD were addressed. I think the last couple of things should be easy to implement.... this completes action http://www.w3.org/2005/rules/wg/track/actions/823 Some things which remain open: > * Section 2 if it is not normative, then section 2.6 should be marked > "(Informative)" explicitly. This wasn't addressed. I suggested to change: 2.6 EBNF Grammar for the Presentation Syntax of RIF-BLD to 2.6 EBNF Grammar for the Presentation Syntax of RIF-BLD (Informative) > * Section 2.1 > > 'Const', 'Var' could be linked to the respective productions in the > EBNF. > > Remarks: Would it make sense to change 'Names' to 'ArgNames' in the > EBNF (independently of the previous point) and XML syntac or - vice > versa - not to speak about the set <tt>ArgNames</tt> but use > <tt>Names</tt> instead? was not addressed, but well, was only meant as suggestion. > Change: reference "Section Constants and Symbol Spaces" to "Section > Constants, Symbol Spaces, and Datatypes", this occurs several times. has not been addressed, this reference is not the subsection where the shortcuts are explained. either refere generically to Section 1 (Section Constants, Symbol Spaces, and Datatypes) or to the subsections of 1.2 > * Appendix 10 > > similar to the Examples, the text should not be in fixed width font. has not been addressed yet. Some more things in reply to Michael's notes on the review: Michael Kifer wrote: > Thanks Axel for your detailed review. We applied most of your > suggestions. > > Just few brief notes: > > 1. List (1|2) = 1 is unsatisfiable because the image of Ilist is > disjoint from the data types. ok, had overlooked that I guess. > Is there something in the definition > that makes it seem as if this is satisfiable? no then. > 2. Abridged notation. As far as rif's presentation syntax is > concerned, this is abridged notation (and CSMA even wants it to be > marked non-normative). If you have a better name for it - fine. > Otherwise, it is quite descriptive. I suggest to speak about "compact representation" of IRIs instead of "abridged representation", that is also compliant with the rest of the document where you speak about "compact IRIs" (BTW: URI should be changed consistently to IRI, or is there a particular reason why you speak about compact URIs instead of IRIs?) > 3. In several places (related to conformance) you proposed to replace > T with DTS. Actually, T is not a DTS but a set of data types and > symbol spaces. This mention of symbol spaces was sometimes missing > and some times they were incorrectly called namespaces. I fixed that. > ok. > > 4. Reference to the complexity of unification of named arg terms when > arg names can be nonground terms rather than constants. > > I don't know of such a reference, but it is pretty easy to see that > it is likely exponential. It is similar to commutative and > associative unification, which is known to be NP-hard. For instance, > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.8880 > Probably has a reduction from it (never tried to prove it, but seems > quite simple). This is because bags (which are arguments to named arg > terms) can be represented as terms that are composed using an > associative and commutative function symbol. > > Anyway, given that there is no direct reference, I think it is hard > to do what you suggested in a concise way. Ok, let's leave this out and see whether we get comments. > 5. Primitive data types. The name is probably not optimal. Better > suggestions? I think simply "datatype" can be misleading because RIF > does not define any means of composing data types, unlike XML schema. > I understand this has been addressed. > 6. rif:local's as external names. I agree that they make no > conceptual sense. But do we really need to disallow them? Note that > because of the definition of external schemas, local symbols used as > externals won't cause any problems for whoever uses them. This is > just weird, but not outrageous. well, I think it is indeed weird, but if nobody supports the wish to disallow them, I am fine. > > On Fri, 15 May 2009 23:21:49 +0200 Axel Polleres > <axel.polleres@deri.org> wrote: > >> attached. > > -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/
Received on Wednesday, 3 June 2009 01:24:37 UTC