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

Yes. I made an attempt to define these at the beginning of the syntax section
(current, not in the frozen version).  I agree that we need to clean these up.

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


Yes.

One thing, as Sandro said earlier, let's start calling "concrete syntax" ->
"presentation syntax". Presentation syntax makes it much more clear what it
is used for. I went through the current doc and made the
replacements.


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

Yes. I now added a "TODO" in the appropriate place. We have to decide what
a ruleset actually is. For instance, will we have an #include statement?
Import statement?


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

You've got them for free :-)


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

We should not refer to rif classes, since there is no separate notion of a
rif class. I fixed that in the current version. As to whether to keep this
or not, it is an unfinished discussion, as you know.


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

I fixed that. This statement actually refers to slotted terms, not frames.
The reason for disallowing variables over slots in uniterms is the lower
complexity of the unification. There is no reason for this restriction from
the semantic point of view.

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

Need to decide how to exactly incorporate @lang and such.

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

TO discuss.


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

I do not see how we can get rid of the presentation syntax. This means that
we either give no examples or we use abstract or XML syntax. The latter two
options mean that mere mortals, like me, will not be able to write it our
understand it without undue effort.

> 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?

This is related to 2.


	--michael  

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

Received on Monday, 24 September 2007 20:44:45 UTC