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

Two groups of clauses where named-argument uniterms were used:


RACOFI:

Heads of rules:

modify(amount->"0.5";
       comment->"Adjusting originality rating (by 0.5)
                 for high ratings of other albums
                 by this artist.";
       variable->originality;
       product->?item)

   :- ...


eTourPlan:

Facts:

event(hs.name->"Punakha Dromche" : annual_festival;
      hs.description->"Punakha Dromche take place in the first month of
the lunar year and ends 
                        with 'Serda', a magnificent procession which
re-enacts an episode of the 
                        war against the Tibetan in the 17th century.";
      hs.startDate->211 : Real;
      hs.endDate->215 : Real;
      et.theme->cultural_religious_heritage;
      hs.location->Punakha_Dzong : Western_fortress;
      et.province->Punakha;
 
hs.relatedTo->"http://www.bhutantrips.com/western_bhutan/chimmi_lhakhang
.php").


-- Harold


-----Original Message-----
From: Dave Reynolds [mailto:der@hplb.hpl.hp.com] 
Sent: Monday, January 28, 2008 5:33 PM
To: Boley, Harold
Cc: public-rif-wg@w3.org
Subject: Re: named-argument uniterms [was: regrets telecon on Tuesday]

Boley, Harold wrote:
> 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)

I don't think so. The rules seem to use an object-like representation 
and different patterns match on different subsets of the slots. For 
example the "product" predicate is used with the following pairs of slot

names:
    itemID, lyrics
    itemID, music
    itemID, impression
    itemID, performance
    itemID, originality
    itemID, price
etc, in different rules.

Named argument uniterms can't be used here without explicitly matching 
on all of the product attributes and discarding the unwanted ones 
whereas this does seem like a clear use case for the frame-notation.

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

These seem to be both OOjDrew examples, you've already noted that 
OOjDrew uses named-argument uniterms.

[All the rules I looked at in the second one seem to be conveniently 
expressible in frame notation but I'm happy to take your word for it 
that there are usages of named uniterms in there.]

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

I don't properly understand the notation but again rules like "getName" 
and "getCapitalDistance" seem to matching on only a subset of the slots 
in the "et.place" predicate and look like frame examples again. Which 
are the specific rules and predicates in there for which slotted 
uniterms are required?

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

> 
> -- 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 22:01:15 UTC