- From: Stella Mitchell <cleo@us.ibm.com>
- Date: Tue, 28 Oct 2008 20:46:59 -0400
- To: "RIF WG" <public-rif-wg@w3.org>
- Message-ID: <OF9974E75F.205DAEE3-ON852574EF.0068AFDD-852574F1.00044D24@us.ibm.com>
Dear WG,
These comments are on the 10/28 version of UCR.
Stella
Comments:
----------------
Section 2 - Goals:
Section 2.2
I'd put this as the first goal.
I think the information in the sub-bullets would be better
in
in the introduction. Here, maybe, could be a brief
discussion of the intra-rule-family vs. inter-rule-family
distinction. That topic is briefly touched on in
requirement
5.1.6 and discussed in the conclusion, but not before.
(see also comment for item 3 in section 2.4)
Section 2.4 - Critical Success Factors
I think this section would be better deleted. Most of
the items are already listed as a goal or a requirement.
Requirements support goals in the same way that CSFs
do. Without the whole original scheme and explanation,
this section doesn't seem so useful and may just add
clutter. In substitution for this section, there could
optionally be a little more explanation under certain
requirements explaining how they relate to the goals.
(e.g. could say for req 5.1.1 that this will support the
goal
of widespread adoption)
CSFs:
1. Same as goal 2.1
2. Same as requirement 5.1.6
3. This one seems to be talking about inter-dialect
interoperability (as opposed to intra-dialect)?
That
distinction is made explicitly in the conclusion
where
it says that inter-dialect interoperability is not
addressed
by the current phase of the working group. Maybe
there
should be a requirement about maximum overlap
between
dialects.
4. requirements 5.1.2, 5.2.2 ?
5. requirement 5.1.3
7. requirements 5.1.1, 5.1.4, and 5.1.5
Section 3 - Structure of RIF
------------------------------------
I don't think this section fits well in this document. Could
there be some short separate "Note" that is a document
roadmap for RIF?
Section 4 - Use Cases
------------------------------
last para (before 4.1):
This paragraph doesn't sound quite right, isn't PS a formal
notation? These 2 sentences could be moved above
the show/hide buttons and merged with the sentence
there to be something like:
"The rules in the use cases are expressed in English,
and also, where possible, in the Presentation Syntax
of RIF dialects"
UC 4.1
---------
Replace "slotted" terminology with "named argument"
(for uniterms) (several places)
use "subtract-dateTimes" instead of "numeric-subtract"
(applies to multiple examples in this UC)
If there is a style recommendation for the use of guard
predicates, then add them to make sure ?deliverydate and
?scheduledate are of the correct type. (applies to multiple)
UC 4.2
---------
BLD examples:
Some of the frame slot values are frames, and this is not
valid BLD syntax.
"Meta-interpretation" is mentioned (xor) in this use case, but not
mentioned in any of the others where it might also be used.
I'm not sure if the use of meta-interpretation was supposed to
be removed from the use cases.
What is http://www.w3.org/2007/rif-builtin-operators#" ?
Unused & unecessary prefix declarations pred and func
(check all the examples for this, applies to a number of
the following ones also)
UC 4.3
---------
2nd & 3rd rules:
The BLD version of the rule doesn't read the same
as the English version
(if no energy detected, then no device is using band
vs.
if energy detected, then device is using band)
Missing 'And' wrapper in body
leftover "." at end of rule (3rd example)
style: use guard predicate to make sure ?level is
numeric?
Paragraph following the 2nd rule: (about energy detection function)
I think this paragraph is incorrect. Isn't that what
external frames are for?
UC 4.4
---------
For the rule in this UC, and for the 1st rule in UC 4.3, there
is no BLD example and there is an explanation of why the rule
cannot be expressed in BLD. But for other later UCs, there are
sometimes no BLD version and no explanation (eg UC 4.5,
2nd rule of UC 4.6, etc)
UC 4.6
---------
ineffective, hasDiesease, etc look like predicates, but that would
mean this example has a predicate as an argument to a predicate,
which is not allowed in BLD.
The body needs to be wrapped in an 'And'
UC 4.9
---------
The BLD examples are missing 'forall', 'and', use "<", and
have "." at the end of rules, and use non-existent
"rif-prolog-builtin-functions"
UC 4.10
-----------
The examples are still all in Abridged presentation syntax.
The 1st movie BLD example has a membership term in the
object position of a frame, which is not allowed.
The 2nd movie BLD example uses a "not" predicate without
explanation, and has a predicate as an argument to a
predicate, which is not allowed.
why use:
?Movie#ex:Movie :- ?Movie#ex:ScienceFictionMovie.
instead of
ex:ScienceFictionMovie ## ex:Movie ?
In the Charlie examples:
getEventData (and sysTime?) should be written as External
Frame?
I'm not sure if <rdf:type> is valid syntax.?
Section 5 - requirements
--------------------------------
2nd paragraph:
The last sentence (that level of fulfillment is discussed) is
not true (I think).
What about removing the "General" and "Basic" classification
of requirements, and just saying that if a requirement is
motivated
by particular use cases, then links to the use cases are
included.
3rd paragraph:
1st sentence:
Why have hidden requirements (ones that are not
mentioned here, and are not based on either the
charter, goals or use cases)? There should at least
be
a reason given for not including them, and some
mention
of what their nature is. Also, why not include or
point to the
the requirements from the Charter here, or add an
explanation why they are not included?
Sections 5.1 (General requirements) and 5.2 (Basic requirements)
5.2.1
Is it really true that only one use case calls for RIF
to have
clear conformance criteria? This seems (General).
5.2.3
I think this one could use more explanation about what
the
requirement is.
5.2.4 and 5.2.5
Can these be merged because comments are
a kind of metadata?
5.2.5
Why does use case "Ruleset Integration for Medical
Decision Support" require Embedded metadata, and
use case "Collaborative Policy Development for
Dynamic
Spectrum Access" not require Embedded metadata?
(I think this type of question could be asked for a
number of the "motivated by" assignments)
5.2.6
Why does use case "Negotiating eCommerce Transactions
Through Disclosure of Buyer and Seller Policies and
Preferences" require that RIF have a limited number of
dialects,
and use case "Negotiating eBusiness Contracts across
Rule
Platforms" not require it?
Similarly for (e.g.) requirement 5.2.9. It's not clear
(to me)
why UC 4.2 out of all the use cases needs the semantics
of a RIF document to be determined by the content of
the
document, while none of the other use cases do.
5.2.7, 5.2.8. 5.2.14:
These also support goal 2.1. (Would that make them
General?)
I'd put 5.2.14 next to the other two, just to group
similar
requirements.
5.2.13
This is in the Basic (motivated by use case) section,
but there
are no links to motivating use cases.
Section 6 - conclusion
--------------------------------
Inter-dialect interoperability is discussed here for the first
time.
Section 7 - References
--------------------------------
Add BLD, DTB, SWC, PRD (because code examples depend
on them), and the charter ?
Received on Wednesday, 29 October 2008 00:47:43 UTC