- From: Axel Polleres <axel.polleres@deri.org>
- Date: Sun, 03 Feb 2008 11:16:47 +0000
- To: Jos de Bruijn <debruijn@inf.unibz.it>
- CC: RIF WG <public-rif-wg@w3.org>
Jos de Bruijn wrote: > > > Axel Polleres wrote: >> >> In the last Teleconf, I was asked to try o separate the issues coming >> up about fct vs predicate forms for builtins. >> >> Let's go: I think that there were several questions: >> >> >> a) whether to allow only predicates, and no predicates, i.e. >> generally model functions as predicates. > > I don't think anybody was proposing to not allow any built-in > predicates. Certain operators, such as numeric comparison, are in fact > relations and are thus naturally represented as predicates. yes, jos... was obviously a typo... sorry for the sloppy writing this should be: a) whether to allow only built-in predicates, and no built-in functions, i.e. generally model functions as predicates. > Regarding the question whether to allow only built-in predicates or both > functions and predicates: I'm leaning towards only allowing predicates > (because it makes the language simpler), but I don't have a big problem > with functions being allowed as well. As for not allowing functions, the example below should demonstrate that this would could mean considerable blow-up by necessary auxiliary variables when rewriting nested function terms. But I am not religious about any of the solutions. This said, I mean if we can cleeanly define them as well, built-in functions would be nicer to write sometimes, but we don't need them strictly speaking. Seems we pretty much agree here. Axel >> For explanation, any n-ary built-in function >> (with a single return value) >> f(p1, ... , pn) >> in a RIF rule head or body, can be rewritten to an n+1-ary >> predicate as follows: >> >> Head :- ..., Pred(...,f(p1, ... , pn),...),... . >> >> -> >> >> Head :- ..., Pred(...,Val_f,...),..., P_f(p1, ... , pn,Val_f). >> >> >> This also shoud work in the rule head: >> >> >> Pred(...,f(p1, ... , pn),...) :- ..., . >> >> -> >> >> Pred(...,Val_f,...) :- ...,,..., P_f(p1, ... , pn,Val_f). >> >> >> so, theoretically, built-in functions are not needed, although they >> provide more concise writing, especially, when they are nested, >> imagine: >> >> >> Head :- ..., Pred(...,p1+p2*p3-p4,...),... . >> >> te rewriting looks farily ugly: >> >> Head :- ..., Pred(...,Val_3,...),... Mult(p2,p3,Val_1), >> Add(p1,Val_1,Val_2) Minus(Val_2,p4, Val_3). >> >> >> An "intermediate" proposed solution in the last teleconf was to have >> one special predicate to evalutate (possibly nested) functional terms >> similar to the "is" predicate in Prolog. > > This is yet another issue. > And it is only relevant if we were to consider a dialect without equality. > The only argument I heard in favor of this special predicates is that if > you want to use the same extterm in several places in your rule, then > you do not need to repeat the term, but the only variable to which you > assign the outcome of the function. > > If we were to decide to include this predicate in the language, then we > need to decide whether built-in functions may only be used in this > special predicates or whether they may be used anywhere. > >> >> b) whether the same built-in should be (dis)allowed to have both a >> function and a predicate version. This is, if we allow both, built-in >> functions and predicates, whether there should be both a >> built-inpredicate And functions for the same purpose. > > All kinds of built-in functions and predicates may be used with RIF that > have not been foreseen in the language design. Therefore, I don't think > it is realistic to "allow" or "disallow" duplication. However, if we > decide to use both built-in functions and predicates, then we should > decide for each operator we define whether it is going to be a function > or predicate. > > Best, Jos > >> >> That was all as far as I could get it. >> Additions/Clarifications welcome before the next Telecon! >> >> Axel >> > -- Dr. Axel Polleres email: axel@polleres.net url: http://www.polleres.net/ rdf:Resource owl:differentFrom xsd:anyURI .
Received on Sunday, 3 February 2008 11:17:18 UTC