> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:public-sparql-dev-
> [EMAIL PROTECTED] On Behalf Of Richard Newman
> Sent: 16 August 2008 22:27
> To: Lee Feigenbaum
> Cc: [email protected]
> Subject: Re: 'standardizing' on one or more predicates for text search in
> SPARQL?
...
> I have some syntax ideas (and possibly even working code; this was
> some time ago) to solve this -- I don't think this is a natural fit
> for computed property syntax. Something along the lines of
>
> TEXTINDEX "foo" {
> ?x my:predicate ?o
> }
Hi Richard,
Good point - if we do want to respect the exact semantics of BGP and triple
patterns, I think there is some merit in considering a syntax for calling
custom code. The property function (computed predicate ....) form because
property functions do not necessarily behave exactly like normal BGP matching
(e.g. whether arguments are bound or unbound at the time of the call) and also
because of allowing expressions.
ARQ has an (currently undocumented) feature to make explicit calls on custom
code using PROC:
{
?s ?p ?o
PROC <uri>(str(?s), my:namespace(?p), ?o+16, ?z)
}
The procedure URI must be a URI, not a variable, allowing static analysis.
Arguments can be expressions - unbound variables must not be used in
expressions.
For example:
PROC dawg2:textMatch(?literal, '+word')
PROC dawg2:textMatch(?literal, ?pattern) # ?pattern already set
for free text matching. Now we can impose evaluation rules for procedures and
also allow per-procedure rules like the second argument must be a constant or a
bound variable (i.e bound in an earlier part of the current group, or treat as
if placed at he end of the current BGP like FILTERs).
Variables named in the arguments can be bound by the procedure if not already
bound - it's not a functional call so it's not like a custom function in FILTER
which is a pure function.
In ARQ, the property function mechanism and the procedure mechanism are two
manifestations of the same thing. Executing a property function is using the
execution mechanism of custom procedures - it's how the object gets built that
is different.
Andy
