Functional-Logic RDF [was: function terms in Euler, n3, and

---------------------- Forwarded by Jos De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER on
14/03/2001 10:40 ---------------------------


boley@informatik.uni-kl.de@INTERNET@informatik.uni-kl.de on 08/03/2001 18:52:14

To:   connolly@w3.org@INTERNET, Jos De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER@AGFA
cc:   www-rdf-logic@w3.org@INTERNET, mdean@bbn.com@INTERNET
Subject:  Functional-Logic RDF [was: function terms in Euler, n3, and
jos.deroo.jd@belgium.agfa.com wrote:

> I'm also sure that Harold can tell much more about functional/relational
> matters (RELFUN etc...)

RELFUN (http://smi-web.stanford.edu/people/boley/lnai1712.html) regards the
discussed 'function terms' as 'constructor terms', which just denote values.
On the other hand,  'defined-function applications' actually compute values.

Example 1: The function symbol "owner" could be user-defined by a rule
or 'directed equation' owner(car17) = john. Now, the first premise of
the 'functional Datalog' rule

buy(Person,Object) <- pay(Person,owner(Object)) and take(Person,Object)

is an "owner" function call nested into a "pay" relation call. With
additional facts pay(fred,john) and take(fred,car17) also asserted,
the "buy" relation call buy(fred,car17) would be computed thus:

buy(fred,car17)

pay(fred,owner(car17)) and take(fred,car17)

pay(fred,john)         and true

true                   and true

true

So, owner(car17) _computes_ the actual owner individual, rather than
just _denoting_ it, as a structure with a constructor symbol "owner"
would. For such an "owner" structure in the first premise RELFUN would
have used square brackets like pay(Person,owner[car17]); but then one
asserted fact would have to be non-Datalog:  pay(fred,owner[car17]).

RFML (http://www.relfun.org/rfml) has been designed as a Functional-Logic or
Relational-Functional Markup Language for the interchange of such definitions.

RuleML (http://www.dfki.de/ruleml) currently assumes that nestings have been
statically flattened. Thus, pay(Person,owner(Object)) would have to be trans-
formed into a conjunction  Ownob = owner(Object) and pay(Person,Ownob), where
Ownob is a fresh variable.

Example 2 (http://www.dfki.de/ruleml/RuleML-RDF/sld009.htm and .../sld010.htm):
The URI-valued function "uriexp" in these slides exemplifies URIs as 1st-class
citizens according to the current XML-based RuleML 0.7. .../sld013.htm ff. show
possible RDF versions of RuleML. An RDF-like graph for a rulebase defining the
"uriexp" function can approach the compactness of the corresponding XML tree by
using N3-like (typed) anonymous resources as nodes; e.g., "nano" is the type of
anonymous resources that apply a functional operator to N arguments (here N=1):


        rulebase
        |      |
Element |      | Element
        |      |
        |      v    Lhs        Operator      Name
        |      eq-------->nano---------->fun------>uriexp
        |       |           |
        |       |      Arg1 |
        |   Rhs |           |
        |       |           v  Name
        |       |          ind------>oil
        |       v
        |   http://www.ontoknowledge.org/oil/
        |
        |
        |
        v    Lhs        Operator      Name
        eq-------->nano---------->fun------>uriexp
         |           |
         |      Arg1 |
     Rhs |           |
         |           v  Name
         |          ind------>daml
         v
     http://www.daml.org/


The computation for answering a 'query graph' like


        Operator      Name
   nano---------->fun------>uriexp
     |
Arg1 |
     |
     v  Name
    ind------>oil


first retrieves an eq(uation) with a unifying or matching (here even identical)
Lhs; the query is then rewritten by the possibly instantiated Rhs. This repeats
until no (more) eq's, nano's, or atom's remain. Here, the result, after a single
rule application, would be the 'answer node'

http://www.ontoknowledge.org/oil/

The trace in Example 1 assumed an innermost ('call-by-value') rewriting, the
most simple and usually sufficient strategy. Other relational-functional
nestings may favor more refined strategies, as discussed, e.g., in the Curry
Mailing List at http://www.informatik.uni-kiel.de/~mh/curry/listarchive/.

Harold Boley, DFKI http://www.dfki.de/~boley/

Received on Wednesday, 14 March 2001 04:40:48 UTC