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

Here are some use cases for named-argument uniterms
(slotted atoms and expressions):

RACOFI: A Rule-Applying Collaborative Filtering System
<http://www.daniel-lemire.com/fr/documents/publications/racofi_nrc.pdf>
(A. RACOFI Rule Listing)

NBBizKB: The New Brunswick Business Knowledge Base
<http://www.ruleml.org/usecases/nbbizkb>
<http://www.ruleml.org/usecases/nbbizkb/NBBizKBRules.posl>

FindXpRT: Find an eXpert via Rules and Taxonomies
<http://www.ruleml.org/usecases/foaf/findxprt>
<http://www.ruleml.org/usecases/foaf/findxprt/FindXpRT.posl>

eTourPlan: A Knowledge-Based Route and Activity Planner for eTourism
<http://v37s3b4h7dn47s37hg1br4h7rs7n3du7s8nu.unbf.ca/~s7kw0/>
<http://v37s3b4h7dn47s37hg1br4h7rs7n3du7s8nu.unbf.ca/~s7kw0/master/lates
tTravelPlan(15.11.07).posl>

-- Harold


-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Michael Kifer
Sent: Wednesday, January 23, 2008 2:33 PM
To: Dave Reynolds
Cc: Igor Mozetic; public-rif-wg@w3.org
Subject: 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 Monday, 28 January 2008 20:40:22 UTC