RE: More fulltext advocacy (was Re: Lee's feature proposal)

> From: Orri Erling
...
> We might go as far as to say that a pattern like:
> 
> ?xx sparql:fulltext ?text_exp ?score [option, ....].

There are two key features here:

+ full text is an index, not a restriction (unlike regexs).
+ scoring matters, as does limiting hits

It might be viable to have syntax and integration into evaluation without defining what full text results are.

Unfortunately, scoring is useful only if order is preserved.
 
The needing ?text_exp to be a ground term of bound variable at the point of evaluation is also a bit of a nuisance.

Thus, specific syntax for full text, and not making it look like a property, would be a step forward.

    TEXT(?x, 'word1 word2'[, relevance][, limit])

No specification of what the results are in this WG cycle.
 
This element would be part of a group so the evaluation model is join all the group elements together (caveat ordering in results).  Because of the need for the pattern to be grounded at the moment of evaluation, joins are not fully commutative here.  It's a tradeoff but then it's not joining to the same sort of index anyway.

A special case is use in a filter (that does just test for a pattern being higher than some threshold so it is a constraint and is more like a regex). The filter form is unnecessary unless non-conjunctive combinations of text checking and other filter expressions are really imporant.

 Andy

Received on Tuesday, 5 May 2009 09:19:08 UTC