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

On Apr 25, 2006, at 1:32 PM, Vincent, Paul D wrote:

> Added comments below (hope my notes are not boring anyone)...

Not me. But if the chairs think it's inappropriate we can take it off 
line or wrap it up.

[snip wanting a PR description as a starting point]
> I’d expect the PRR spec to provide this input. We’ll be updating this 
> soon and will be made available to the RIF group.

Oh, cool. Great.

>> By "interchange between rule types" you mean converting one type of
>> rule to another, or integrating rule sets with different types of
>> rules?
> AFAIK RuleML itself does not address rule language interchange. I’d 
> bounce this question to Harold, Gerd, Said and Benjamin.

Harold, Gerd, Said, Benjamin? I had certainly always *thought* of 
RuleML as addressing rule language interchange!

Hmm. Not a ton of evidence, but on <http://www.ruleml.org/#Translators> 
I see:

	"""Since RuleML should help rule-system interoperation, (XSLT, ...) 
translators for RuleML rulebases are rather important. Please send us 
further translator pairs between your system and RuleML -- even if your 
translators are (still) partial."""

Bit ambivalent. I.e., that rule exchange is sort of an accidental 
consequence :) I see analogies to MathML, so I guess it's just 
primarily a rule language (or a language for marking up rules?) that 
happens to have a wide enough scope to be useful for exchange?

Does anyone have a crisp assessment of what RuleML is and how it does 
or does not address interchange? I feel rather mushy on the topic.

Hmm. Perhaps RuleML is a rule language that may be *compiled* to 
various other rule languages as an intermediate target? Such 
compilation might lose details that are essential software engineering 
aspects of the original rule set?

(Note: I'M MAKING THIS UP AS A HYPOTHETICAL. No rule sets were harmed 
in the making of this hypothetical. Any resemblance to real scenarios 
or languages is entirely coincidental) So, suppose I have a rule set in 
Jess and I want to translate it to Clips (a pain), via RuleML. Roughly, 
would it be like decompling .NET CLR to Java, then compiling the Java 
to bytecode, and then expecting the bytecode to be something I could 
inspect, tweak, modify, adapt? (Note, that's rather extreme! More 
realistically, little things might get lost like comments, subtle 
aspects of the semantics, maybe have to have a larger encoding, etc.)

So, interchange aims at preserving the rule set as a human oriented 
artifact? Whereas mere semantic compatibiilty (in some sense) allows 
for e.g., an exponential blow up in the encoding plus gensyms?

(The analogy there would be using KAON2's reduction of SHIQ to 
disjunctive datalog, and then hoping to load the result into protege.)

I'm stumbling around here :)

[snip]
>> Pointer? Why is "analysts" scare quoted?
> [http://www.gartnergroup.com/DisplayDocument?doc_cd=125811 and similar 
> via Google]
> Not everyone likes analysts 
> [http://blogs.pathf.com/business_rules/2006/03/shocking_forres.html]

Thanks!

[snip]
> “Standards are good”. Basically, a standard for rule interchange of 
> production rules will open up all the internet-based applications that 
> today rarely make it out of the lab. We have had several B2B customers 
> interested in swapping rules around, and of course they would prefer 
> to use an agnostic format. Increasing government use for production 
> rules also means that rule standards would be a market opener for 
> vendors.

Thanks again.

[snip]
>>  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?
> I’m certainly hostile to the idea that RIF will invent new 
> requirements for rule engines and languages without end-user 
> validation.

That's reasonable. I trust you acknowledge that afaict no one was 
proposing that. Indeed my discussion was trying to illustrate the kind 
of considerations we might bring to end users ("Hey, yes, you'll have 
to change some stuff, but ever after migration will be way cleaner, 
blah blah blah.") Of course, that's an in principle argument. It's easy 
to delude oneself in the throes of invention or "clean up", so good, 
antecedent agreement as to the reality checks is a good idea.

>  But it is unlikely that RIF-PR will be very different from the PRR 
> standard (almost by definition).

Interesting. Sorry to be pestery, but is there much more than the W3C 
stamp to add? (Which is *fine* by me. I like easy wins. Actually, I 
adore easy wins!)

Cheers,
Bijan.

Received on Tuesday, 25 April 2006 18:03:01 UTC