SPARQL text-indexing query-standard

[baran_H <ba...@gmail.com>]

Continuation from:

http://mail-archives.apache.org/mod_mbox/jena-users/201306.mbox/%3c51C57EC0.2030601@apache.org%3e

>> 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?
>>
>> thanks baran
>
> 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.
> ...

But this is a bit juggling with syntax issue, i mean certainly two SPARQL
implementations with same dataset, where i can compare the performance
with identical query-syntax addressing their 'in any way realized'
text-indexing.

> 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 whatthe  
> initial issues are.

I think standard of query-syntax for indexed texts is not a big problem.
It seems to me irrelavant how different SPARQL implementers realize
their text-searching internally, this doesn't need a standardization,
essential is, they make it possible to query it with the same syntax and
let the users easily compare their total performance.

Semantic Web as a whole is ailing at performance issues all the time,
there is so much work to do to get in it, but what you get back is poor
performance in form of results of any kind. And SPARQL spec + SPARQL
implementations are important bottlenecks in performance issues and
text-indexing is ONE of the heavy influencers of the overall
performance of a SPARQL implementation.
Therefore i cannot understand farfetched sounding arguments against
standardizing it at query-syntax-level as 'it is not a real need'.

Another aspect are so long expected huge crowds of the future-world
querying public SPARQL endpoints, do you want to tell each of them what
kind of SPARQL implementation each endpoint is to put a correct query?
If yes, there will never be huge-crowds querying public SPARQL enpoints.

Only if SPARQL prefers the closed world of a (we say) medicine company
as its real public, then i can understand a bit this kind of arguing.

> 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

I cannot dive in, Andy, i see 1/ definitly not as a priotity, but if
you mean it is a first class performance trigger, then i can really
understand you. In addition, my real profession is 'embedded systems'.
Many years i wrote by the way reports (with live online presentations)
about Semantic Web for the staff of a company, because it interested me
an they were also interested until they said: This will never deliver
something comparable to Google.
And now i am alone with my hobby and hope very much for continued
free support when i have time for it...

baran.
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/