New release of the Stardog WebFunction plugin v1.0.1
https://github.com/semantalytics/stardog-webfunctions/releases/tag/v1.0.1
This new release adds support for aggregate functions.
prefix f: <ipns://wf.semantalytics.com/stardog/aggregate/>
prefix wf: <http://semantalytics.com/2021/03/ns/stardog/webfunction/>
select (wf:agg(f:sum, ?a) AS ?result) WHERE { VALUES ?a { 1 2 3 1 }}
returns
+--------+
| result |
+--------+
| "7" |
+--------+
There is only the one demo function available right now but the next thing to do is to start filling out the available functions which should start to become available at http://wf.semantalytics.com under the Stardog link there will be a directory listing with the available functions. I'll make a follow on post about the many different ways to reference your WebFunctions.
In addition it also supports specifying WebFunctions as a literal but to understand this a some background is necessary. In order to make WebFunctions as reliable as possible there needed to be a way to update the WebFunction API without effecting any current WebFunctions being used. To do that the plugin embeds a pluginVersion that can be accessed with the wf:pluginVersion function. This version gets appended to the function URL to retrieve the WebAssembly to run. So a function URL of http://www.acme.com/myFunction would actually dereference http://www.acme.com/myFunction/1 for a plugin version 1 and an upgraded plugin with verison 2 would dereference http://www.acme.com/myFunction/2 . I still wanted a way to specify the exact URL to dereference so that if you weren't able to place the WebAssembly in the correct location with the correct name you could still execute it if you knew the address.
To do that you can now literaly use a literal to give the exact address. Using wf:call("http://www.acme.com/myFunction.wasm") would execute that exact file while wf:call(<http://www.acme.com/myFunction>) would access the plugin specific version at http://www.acme.com/myFunciton/1. I am considering also supporting running WebAssembly directly from a literal, either HexBinary, or there is a native text encoding for WebAssembly called wat. WebAssembly can be very small and easily fit within the 4mb literal limit. This would allow you to store the code for running functions in the database itself.
One last thing that you can do wtih WebFunctions that you can't do with regular functions is make them dependent on your query and call different functions for each binding. The function called doesn't need to be constant and can be executed from a binding ie. select (wf:call(?func) as ?funResult where { values ?func {"func1" "func2" "func3" }}. I have no idea how or when this might be useful but you never know. Let me know if you can think of a good use for it.