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

Re: Action-778 - Review FLD

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Mon, 18 May 2009 20:07:34 -0400
To: Stella Mitchell <stellamit@gmail.com>
Cc: RIF <public-rif-wg@w3.org>
Message-ID: <20090518200734.5bf89762@kiferserv>
Thank you Stella.

Below pls find some responses and questions on your review.
I removed the ones that were taken care of and do not require explanation.
Please let me know if things have become clearer now.


On Mon, 11 May 2009 11:17:52 -0400
Stella Mitchell <stellamit@gmail.com> wrote:

>  My comments are all editorial:
>   Abstract
>  ------------
>       Says that dialects are required to specialize the framework.
>       In some places* it looks like specialization means a restriction on
> the framework (and is contrasted to an extension), and in other places** it
> looks like extending the framework is considered one way to specialize it.
>               *  e.g. last sentence of the 1st paragraph of the overview,
> 2nd paragraph of section 4, where it says that specialization implies that
> every well-formed formula in a dialect will also be a well-formed formula in
>               ** e.g. sections 2.1, 2.2, 2.4, 3.1,  where adding new things
> is described under the heading "specialization."
>                   Also, section 2.1 item #1 says the alphabet can be
> restricted, and then section 2.2 says the alphabet can either be restricted
> or extended.

This is indeed a very good point. I now changed the text by explicitly defining
extension points, which were implicit in the old text. Dialects are now
supposed to specialize these extension points by replacing them with zero or
more objects of appropriate kind. In this way, extension is part of

>  2.1 Syntax of a RIF Dialect as a Specialization of FLD
>  -----------------------------------------------------------------------------
>        Definition (Symbol space):
>            slightly different from the one in DTB, where there is a 4th
> bullet saying each symbol space has a short name

Axel is supposed to fix the definition of symbol spaces in DTB.
The stuff about short names in DTB does not belong in the definition.

> 2.9 Annotations in the Presentation Syntax
> --------------------------------------------------------------
>         3rd para:
>            The EBNF (and the text afterwards) specfies that the annotation
> id is a rif:iri const, and also example 3 below shows it as an rif:iri
> const, and the mapping table in section 4.2.2.  Also, doesn't DTB in section
> 1.2.1 say that rif:ifi constants are globally known when it constrasts them
> to rif:local constants and says that a rif:ifi constant must be interpreted
> as a reference to one and the same object regardless of the context in which
> that constant occurs?

This was indeed garbled. The issue was not globality of names but those
names having a fixed interpretation. This par has been reworked; please see if
it is clear now.

>  3.4 Semanic Structures  ----------------------------------
>       1st list, item #11:
>           this item only covers externally defined positional functions (not
> positional predicates or named argument terms or frames...)?

Why does not it cover named arguments and frames?

>  5.0 Conformance
> -------------------------
>       Why did conformant producers use to have map a subset of L into RIF
> and now they have to map all of L into RIF?

This was changed from a subset of a language to mappings from the entire
language because one can always say that the sublanguage is a language in its
own right. This is clearer because "subset of a language" seems to be begging
the question "which subset?". For instance, an empty subset is also a subset,
so any processor would then be a conformant producer for any language.

    -- michael
Received on Tuesday, 19 May 2009 00:08:37 UTC

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