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

I'm afraid I'll have to agree to disagree on many of these points... :-)

 

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. For evidence, note the lack of existing PR
standards and the lack of effect on the current market for PR systems.
[Opinion: Of course, the point of RIF is also to enable / encourage the
internet use of PR (+ other types of rules)]

 

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]

 

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. 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. In time I'm sure it will grow to
accommodate bigger subsets.

 

Just my 2 cents!

 

Paul Vincent

Fair Isaac Blaze Advisor --- Business Rule Management

OMG Standards for Business Rules, PRR & BPMI

 

-----Original Message-----
From: Bijan Parsia [mailto:bparsia@isr.umd.edu] 
Sent: Sunday, April 23, 2006 11:42 PM
To: Vincent, Paul D
Cc: RIF WG; Gerd Wagner
Subject: Re: [UCR] Design constraints: early example goal/csf hierarchy
--> PR / PRR

 

On Apr 23, 2006, at 2:25 PM, Vincent, Paul D wrote:

 

> Gerd - I don't think comparing the state of standardization in current


> PR systems with HTML is very useful.

 

I disagree.

 

>  The latter was defined as a "standard" from the start,

 

And companies added tags left right and center from the start. It also 

had a very liberal (vauge even) semantics. Browsers added tags to be 

competitive and distinguish themselves. People relied on browser 

dependent understanding of the meaning of tags. I think of production 

rules as having  a fairly similar history.

 

>  for distributed (+ public) internet access. A better analogy would be


> to complain that the semantics of Java/Java byte code and .NET/CLR are


> different (and we don't want to open that can of worms).

 

Both of these were single source, primarily defined by implementation 

(though then good descriptions and standard, or semistandard, 

definition). .NET/CLR was also pretty certainly designed to be 

incompatible :)

 

> The reason for PRR and PR in RIF is to share rules across different 

> systems.

 

Which is not remotely the purpose of Java byte code and .NET/CLR (at 

least if "different system" is defined as JVMs vs. .NET systems). 

Hence, I think the analogy fails :)

 

> In time, if the standard is successful, then it may take on some role 

> of leading the semantic definitions for PR engines / use.

 

Consider Common Lisp, or, indeed, any language standard. If you want 

interoperabilty and portability, you have to accept some compromise. 

The goal is to agree upon the stuff that no one wants to compete on 

anymore, so that the entire market can grow. So, I'd be pretty shocked 

if vendors were completely unwilling to evolve a bit. Of course, 

sensibly, they'll try to evolve as little as they can (while hopefully 

making everyone else evolve more), but that's ok. We just have to 

recognize that absolute fidelity to the quirks will make the task MUCH 

harder and the result less useful. For everyone.

 

> But there is a long way to go yet!

> 

> PS: I would expect all PR vendors to have well defined semantics for 

> their rule engines.

 

This would be great. I would ask that all PR vendors on the working 

group supply these documents as soon as possible so we can study them. 

Or is there a wiki page for these already?

 

>  I would not expect RIF to take on the challenge of deciding which 

> particular PR semantic was "correct" - what may be a quirk to one 

> person may be an essential productivity saver to another!

 

And some people will be, or will feel that they have been, screwed. 

It's unfortunate, but too bad for them. We risk the whole endeavor if 

we try to deal with everything.

 

Note that there are ways and there are ways. One way is to make some 

quirk *illegal*. Another is to make an area in which quirks abound 

*undefined*. *Both* are problematic. One of our jobs is to decide when 

the tradeoff are worth it. Vendors and customers will give pushback, so 

it's not like we are making these decisions entirely in isolation. In 

fact, it's important to gather data about what people are willing to 

give up, and what the costs are.

 

Balancing legacy and sanity is a tricky task...but they must be 

*balanced*, not relentlessly adhered to.

 

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.