ACTION-451: Review UCR

Summary
-------

The document appears "frozen in time" -- a time when there were many 
competing voices in the group, many ideas that were not fully fleshed 
out, and little consensus.

What I would expect from the UCR:
Use cases that motivate and illustrate the proposed Phase I technical 
solution (FLD/BLD and XML/RDF/OWL integration).  Some consistency 
amongst the use cases, including using the same syntax (some simplified 
FLD presentation syntax) and describing how to access XML or RDF data as 
frames.

What I get upon reading the UCR:
Use cases with little consistency amongst themselves (not guided by the 
same solution) and that claim to motivate a questionable hierarchy of 
"critical success factors".  The document is useless as a tutorial or 
primer to the technical specification. 

We have enough capability in our technical solution (FLD/PRD and semweb 
integration), that with a bit of hand-waving about translating xml 
schema to frame axioms, we can represent almost all the use cases in FLD 
(there is 1 use case involving production rules).  The pity is that from 
the UCR document one arrives at the opposite conclusion: that we are 
struggling to organize the problem space (and hence the foray into 
critical success factors).

Details
-------

1 Introduction:
Third para, 2nd sentence: We start by ... developing a basic model of 
how RIF is supposed to work
Where is the mythical Section 2?  It seems to have been deleted (leaving 
the section numbers off by 1).
There should be a short overview of the technical solution (FLD/BLD, 
PRD, Core, RDF+OWL) that we claim addresses the goals and requirements.

2 Use Cases:
The "motivates" sections should all be deleted.  They are confusing and 
vague forward references, and many seem contrived or "stretched".  See 
also comments on the backward references ("motivated by" sections of 
goals and requirements)

2.1
Jane's rule change is suspicious.  Did she mean 18.7% off an entire $500 
delivery just because one bag of potato chips is stale?  Such 
ambiguities would be found quickly if all the examples used (simplified) 
FLD.

2.3
The phrase "the RIF" is awkward.  I think "compiler" should be "translator".

Additional aspects of the use case are introduced in the motivates 
section.  This seems like the author is "stretching" the use case to 
cover more requirements.

2.4
The rule is embarrassingly trivial and does not support the use case.  
The rule is about integration of human workflow into a business process.

3 Goals
All these pictures give the impression that there is some worthwhile 
content here.  That would be misleading. 
I would simply list each goal with a short paragraph explanation and a 
description of how the technical specs address the goal.

4 Requirements
The Motivated By sections are not very useful.  Clearly, some use case 
authors wanted to "stretch" their use case to cover as many requirements 
as they could, and other authors maybe didn't want to bother with the 
extra cross referencing work on the wiki.  The result is very uneven and 
not very motivating.

I would just list the requirements and associated goals along with a 
brief explanation of how the specs address the requirement.

5 Coverage
Somehow, the relationship of this "RIFRAF" to FLD/PRD needs to be made 
clear.  Maybe this section should
just be replaced with references to FLD and PRD.  Otherwise, somebody 
needs to write a chapter about RIFRAF using the existing outline as, 
well, an outline.  And write a chapter (maybe in FLD?) about how FLD 
does/does not handle the various RIFRAF features.
-- 


Oracle <http://www.oracle.com>
Gary Hallmark | Architect | +1.503.525.8043
Oracle Server Technologies
1211 SW 5th Avenue, Suite 800
Portland, OR 97204

Received on Monday, 24 March 2008 18:38:49 UTC