Re: [UCR] Design constraints: early example goal/csf hierarchy --> PR / PRR

On Apr 25, 2006, at 4:00 AM, Vincent, Paul D wrote:

> There ARE good arguments for standardizing syntax (and for that 
> standard
> syntax, the semantics) of programming languages - but it's not for
> re-use of software across for organizations and more for skill and
> quality purposes (as well as avoiding vendor lock-in).

Or reuse inside an org, or when orgs merge.

I think we agree.

[snip]
> AFAIK there is no "chaos" in the rule market place, and the rule
> transformations I am aware of (of course, in my case, chiefly from 
> other
> vendors to Blaze's syntax) have not been overly problematic, being 
> 1-off
> vendor switching:

This all suggests to me that the PR situation is much simpler than I 
feared, which would be a good thing. One thing that would help move 
things along (in my opinion) is a concrete proposal from some rule 
vendor of what they want/need (in terms of features, etc.). A straw 
proposal, perhaps with syntax. Could be a pointer to something with a 
"and it also needs blah blah and blah". Then that would be something to 
build on/formalize/discuss.

> - some could be done via XSLT conversions from other XML 
> representations
> of rules

So RIF would largely obviate that since the engines/tools would 
export/import RIF directly? Or was the XSLT generic? I don't see why 
XSLT wouldn't be a reasonable implementation strategy, I guess.

> - some would have been rearchitected to suit a fwd chaining PR 
> mechanism
> over a bwd chaining PR mechanism

Do you think RIF could make this easier? How?

[snip]
> In terms of PR standards:
> - JSR94 is an engine API - nothing to do with PR except that most PR
> engines provide the API,

Yeah, all I meant was there was some force toward standardizing some 
aspect of it.

>  and precious few other rule types have enough
> users to justify providing a standard API (I'd be interested in counter
> examples though).
> - OMG stuff: well PRR is taking the subset approach, and SBVR deals 
> with
> business rule statements not rules in an executable context.
> - RuleML: see PROLOG, not really anything to do with PR except there is
> the PRR RuleML variant under development, and also mostly a family of
> related schemas for different rule representations (AFAIK not dealing
> with interchange between rule types, although clearly the common schema
> basis would help in the mechanics of interchange)

By "interchange between rule types" you mean converting one type of 
rule to another, or integrating rule sets with different types of 
rules?

> - PROLOG: not really widely used in business, and not limited to PR of
> course.

Thanks for the overview.

> For the effect of standards on the current rules market: well you can
> judge there is some interest (from the vendors in RIF),

Yep.

>  but in terms of
> effect on the market I'd refer you to the "analysts" that cover this
> market.

Pointer? Why is "analysts" scare quoted?

>  AFAIK there has not been any public research on this topic that
> you can read about, so it will need to remain observations from 
> vendors.

Ok. So, do the vendors think that RIF will significantly help grow 
their market? Do they expect new competitors? What's the rough value 
add?  Do they care about anything other than PRs? If not, is there any 
point, to them, to the rest of RIF?

> For the potential of RIF allowing PR to be used across the internet: 
> see
> the use cases.
>
> For the (implied denial of) evolution of rule languages: not sure where
> this discussion came from (all vendor rule languages are evolving /
> growing).

Well, I got the feeling that you were hostile to the idea that we might 
make choices in RIF that would force any specific evolution. Do you 
think that's just unlikely given a de facto large usable common subset 
that would neatly be the basis of RIF PR?

>  RIF includes rule interchange between different vendors (and I
> use the term "vendor" to mean supplier of rule engines, ie including
> open source interests)

Sure.

> - to maximize interchange the subset of PR
> features supported needs to be maximized, but balanced against the
> overall end-user interest in such PR features.

But this is exactly what I argued. I just argued that one way you might 
maximize, and balance overall end-user interest, is given a PR feature 
that is realized in two different languages in incompatible ways, 
mandate one compatible way (either pick a winner, or forge a new one). 
This is something to be done carefully and considerately. But I don't 
see why it should be off the table. It's not a license to run amok, but 
few things are :)

> The way I see this:
> - there are very very few end user organizations in RIF. This could be
> viewed as a lack of interest (per my points on the use of PR outside of
> interchange) or simply delegation to their preferred vendor.

Actually, my experiences is that end user participation in standards 
working groups, at least at the W3C, is minimal. There's some, but we 
get more from the mailing lists and pushback, etc.

> - from the vendor's perspective, it would be good to have a usable PR
> language that is at least a subset of the current PR language 
> evolutions
> from the vendors (no objection to extensions: however by observation, 
> if
> an extension was *really* useful for their audience, it would have been
> implemented)

Well, I was mostly thinking about the case where there were very 
similar mechanisms that just happened to be annoyingly different. 
Entirely new features, I agree, are much more risky and should have 
good evidence before adoption.

> - RIF allows for rule interchange to fail - so there is no reason why
> this cannot apply to PR interchange as well. For example, maybe I can't
> pass a score model from Blaze Advisor to JRules, and I can't pass an
> Ilog constraint set to Blaze Advisor.

And thus, I agree there can be areas undefined, or incompatible. Or 
just defined, and if JRules wants some of that Blaze Advisor market, 
and Blaze Advisor rulesets tend to have lots of score models, then 
JRules will have to support that.

Cheers,
Bijan.

Received on Tuesday, 25 April 2006 10:56:47 UTC