Re: [TED] ACTION-294: Propose a treatment of sequences

Dave Reynolds <der@hplb.hpl.hp.com> writes:
> 
> Given that the proposed mapping of RDF to RIF will map the triple 
> (s,p,o) to the Frame s[p->o], then RDF lists will end up as nested RIF 
> Frame structures:
> 
>    _:1[rdf:first->a, rdf:rest->
>        _:2[rdf:first->Y, rdf:rest->
>            _:3[rdf:first->c, rdf:rest->rdf:nil]]]
> 
> rather than nested function symbols.
> 
> It would convenient if the RIF list builtins worked on RDF lists.
> 
> Possibilities include:
> 
> (1) Use nested-frame rather than nested-pair representation for lists (I 
> suspect this is too ugly to be acceptable but thought I'd mention it).
> 
> (2) Include in the RIF-specified RDF mapping a transformation so that 
> RDF lists map to RIF lists.
> 
> (3) Let individual applications include mapping rules which explicitly 
> map the nested-frame structures to RIF lists and say nothing about RDF 
> lists in the spec.
> 
> I'm not sure I like any of these and so don't have a specific proposal 
> at this stage. I'm just mentioning it in case anyone has another take on 
> this issue.

Just to give a little context, I believe it's long been understood that
one can represents lists with cons+nil (or pair+nil as Harold calls it)
or car+cdr+nil (first+rest+nil as RDF calls it).  The first approach
uses a binary function or a ternary predicate; the second uses two
binary predicates.  The difference seems to be one of style, and perhaps
efficiency when using certain implementation techniques.  

>From a different angle, I believe this is an instance of the common
duality between functions and predicates, and also the one between n-ary
predicates and frames.

If you turn the pair function (pair_f) into the pair predicate (pair_p):

     L12 = pair_f(1,2)
=>
     pair_p(L12, 1, 2)

then convert the 3-ary pair_p predicate into two 2-ary predicates, in
the frame style (since L12 works as an Id here), we get the RDF list
serialization Dave gave above.

What I'm wondering is if knowing this is a common duality, which will
appear in many applications, helps us.  There will be rulesets that
represent the same knowledge in logic-functions, n-ary predicates, and
frames -- and the designers will know they mean the same thing, and
users will want to interchange/combine them.  Should they write their
own conversion rules every time (Dave's option 3), or can they just
declare (function x=predicate y =slot-names z1,z2) and have the
conversion be automatic?  If it's the latter, then maybe we've solved
the instance of this problem for sequences, saying "it's both; use
whichever you like."

Another approach (which seems heretical to RIF) is to just provide one
option (eg only binary predicates) and force everyone to convert to/from
that style.  That gets us semantic interoperability without needing to
convert between the different styles.  (This is what SWRL does.)

     -- Sandro

Received on Tuesday, 19 June 2007 12:03:16 UTC