Re: [PRD] Issues to resolve before publication (NAU)

Christian de Sainte Marie wrote:
>
> Gary Hallmark wrote:
>>
>>> One a more argumentative note: "it is in BLD so it must be in PRD" 
>>> strikes me as a particularly non-technical argument (ideological, I 
>>> would say, if I had to qualify it).
>>
>> I can prove that case B has measurably greater interoperability than 
>> case A:
>
> Yep. But your proof is besides my point:  although you insist on 
> ignoring it, my argument is that we have to balance PRD-BLD 
> interoperability with usability by (legacy) PR systems.
>
>>> Whereas: "most mainstream production rule languages do not have 
>>> them" sounds like a rather technical argument to me, when it comes 
>>> to standardising the XML srialisation of production rule languages.
>>
>> As Harold and Adrian have pointed out, Clips (and Jess) have named 
>> argument uniterms.  Your argument sounds like "PRR doesn't have it".  
>> Alignment with PRR is not something I care about.  It looks like a 
>> committee-produced syntax with no semantics.  Hopefully we can do 
>> better.
>
> Apologies. I should have written: "as far as I know (and I know 
> little), most mainstream...". But I do not see clearly why you mention 
> PRR here.
>
> As I said in earlier email, the question about NAU in PRD might be 
> different from the answers it got in BLD, because the balance between 
> PR systems that have them and PR system that do not have them may be 
> different.
>
> The real question is therefore (as I stated it in [1]): "what is the 
> respective weight of "all the
> languages" on each side [that would have to implement NAU but do not 
> use them VS that would have to positionalize their NAU] (and the 
> answer may be different for logic
> languages and PR languages). My understanding is that, wrt PR languages,
> the balance is heavily tilted towards positional only. But I may be 
> wrong."
>
> I was aware only of CLIPS. You mention Jess as well. Ok. That is 
> already more than I thought. Let us continue the discussion along that 
> line.
This is related to "named" arguments on patterns? i..e. a pattern for
(person (name "mark") (age 32) )
"including named-arguments atoms in PRD will force all the languages 
that do not have them to implement the feature,"

Which PR system doesn't support this? ilog does, drools does, clips 
does, jess does, opsj/fic does ?

I'm am heavily against the push to forcing bindings of patterns so that 
we have to do
$p : Person()
eval( $p.name == "mark", $p.age == 32)

This was forced as part of the PRD last year, which we demoed as part of 
the RuleML conference. I would like to see this solved, so that binding 
is optional and not forced. I know that ILog tooling tends to generate 
most of it's rules this way and internally analysis this to "pull up" 
the constraints into the pattern for performance, but I still don't 
think that is a good approach. We need good pattern matching 
capabilities, not cludged ones.

It's the ordered facts that not all engines support, which Jess/Clips does
(grocery-list bread milks eggs)

I don't believe a special construct is needed for that, as both Jess and 
Clips implement this as a named fact with one field which is a List. So 
if PR eventually supports Lists then this can be accomodated, as is.

>
> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0082.html
>
> Cheers,
>
> Christian
>
>


-- 
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, 
SI4 1TE, United Kingdom. 
Registered in UK and Wales under Company Registration No. 3798903 
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)

Received on Tuesday, 1 July 2008 12:29:53 UTC