Re: named-argument uniterms [was: regrets telecon on Tuesday]

Michael Kifer wrote:
>> After recent email interchanges I realized that named-arg uniterms bring
>> very little (just possible args reordering, but one has to list them all).
>> The only argument in favor of keeping them thus remains to have BLD general
>> (and define various useful profiles).
>> For my taste the little gain doesn't justify complications, therefore
>> I am reversing my straw poll vote: I'm in favor of not including them in
>> BLD but will not object to have them.
>>
>> Regards,
>> Igor
> 
> 
> I think this debate is loosing sight of what we are trying to accomplish.
> Here are some points to clarify things.
> 
> 1. Positional notation, frames, and named arguments are three equivalent
>    notations. One can encode the other two, and there is no gain in the
>    expressivity.
> 
> BUT
> 
> 2. We are not designing a minimalist language, but an *interchange format*.
>    The goal is to be able to send rules like this:
> 
>    SystemA ----> RIF ----> SystemB
> 
>    Suppose that both systems support named arguments and want to
>    communicate through RIF, but RIF does not support named arguments.
> 
>    In that case, the two systems would have to encode named args as follows
>    (there are several ways - I just picked up one):
> 
>    SystemA                       RIF                              SystemB
>    p(foo->2,bar->"abc") ----> p(foo(2),bar("abc")) -----> p(foo(2),bar("abc"))
> 
>    The big trouble is that if SystemA & SystemB also support positional
>    predicates then p(foo(2),bar("abc")) is also a valid formula in both of
>    those systems.  So:
> 
>    p(foo(2),bar("abc")) ----> p(foo(2),bar("abc")) -----> p(foo(2),bar("abc"))
> 
>    What happened is that two distinct formulas are now mapped into the same
>    thing and no exchange is possible. At least, not in a natural way.

Not at all, at least it depends on what you mean by "natural". Clearly 
the predicates names that the SystemA->RIF translator uses will not in 
general be the same as those used within SystemA - most systems don't 
use URIs internally for a start. I would expect it to choose options 
more like:

    SystemA                       RIF
    p(foo->2,bar->"abc") ----> pFooBar(2, "abc")

[Where I don't mean the argument names are literally encoded in the 
predicate name but that the predicate name is distinct and may be linked 
to a specific data model out of band if that is relevant to the 
interchange.]

or:

    SystemA                       RIF
    p(foo->2,bar->"abc") ----> pNameEncoded(foo(2), bar("abc"))

neither of which lead to any such overloading.

I agree that interchange of rules between two systems that use named 
arguments will be more natural with an interchange language that 
supports named arguments. The issue for us is that every convenience 
feature like this you put in the language for one set of users is a 
burden to all implementers. The implicit question discussed on the 
telecon was whether this is a sufficiently minority interest that the 
extra burden to all implementers out weighs the convenience of a few.

There was a general sense that at this stage erring on the side of 
simplicity would be a good default policy.

[None of which changes my voting which was in favour of dropping but not 
opposed to keeping named arguments. We can't implement or support BLD 
anyway!]

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Wednesday, 23 January 2008 09:10:15 UTC