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

Re: [BLD] My BLD review.

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Tue, 19 May 2009 03:45:00 -0400
To: Axel Polleres <axel.polleres@deri.org>
Cc: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Message-ID: <20090519034500.5ce56537@kiferserv>
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.
   Is there something in the definition that makes it seem as if this is

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.

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.

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,
   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.

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.

6. rif:local's as external names.
   I agree that they make no conceptual sense. But do we really need to disallow
   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.

On Fri, 15 May 2009 23:21:49 +0200
Axel Polleres <axel.polleres@deri.org> wrote:

> attached.

    -- michael
Received on Tuesday, 19 May 2009 07:45:48 UTC

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