ARQ does have a (incomplete) OpProcedure which has no syntax currently,
it did experimentally in the past ("PROC" IIRC). It did not declare the
return variables which I agree would be very helpful
PROC <uri>(expr1, expr2, ...) RETURNS (?var1, ?var2, ?var3)
PROC <uri>(expr1, expr2, ...) -> (?var1, ?var2, ?var3)
PROC <uri>(expr1, expr2, ...) (?var1, ?var2, ?var3)
the return can be multiple tuples for a single call of PROC.
The guarantee is that ?var1... are set for each row returned.
So IN parameters, OUT variables, results are a bag. No INOUT, no undefs
introduced.
<uri> is required to be a fixed URI, not an expression that evaluates to
a URI so the static optimizer can hook in code directly.
I doubt that OpProcedure handling in the optimizer is very smart and it
does not utilize defined variables but it shouldn't be broken.
Also - add to the rules on syntax checking single-assignment.
Blazegraph overload SERVICE and use the graph pattern to pass in/out the
parameters which is quite cute for expression very complex facilities.
Andy
rdfs:member is a property function in SPARQL.
On 26/04/17 10:04, Rob Vesse wrote:
This is essentially what already exists as property functions within ARQ and
various other vendors implementations.
What I was advocating for is explicit syntax that would identify such
functions as first-class citizens within the language rather than obscuring
them within the BGP syntax as is done today. Additionally it needs to
generalise to be able to consume the existing set of solutions upon which it
operates in order that intentions could efficiently processed the function in
the case where the existing solutions should be used to constrain the possible
outputs.
The additional complication is handling functions which introduce multiple
output variables, again this is typically handled in existing extensions by
passing in A Collection of variables as the subject. Again explicit syntax of
what new variables are introduced would be a big help to query engines.
Rob
On 26/04/2017 07:28, "Claude Warren" <[email protected]> wrote:
Greetings,
I was reading the "who made such idiocy" thread and began to think about
how one might introduce a "function" that could return more than one value
as was noted in the message stack.
I started thinking about how XSLT has extension elements and thought
perhaps a property type that rather than being a standard lookup performs a
function based on the object of the statement.
For example: assume ex:textLookup calls a text index lookup function and
returns the object of triples that have the values. Further assume
textLookup takes an argument list comprising the property to have the value
and a list of text items to look for. Then:
?x ex:textLookup (dc:comment, "now", "is", "the", "time" );
would return a list of objects that have dc:comment properties that contain
"now" or "is" or "the" or "time".
This would be a major change to how properties are handled as any property
that is a function would have to be identified and executed separately.
But I think as a construct it might work and it would be in concept similar
to the XSLT extension element.
Thoughts?
Claude
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
