Re: [UCR] Design constraints: early example goal/csf hierarchy

Michael Kifer wrote:
> On 04 Apr 2006 Dave Reynolds <der@hplb.hpl.hp.com> wrote:
> 
>>This is an incomplete attempt to sketch out an example goal/csf/requirement 
>>hierarchy to help me at least see the wood for the trees.
>>
>>This is not "right", just preliminary musings, so it can't go into the 
>>Design Constraints page (violates the stated ground rules for that). Posted 
>>in its current highly preliminary state in case it is a useful seed.
> 
> 
> Dave,
> This is a good high-level start. It needs to be refined and weeded out
> (i.e., there are problems :-)
> See below.

Sorry to be slow to respond - just back from holiday.

>>** Goals
>>G1 Enable effective interchange of rules between existing rule systems
>>G2 Widespread adoption
>>G3 Foundation for a semantic web rule language
>>
>>** Breakdown
>>
>>G1 Enable effective interchange of rules between existing rule systems
>>  C1.1 Able to express the main features of relevant commercial rule systems
>>    R1.1.1 Support for production rule languages
>>    ...
> 
> 
> The devil is in the details. What is "effective" supposed to mean?  

Whatever we want it to :-)

Goals aren't themselves measurable, they are broad statements of intent 
which get more measurable as you turn them into requirements.

I'd agree that my examples were light on details and precision but I felt 
brevity was more important, to help see the overall shape. The detailed 
versions can get thrashed out on the Wiki but I was trying to address my 
own concerns that the linear Wiki encouraged focus on the details while 
missing the gestalt.

> If you
> intended that one set of production rules for Vendor X's engine will pass
> through RIF and emerge on the other end as a bunch of rules for Vendor Y's
> engine and the results will stay the same then keep dreaming.

The rule vendors can address this better than I ... however, I've been 
assuming that there is some interesting subset of customer applications for 
which use of Vendor X's feature set can be sufficiently constrained that 
translation to vendor Y's rule language is indeed possible, at least so 
that the results from the translated ruleset will be equivalent as far as 
application-observable effects are concerned.

If that's not the case then what's the point of RIF for the production rule 
vendors?

>>  C1.2 Interchanges can be meaning preserving
>>    R1.2.1 RIF semantics is clear and precise
>>    R1.2.2 RIF semantics is compatible with the rule languages to be
>>           exchanged
> 
> 
> I hope that by RIF you mean a family of languages and you take the word
> semantics as plural (i.e., that there will be different semantics for
> different sublanguages of RIF).

Agreed.

>>  C1.3 Cohesive, sufficiently few RIF dialects that there is useful
>>       interchange
> 
> 
> I may be reading too much into your "sufficiently few" here, because later
> you talk about extensibility. But just in case, let me say this.
> 
> One important requirement is that RIF should be *useful* and should not
> become irrelevant as technology marches on. This implies that RIF should be
> extensible, and this flies in the face of the "sufficiently few" requirement.
> 
> I agree that we should start with few well-known paradigms, but the
> mechanism should be designed thoughtfully to enable extensibility.
> One way to do that is to propose a taxonomy of languages characterised by
> their salient semantic and syntactic features, as we proposed at the F2F.

I fully agree that RIF is extensible and there shouldn't be arbitrary 
limits on that extensibility.

This CSF is simply an encouragement to moderate the number of RIF dialects 
we start off with. If we start off with N RIF dialects where N ~= length of 
our list of rule languages then we don't achieve much useful interchange. 
Clearly N ~= 1 is not tenable either. This CSF is an encouragement to us to 
look for a modest number of useful starting dialects.

>>   R2.2.2 Sufficiently inexpressive that RIFdialect -> RLj is easy
> 
> 
> Can't make sense out of it. If RIF is as expressive as every RLi then what
> does it mean to be "sufficiently inexpressive"?

The expressivity referred to the RIFDialect (and thus also to RIF Core) 
rather than RIF overall.

If RIF Core is too expressive (or example the first draft charter called 
for the core to be FOL with equality) then the task of an implementer 
trying to translate any RIFDialect into their specific rule language is 
untenable. I'm trying to say it should be possible to have RIFDialects that 
are sufficiently constrained that the job of the implementer of the 
consuming-translator is reasonable, that it is possible for a vendor to 
reasonably say we support RIFDialects "foo" and "bar".

As stated this is not yet a sufficiently well defined requirement, it's 
certainly not measurable. However, if the principle was acceptable to the 
working group I should think it could be turned into an adequately 
requirement.

I was, naively, seeking some agreement on the broad principles and shapes 
of the requirements that could then be refined into more precise statements.

>>  C3.3 Compatible with OWL
>>   R3.3.1 RIF Standard inference and OWL inference can be combined in a
>>           well-defined fashion
> 
> 
> RIF "standard" inference? There can be no such thing given the diversity of
> the group. There are at least 3 streams in the RIFWG: pure FOL, logic
> programming, and production rules. Another member has joined recently,
> which brings in one more: reactive rules.

Agreed, bad phrasing on my part.

> In my F2F2 presentation mentioned above and in the RuleML 2005 paper
> http://www.debruijn.net/publications/msa-ruleml05.pdf
> a realistic hybrid architecture was proposed, which allows to combine the
> different paradigms in a loosely coupled fashion.

"combined in a well-defined fashion" was supposed to include such options, 
so you could propose a hybrid architecture as a way of meeting this 
requirement.

> It is more realistic to push for *interoperability* among RIF dialects and
> OWL/RDF rather than for "compatibility." In some important cases, compatibility
> is achievable (as shown by Rosati), but we should allow more flexibility
> (what we called "ad-hoc interoperability" in the DERI/RuleML presentation
> at F2F2).
> 
> It is thus more realistic to build RIF around the roadmap that Harold presented
> at F2F2
> http://www.w3.org/2005/rules/wg/wiki/F2F2?action=AttachFile&do=get&target=RoadmapSessionSlides
> http://lists.w3.org/Archives/Public/public-rif-wg/2006Feb/0255.html

Well, having missed F2F2 (and there being no phone or IRC access of any 
utility) I don't fully understand that roadmap but I took it to be roadmap 
for the for the actual design work. So again it sounds like an answer to 
the requirement rather than a different set of requirements.

Dave

Received on Tuesday, 18 April 2006 17:25:33 UTC