W3C home > Mailing lists > Public > public-rif-wg@w3.org > January 2008

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

From: Adrian Paschke <adrian.paschke@biotec.tu-dresden.de>
Date: Wed, 23 Jan 2008 13:41:39 +0100
To: "'Dave Reynolds'" <der@hplb.hpl.hp.com>, "'Michael Kifer'" <kifer@cs.sunysb.edu>
Cc: "'Igor Mozetic'" <igor.mozetic@ijs.si>, <public-rif-wg@w3.org>
Message-Id: <20080123124132.543F170000E7@mailserver.biotec.tu-dresden.de>

Dave Reynolds wrote:

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

I would not say that named arguments are necessarily a burden for
implementers writing translators for execution systems supporting only
ordered literals. Default incremented arguments might be a solution which
can be easily implemented in XSLT or programmatic translators. For instance:

   SystemA                RIF                      SystemB
  p(2,"abc") ----> p(arg2("abc"),arg1(2),) -----> p(2,"abc")


-----Ursprüngliche Nachricht-----
Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im
Auftrag von Dave Reynolds
Gesendet: Mittwoch, 23. Januar 2008 10:10
An: Michael Kifer
Cc: Igor Mozetic; public-rif-wg@w3.org
Betreff: 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
>> The only argument in favor of keeping them thus remains to have BLD
>> (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.
> 2. We are not designing a minimalist language, but an *interchange
>    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
>    (there are several ways - I just picked up one):
>    SystemA                       RIF                              SystemB
>    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")) ----->
>    What happened is that two distinct formulas are now mapped into the
>    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 


    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 

Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Wednesday, 23 January 2008 12:42:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:49 UTC