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

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). 

With PR, we are in the position where it is much more likely that PR
will be viewed as re-usable and potentially shareable assets - hence the
need for potential interchange with 3rd parties. I'd guess the closest
we get in the HTML world to this is Javascript / ECMAscript, which
*could* be used for "rule interchange" but has not been sofar (although
it could be used as the expression language within rules).

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:
- some could be done via XSLT conversions from other XML representations
of rules
- some would have been rearchitected to suit a fwd chaining PR mechanism
over a bwd chaining PR mechanism
- most have been business rules, not complex, AI-type rule programming
problems that utilize complex Inferencing strategies.

In terms of PR standards:
- JSR94 is an engine API - nothing to do with PR except that most PR
engines provide the API, 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)
- PROLOG: not really widely used in business, and not limited to PR of
course. 

For the effect of standards on the current rules market: well you can
judge there is some interest (from the vendors in RIF), but in terms of
effect on the market I'd refer you to the "analysts" that cover this
market. 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.

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). RIF includes rule interchange between different vendors (and I
use the term "vendor" to mean supplier of rule engines, ie including
open source interests) - 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. 

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.
- 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)
- 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.

Paul Vincent
Fair Isaac Blaze Advisor --- Business Rule Management
OMG PRR and W3C RIF for rule standards
 -----Original Message-----
From: Bijan Parsia [mailto:bparsia@isr.umd.edu] 
Sent: Tuesday, April 25, 2006 1:15 AM
To: Vincent, Paul D
Cc: RIF WG; Gerd Wagner
Subject: RE: [UCR] Design constraints: early example goal/csf hierarchy
--> PR / PRR
Importance: Low

---- Original message ----
>Date: Mon, 24 Apr 2006 15:53:10 -0700
>From: "Vincent, Paul D" <PaulVincent@fairisaac.com>  
>Subject: RE: [UCR] Design constraints: early example goal/csf hierarchy
--> PR 
/ PRR  
>To: "Bijan Parsia" <bparsia@isr.umd.edu>
>Cc: "RIF WG" <public-rif-wg@w3.org>, "Gerd Wagner" <wagnerg@tu-
cottbus.de>
>
>   I'm afraid I'll have to agree to disagree on many of
>   these points... J
>
>   1. HTML was popularized through internet (later
>   intranet / thin client) applications that meant
>   standards for interpreting HTML were vital. Most
>   production rules in use as such today are utilized
>   to represent private-to-organization business rules
>   - so the need for a single representation is much
>   less.

By this argument, there would be little incentive for standardizing
programming 
languages. Even programming languages that don't go through standards 
bodies (e.g., Python, Perl) have a standardizing force (primary or sole 
implementation).

The argument wasn't from the way HTML was deployed to the
homoginization. It 
was from the rather large amount of chaos in the deployed base (both
browsers 
and websites) toward standardization (however minimal). HTML standards
help, 
some, not perhaps a huge amount, by pulling toward commonality. Any 
reasonable browser has a tag soup parser in there, but I don't think the
browser 
authors regret standardized HTML.

Again, there are trade offs.

In the "internal" context, one serious issue is vendor lock in. Not only
are people 
rightly made nervous from sole sources, but idiosyncratic systems make 
training, etc. harder. These benefits are sometimes worth a bit of pain.

>  For evidence, note the lack of existing PR
>   standards 

RuleML and OMG stuff?

http://www.jcp.org/en/jsr/detail?id=94

(it's an api, but still)

Does Prolog count?

Of course, a market can exist without standards.

> and the lack of effect on the current
>   market for PR systems.

I'm sorry, how on earth do I observe that? Point me to a study or
something.

If there's no use for PR standards, then let's dump PRs from RIF.

>  [Opinion: Of course, the
>   point of RIF is also to enable / encourage the
>   internet use of PR (+ other types of rules)]

I'm sorry, but I find this incoherent. I don't know if I can agree to
disagree with 
incoherence, but I guess I can agree to disagree about whether that was 
coherent :)

>   2. A better analogy rather than HTML is probably
>   SQL: there is ANSI SQL, and there are vendor
>   extensions. ANSI SQL is mostly a subset (AFAIK) of
>   what most companies use. [Opinion: I would expect
>   RIF PR to follow a similar path]

I think you are making far too much of the HTML analogy. It wasn't meant
to 
suggest, and I think my post made it *manifestly* clear that I was not 
suggesting, that we'd end up with one true language smoothed of all
quirks. In 
fact, my point was simply that not all quirks are created equal, that
the working 
group can strive to discern this, and better interoperability is a good
reason to 
scorn some quirks, even if it disadvantages someone. We can't win every
point 
to everyone's satisfaction. We can, however, try to make the overall
result largely 
beneficial.

>   3. On the subject of other computer "language
>   standards" (aka CommonLISP) - that is indeed the
>   point - the agreed standards are generally subsets
>   of what the vendors provide. 

And how has it been suggested otherwise? I thought my point about
dealing 
with quirks by leaving some point undefined caught this. The question
is, for 
any particular quirk, is it overall helpful to leave it undefined.

Usually, the common core is pretty large, one hopes large enough to be
useful 
in its own right.  Consider Java.

> A PR standard (eg PRR)
>   is a subset of the universe of production rule
>   language features, so as to be vendor neutral yet
>   still useful. 

The "still useful" might require evolution on someone's part. Do you
deny the 
*possibility*? I mean, if ILog said, "yeah, we have this weird thing,
only one 
customer ever used it and their happy to change" we should nevertheless 
support it? (yes, this is an extreme, but you don't seem to have staked
middle 
ground or acknowledged my staking of middle ground)

> In time I'm sure it will grow to
>   accommodate bigger subsets.

One must hope that the *common* subset is useful enough, and covers
enough 
real code, to be worth it. If not, frankly, I don't see why I, if I were
a PR vendor, 
would bother to support it, other than for Public Relations (Oh yes, we
support 
that silly W3C standard, just don't think it will help.)

Now I don't know what that useful subset is. And I don't know if there
is conflict 
on that useful subset. To do so, I'd need some language descriptions and

perhaps some survey of actual rulebases.

Please note that I have no particular stake in the PR part of RIF, save
insofar as it 
affects RIF as a whole. But let's get our methodology and principles
straight.

Cheers,
Bijan.
This email and any files transmitted with it are confidential, proprietary
and intended solely for the individual or entity to whom they are addressed.
If you have received this email in error please delete it immediately.

Received on Tuesday, 25 April 2006 08:02:36 UTC