On 22/06/13 08:59, baran_H wrote:
...
but i have a LAST question here:
Promise?
Is PREFIX text: <http://jena.apache.org/text#> defined in SPARQL-spec
with the aim of identical query syntax for all SPARQL implementations
supporting text-indexing and if not, is a similar thing planned for
the future?
Property functions (sometimes called magic properties) are within SPARQL
syntax but there is no formal definition in the SPARQL specs. The style
is used by other systems, going back to cwm/N3.
PREFIX text: <http://jena.apache.org/text#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?s
{ ?s text:query (rdfs:label 'word' 10) ;
rdfs:label ?label
}
In fact, with possible a slight generous reading, there doesn't need to
be any spec text. You can imagine there really is a pattern in the data
that matches { ?s text:query 'word' } with the resource having a
property text:query and value all the strings it matches. Think of it
as a weird kind of entailment.
Extension within the syntax is more popular than extension that adds
non-standard syntax. If synatx were being added, then
?s TMATCH (rdfs:label, 'word', 10)
or (SPARQL likes simple - keyword first:)
TMATCH ?s WITH (rdfs:label, 'word', 10)
There are no plans that I know of to standardise this - it came up in
scoping SPARQL 1.1 at the use case and requirements stage. The big
problem is defining the text search language. A standard for SPARQL
text search needs a standard for the search string. But while many of
the candidates look the same, they differ in the details. This, coupled
with the fact that implementers do not want to implement text search
themselves but use an existing engine, does make standardizing it unlikely.
The first thing is to let SPARQL 1.1 get established. Any new round of
standardisation should wait to see what the real needs are - not what
the initial issues are.
Areas that could be interesting:
1/ Experimentation with graph operators beyond property paths
2/ Better/different syntax targeting the same algebra
Anyone interested should just dive in.
Andy
