Text search and named graphs

[Howard Burrows <ho...@gmail.com>]

Is the text search module named graph aware and capable of being configured (assembled) such that each named graph in a dataset can have its own text indexes configured separately with their own EntityMap definitions?

I have a TDB dataset composed of multiple named graphs (i.e. one per 'vendor') which I would like to index using the text search module and then search using named graph semantics.  Some of my SPARQL queries reference all graphs and some reference just a single graph so splitting the data into multiple datasets each with a separate Fuseki service endpoint wouldn't work well.

Any advice on how to assemble such a solution would be welcomed and appreciated.

Thanks,

Howard Burrows

Re: Text search and named graphs

[Andy Seaborne <an...@apache.org>]

On 07/08/13 15:48, Howard Burrows wrote:
> Is the text search module named graph aware and capable of being
> configured (assembled) such that each named graph in a dataset can
> have its own text indexes configured separately with their own
> EntityMap definitions?

The index is simply URI and text string, with no concept of which graph 
it comes from.

What you may wish to do is:

SELECT ?s
{ ?s text:query (rdfs:label 'word' 10) ;
      rdfs:label ?label
}

which looks the text query up and then checks to see if the URI returned 
actually does have a triple of that property.

So:

SELECT ?s
{
    GRAPH :graph {
      ?s text:query (rdfs:label 'word' 10) ;
         rdfs:label ?label .
    }
}


Not exactly the same but similar.

Otherwise, you'll need to create separate indexes and have separate 
property functions to access each one.

	Andy

>
> I have a TDB dataset composed of multiple named graphs (i.e. one per
> 'vendor') which I would like to index using the text search module
> and then search using named graph semantics.  Some of my SPARQL
> queries reference all graphs and some reference just a single graph
> so splitting the data into multiple datasets each with a separate
> Fuseki service endpoint wouldn't work well.
>
> Any advice on how to assemble such a solution would be welcomed and
> appreciated.
>
> Thanks,
>
> Howard Burrows
>