Hi all, First off, my impression is that having a builtin do non-trivial query of the graph (i.e., that depends on more inference), or modification of the graph, is not supported. That said, I'd like to do something akin to it, and I'm looking for suggestions.
I have a simple expression evaluator (essentially a simple lambda-calculus interpreter) whose expressions can be encoded in RDF. In the simplest case, I have a builtin called Eval which takes two arguments, an expression, which should be concrete, and a result which may be either a variable or concrete node. If the result is a variable, then Eval binds the result of the evaluation to it, and matches, and if the result is concrete, then Eval compares the evaluation result with it, and succeeds if they are the same (approximately with the primitive equal builtin). Now, the expression language that Eval can handle has some primitives for querying RDF graphs. The primitives are based on those presented in a recent paper [1]. The idea here is to be able to write an expression denoting a function of x, e.g., "the sum of the values of the hasValue property for all the resources related to x by the relatedTo property" and to store the result as a property of x. E.g., with the data x relatedTo y, z . y hasValue 3 . z hasValue 4 . we would compute the value 7. This is generalized by a rule that says (?s ?p ?o) <- (?s hasComputableProperty ?p) (?s hasComputableExpression ?e) Eval(?e,?o) . Now the problem of recursion comes up when the values of y and z are not stated explicitly, but should also be computed by this same rule. Eval doesn't have access to the InfModel directly, but through the context can access the InfGraph, but simply querying it from within Eval causes problems with recursive query. (I assume that this is to be expected. If it is not, please let me know, and I can reply with the particular errors that I'm encountering.) Has anyone done anything like this, or does anyone have any suggestions for handling things like this? So far, I've considered adding some preconditions to the rule that would require that computable properties of related resources must be computed first (which would require more explicit connections in the data), or having Eval return some sort of continuation or promise/delay type object, or a new rule that could finish the computation when more information becomes available. I think this is pushing the boundaries of the rule engine, but any and all suggestions are welcome! //Joshua [1] http://ceur-ws.org/Vol-921/openmath-01.pdf -- Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
