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

RE: [BLD] ACTION-

From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
Date: Thu, 4 Jun 2009 13:30:51 -0400
Message-ID: <E4D07AB09F5F044299333C8D0FEB45E907EF0AFC@nrccenexb1.nrc.ca>
To: "Axel Polleres" <axel.polleres@deri.org>, <kifer@cs.sunysb.edu>
Cc: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Axel,

Thanks, I have meanwhile addressed these:

http://www.w3.org/2005/rules/wiki/index.php?title=BLD&diff=10052&oldid=9
999

> * Appendix 10
> 
> similar to the Examples, the text should not be in fixed width font.

I removed the surrounding <pre> ... </pre>, so links, including to RFC
3023
by IETF, became activated. The style is now as it is in such IETF
documents.

Harold


-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Axel Polleres
Sent: June 2, 2009 10:24 PM
To: kifer@cs.sunysb.edu
Cc: Public-Rif-Wg (E-mail)
Subject: [BLD] ACTION- 

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 Thursday, 4 June 2009 17:31:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 June 2009 17:31:35 GMT