FLD mini-review

I generated a wiki-tr version on Friday 15th so I hope I was working on 
the up to date version.

Most comments quite minor.


** Overall

A clear and precise document. Not an easy read for people not versed in 
logic rule languages but that's not the target audience.

** 1. Overview

s/RIF-BFD/RIF-FLD/ half way down first paragraph.

** 2.0.4 Signatures

This is one of the longer sections. I wonder if a small upfront example 
illustrating the basic approach would aid readability. You do already 
explain the motivation for signatures clearly so perhaps that is enough.

** 2.0.6 Symbol Spaces

(a) Why include all subtypes of xsd:string?  I know Igor already pointed 
this out but I wasn't clear on the explanation. In particular, I don't 
think we do want to support the pattern restricted subtypes like NCName.

If this feature is retained then suggest spelling out that by "subtype" 
you mean "derived by restriction" in XML-Schema-speak and don't include 
those derived by list (NMTOKENS, IDREFS, ENTITIES).

(b) The description of rif:local refers to the notion of "rule set" 
which I'm not sure is defined clearly elsewhere in the document. As an 
informative description this is not a problem but should the notion of 
rule sets and scoping be precisely defined somewhere in this document?

"RIF-compliant inference engine"
(c) is this appropriate terminology? Suggest "RIF-compliant processor". 
Early on in the WG several members wanted to be clear there were 
different sorts of RIF processors such as editors and repositories that 
are not inference engines. An editor would still need to be able to 
validate and generate lexically valid symbol instances.

"RIF-consuming system"
(d) What's the point in explaining about substituting type 
generalizations here? That is between the translator and the internal 
engine itself and is outside of RIF. We require a compliant RIF 
processor to accept all the required symbol types, if it does so 
internally in the translator instead of the engine that is irrelevant to 
conformance. It seems like a low level piece of implementation advice 
out of place with the rest of the document.

(e) Presumably once we add the builtins then the set of builtins will 
include the constructors for each supported type. In which case if we 
require support for all xsd:string and xsd:decimal subtypes then will 
require the engine to support all of those constructors and simple type 
generalization in the translator will not be sufficient.

3.0.3 Primitive Data Types

The list of xsd:types given here is our old list and is different from 
that in 2.0.6.

In the last paragraph if the description of rif:text suggest replacing:
    "RDF's semantics for strings with named tags"
by
    "RDF's semantics for plain literals with language tags"

3.0.5 Interpretation of fomulas

Why does the TVal definition for equality not refer to I= ? Or rather 
what's the point of I= if TVal bypasses it direct to equality over the 
elements of D? [This is just my lack of understanding rather than an 
issue with the document.]

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

Received on Monday, 18 February 2008 11:40:42 UTC