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

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

Received on Tuesday, 25 April 2006 00:16:16 UTC