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

[BLD] ACTION-

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 03 Jun 2009 02:23:57 +0100
Message-ID: <4A25D0AD.9030600@deri.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 June 2009 01:24:38 GMT