Re: read BLD draft for f2f

Chris Welty wrote:

> If you have any issues with this draft (other than editorial), that have 
> not already been raised, please do so before the f2f meeting.
> 
> http://www.w3.org/2005/rules/wg/wiki/FrontPage?action=AttachFile&do=get&target=ED-rif-bld-20070914.html 

Most of these have been raised before but to avoid any surprises here's 
my list of non-editorial issues with the draft. I'll send a separate 
message on the things that are at a more editorial level.

[We need to clean up this whole formal syntax, abstract syntax, human 
readable syntax, XML syntax story but that is clearly already on the 
agenda.]

1. We should clarify that the "concrete syntax" is intended *purely* for 
illustration in the spec documents. This sounds like an editorial issue 
but I've mentioned it here because if the intent is that it might 
actually be used in practice then it needs a tighter specification 
(character sets, character encoding, lexical definition of CONSTNAME and 
VARNAME etc).

2. The scope of rif:local is not defined. The current phrasing "local to 
the various sets of RIF formulas" is not sufficiently precise, 
especially in the light of our requirement to support ruleset merging. 
I've previously suggested dropping rif:local and just having rif:iri. 
Presumably in some future phase we will add modules, as previously 
discussed, and at that point we will be able to be precise about the 
scoping of rif:local.

3. The spec still includes slotted terms. I don't see the value of this 
in the *basic* logic dialect, it seems like something for an extension. 
This was raised at F2F6.

4. The spec still includes # and ## but there is as yet no section on 
which to hang the agreed pro/con discussion nor is there any content for 
the pro/con discussion. The description of # refers to the notion of a 
"rif class". This is section survives (not my preference) then the 
notion of a "rif class" will need a fuller explanation.

5. In section 2.2.1.1 it states "This means that no variables or complex 
terms are allowed as slot names in the basic logic dialect." Yet the 
example in section 2.2.1.3 uses variables for slot names. If the 
restriction is indeed required then frames are not usable for RDF 
representation and the RIF/RDF representation will be to be reworked.

6. rif:text is not included in the list of primitive data types but is 
used (and needed) in the RDF compatibility section. The XML syntax for 
it will need to be defined.

7. The concrete syntax doesn't have an explicit set of delimiters for 
RULESET. That makes it hard to define ruleset-level metadata in the 
concrete syntax. That may or may not be an issue depending on the 
purpose of the concrete syntax.

8. In section 4.2.1 the mapping of plain literals with a language tag 
talks about replacing occurrences of "@" with "@@". I would prefer that 
we have a separate representation of text in the concrete syntax and 
avoid such mangling or simply avoid the concrete syntax altogether. If 
we stick to the current concrete syntax then (editorial) it should be 
made clearer that that transformation is an artifact of the concrete 
syntax and not relevant to the XML encoding or to any actual RIF processor.

9. [Out of scope for next WD] There is no notion of ruleset importing 
defined, we've mentioned before that would be useful. Is the intent to 
wait until a future phase when a complete module system is defined or 
would a simple syntactic level of import be possible within phase 1?

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 24 September 2007 16:31:23 UTC