From: Harold Boley (boley@informatik.uni-kl.de)
Date: 06/02/03
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