Hi Frank, a couple of comments in-line. Frank Budinsky wrote: > Paolo Castagna <[email protected]> wrote on 03/10/2012 03:34:48
[...] >> Another thing I often find myself thinking about is pros/cons, >> similarity/differences of "property functions" and filter functions. > > Me too. Correct me if I'm wrong, but it seems that filter functions are > fundamentally not workable for performance reasons. A filter function > provides a yes/no answer for each triple that may be a match. If you use a > filter function for free-text search, it would need to be called for every > triple in the triplestore (i.e., does triple #1 match the pattern?, does > #2?, does #3?, etc., etc.). With the property function approach, the > function is called once, and it (via Lucene or some other lookup) returns > all the matches. Yep: property functions generate bindings, while filter functions accept or reject bindings. However, it seems to me it would be possible to have a SPARQL query engine with an optimizer able to spot a particular filter function and decide to replace that with an operator which would create bindings efficiently using a custom index. I am not 100% sure about this, since I've never done it before. But if that is possible, there are very little differences between property functions and filter functions. > This is the reason I don't think that free-text can be accomplished using > an existing standard SPARQL mechanism, and therefore unless property > functions become an allowable extension, the current LARQ approach is > arguably non-compliant with the SPARQL spec. From Andy's reply, I gather > that he believes this is an arguable point. Did I get that right? > > Of course, as you (in your other reply) and Andy have pointed out, the > other important question is can the the text query syntax (currently based > on Lucene) be standardized so that the actual matching behavior would be > interoperable across implementations. I suppose an approach that required > all triplestore implementations to support custom property functions (or > similar) would, at least, allow users to plug in their own custom text > match property function into any triplestore of their choosing. That would be useful, but given the history, given the current situation, given the diversity and the existing implementation, I would not bet on that. For Apache Jena though, it would be really cool if we could allow people to drop-in a new .jar in their classpath and have their SPARQL endpoint extended with a new filter function and/or property function using a custom/external index. It is currently possible to add a new filter function and/or property function, the missing bit an even/notification mechanism to intercept all possible route of updates, so that a custom/external index can be updated as new data is added or removed. (How to do that without affecting performances (too much)? this is still, for me, an open question). Paolo > > Thanks, > Frank.
