Re: Rules ASCII Syntax: Ordered and Unordered Options

From: Harold Boley ([email protected])
Date: 06/02/03

  • Next message: Said Tabet: "RE: DRAFT: List of Built-ins"
    Hi Sandro,
    
    > > In the example, the individual constant "5.0 percent" can be analyzed as the
    > > cterm percent[5.0], and the constant "2003/04" can be analyzed as either a
    > > positional cterm interval["2003","2004"] or again as an object-oriented cterm
    > > interval[start->"2003";end->"2004"]. Note that square brackets are preferable
    > > for cterms to clearly set them off from the parenthesized atoms.
    > 
    > cterms are construction functor expressions?    This syntax is new to
    > me; where does it come from?   Does it have detractors?
    
    Yes, originally 'complex terms' are exactly what Prolog calls 'structures'. The
    distinction between (round) parentheses for active calls and [square] brackets
    for passive structures was introduced in Relfun -- cf. http://www.relfun.org/ or
    http://www.cs.unb.ca/~boley/cs6905/cs6905FLP.pdf -- and can be seen as an obvious
    generalization of Prolog's list notation via a polyadic tup constructor, so that
    [e1,...,eM] is definable as tup[e1,...,eM].
    
    Later, in Object-Oriented RuleML, we have permitted 'complex terms' to *also*
    contain unordered roles with their fillers,  or -- as in F-Logic -- to *only*
    contain such frame-like 'slots'. In that sense, this is a merger of Prolog and
    F-Logic.
    
    Well, a 'detractor' --  which sounds better as the antonym for 'constructor' than
    'destructor' does -- in a unification-based language such as Prolog, Relfun, or
    F-Logic can be represented by a local unification and variable dereferencing for
    the selected part of the complex data structure (BTW, John McCarthy in his work
    on abstract syntax used 'selector' as the antonym for 'constructor').
    
    So we can access the start date of interval["2003","2004"] by unifying it with
    interval[StartDate,EndDate] and dereferencing StartDate to "2003". Similarly, we
    can access the end date of interval[start->"2003";end->"2004"] via unification
    with interval[start->StartDate;end->EndDate] and dereferencing EndDate to "2004".
    
    But instead of / in addition to this, we can introduce a 'universal' selector sel,
    parameterized by either a positive integer or a role name.
    
    sel[1](interval["2003","2004"]) would return "2003".
    sel[end](interval[start->"2003";end->"2004"]) would return "2004".
    
    The general sel definition is easier to explain for normalized OO cterms, although
    it also works for non-normalized ones.
    
    The most general kind of 'functional' OO cterms are 'left-and-right-rolled' cterms
    of the form
    
    c[r1->f1;...;rL->fL;e1,...,eM;rL+1->fL+1;...;rN->fN]
    
    where 'functionality' means that the role names rJ taken from {r1,...,rN} are all
    different.
    
    Notice that a single sequence of positional elements e1,...,eM is surrounded by two
    sets of unordered elements r1->f1;...;rL->fL and rL+1->fL+1;...;rN->fN.
    
    These can be normalized to a 'left-rolled' cterm
    
    c[r1->f1;...;rL->fL;rL+1->fL+1;...;rN->fN;e1,...,eM]
    
    or to a 'right-rolled' cterm
    
    c[e1,...,eM;r1->f1;...;rL->fL;rL+1->fL+1;...;rN->fN]
    
    (Further normalization by lexicographic sorting of the role names rJ would permit
    'linear' term comparisons, but is out of scope here.)
    
    Now, without loss of generality, for any right-rolled cterm
    
    t = c[e1,...,eM;r1->f1;...;rN->fN]
    
    we can introduce the universal selector sel, parameterized by either I or rJ:
    
    sel[I](t)  = eI    for  I  from {1,...,M}
    sel[rJ](t) = fJ    for  rJ from {r1,...,rN}
    
    As we have a direct representation of positional information in the e1,...,eM part,
    we don't need here positive integers as role names in the r1->f1;...;rN->fN part,
    although these or RDF's _1->e1;...;_M->eM could be used to simulate e1,...,eM.
    (The other way round, slot[r1,f1],...,slot[rN,fN] plus normalization could simulate
    r1->f1;...;rN->fN.)
    
    > > discount(Customer,Product,percent[5.0];
    > >          region->"MA";
    > >          period->interval[start->"2003";end->"2004"])
    > >  :-
    > >     premium(Customer;period->interval[start->"2003";end->"2004"]),
    > >     regular(Product).
    > 
    > > These options are offered to accomodate various positional and object-oriented
    > > modeling styles.
    > 
    > It's all pretty interesting.   Do you have code to translate between
    > these forms?   I guess to go between purely positional and the form
    > with role-names, you'd need some kind of declaration information,
    > giving them names of the different role positions.   Unlike in
    > programming languages, you don't just have a formal parameter name you
    > can use....
    > 
    >     -- sandro
    
    Well, Marcel A. Ball has Java code to translate between a somewhat more sloppy
    syntax and OO RuleML, and he is working on the more stringent form presented here.
    We'll let you know, and it will be reachable via http://www.ruleml.org/indoo.
    I guess it is easy to write a translator in Python as well.
    
    To go -- in both directions -- between positional and rolled forms, Stephen Greene
    has XSLT-implemented 'signature' declarations for the information you mention; the
    development URL is http://198.164.40.138/ruleml/ooruleml-xslt/, and a URI will later
    be reachable again via http://www.ruleml.org/indoo. The ideas of 'positionalizing'
    are based on earlier work Michael Sintek and I did at DFKI.
    
    Best,
    Harold
    


    This archive was generated by hypermail 2.1.4 : 06/02/03 EST