W3C home > Mailing lists > Public > public-sparql-dev@w3.org > July to September 2008

RE: 'standardizing' on one or more predicates for text search in SPARQL?

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sun, 17 Aug 2008 17:32:52 +0000
To: Richard Newman <rnewman@franz.com>
CC: "public-sparql-dev@w3.org" <public-sparql-dev@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA34B056C494A@GVW1118EXC.americas.hpqcorp.net>
> -----Original Message-----
> From: public-sparql-dev-request@w3.org [mailto:public-sparql-dev-
> request@w3.org] On Behalf Of Richard Newman
> Sent: 16 August 2008 22:27
> To: Lee Feigenbaum
> Cc: public-sparql-dev@w3.org
> 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

Received on Sunday, 17 August 2008 17:35:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 August 2008 17:35:35 GMT