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

Dave,

Why argue the obvious? And what will you do with SystemA's predicates
of the form

pFooBar(2, "abc")
or
pNameEncoded(foo(2), bar("abc"))

What will be their representation in RIF (to avoid collision)?

If you have a complete and reasonable proposal, please present it.

To simplify the job for you, I'll give you the hint. To avoid collision,
you will need to mangle **all** predicates and function symbols into
something unique --- not only the ones with named arguments. The result
will be that such systems will be severely discriminated against in RIF.
And then there is a serious problem with such encodings when one wants to
use those predicate names as constants.

If we decide that terms with named arguments are to be mangled, then
why not mangle everything into just positional representation? Then RIF
will be the simplicity itself and we will not need to discuss anything.
Everything will be pushed to the implementors of RIF translators (but who
cares about them? :-)


	--michael  


> 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 18:33:06 UTC