Just copying Adrian Walker's followup to the list. His response wasn't about Jena builtins, so I'm still looking for advice on simulating (or implementing) Jena builtins that can make queries that in turn require inference.
---------- Forwarded message ---------- From: Adrian Walker <[email protected]> Date: Mon, Jul 8, 2013 at 1:44 PM Subject: Re: Ways to simulate recursive built-ins? To: [email protected] Joshua, Oops, I missed your questions. Our builtins are not *jena* builtins, sorry. For reference, here they are: some-a + some-b = some-c some-a - some-b = some-c some-a * some-b = some-c some-a / some-b = some-c some-a divided by some-b = some-c remainder some-d some-a raised to the power some-b = some-c some-a rounded to some-b place(s) after the decimal point is some-c some-a is equal some-b some-a is not equal some-b some-a is greater than some-b some-a is greater than or equal some-b some-a is less than some-b some-a is less than or equal some-b the log to base some-a of some-b = some-c the square root of some-a = some-b some-a consists of some-b symbols letters and digits some-a followed by some-b = some-c some-a followed by some-b separated by a symbol some-c = some-d some-string is one or more blanks the part of some-string of length some-length starting in position some-position = some-part in position some-number of some-phrase there is an item some-item some-a is a match to some-b some-a is similar to some-b some-a is a random number greater than or equal some-b and less than some-c the current user is some-a with userid some-b and with permission status some-c the present date is some-yr some-month some-day and the time is some-hr some-min some-sec So far, the system is not open source. Sorry again. Cheers, -- Adrian On Mon, Jul 8, 2013 at 1:06 PM, Joshua TAYLOR <[email protected]> wrote: > > Thanks! I'll take a look. Would you mind forwarding this to the list > too (so that the archives have it too) or if I forward it? //JT > > On Mon, Jul 8, 2013 at 1:02 PM, Adrian Walker <[email protected]> wrote: > > Hi Joshua, > > > > You may be interested in the following examples. > > > > 1. Recursive using builtins > > > > www.reengineeringllc.com/demo_agents/CriticalPath1.agent > > > > > > 2. RDF > > > > www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent > > > > Apologies if you have seen this before, and thanks for comments. > > > > -- Adrian > > > > Internet Business Logic > > Open Apps for Open Data > > A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A Apps over > > SQL and RDF > > Online at www.reengineeringllc.com > > Shared use is free, and there are no advertisements > > > > Adrian Walker > > Reengineering > > > > > > > > On Mon, Jul 8, 2013 at 11:14 AM, Joshua TAYLOR <[email protected]> > > wrote: > >> > >> 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/ > > > > > > > > -- > Joshua Taylor, http://www.cs.rpi.edu/~tayloj/ -- Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
