Yes exactly, this is the latest Solr schema used by structWSF. The cost to change from Virtuoso to Sesame is to check is sesame can handle all the sparql queries generated by any structWSF endpoints. If it doesn’t for one, then a layer should be created to send different queries depending on the underlying store. Such a layer doesn’t currently exists, but should easily be implementable. Finally, one of the goal of structWSF was to create a WS abstraction so that we can use (and switch) any underlying system without impacting the capabilities of the network. It is the reason why we choose to use Solr for the search & browse activities, however if a triple store (or when) will be as effective as this for searching & faceting, then we will be able to switch from Solr to this new triple store (at the end, it would be much easier to maintain with a triple store than Solr because of some create/update limitations of Solr).

Hope it helps, and don’t hesitate to send me any question related to structWSF/Sesame (by email, on this blog, or on the mailing list).

Thanks!

Take care,

Fred

This is really interesting. Just to let you know that the link to the solR schema is broken, and I think it is replaced by this one :

http://code.google.com/p/structwsf/source/browse/trunk/framework/solr_schema_v1_1.xml

What does it cost to integrate structWSF with another triplestore/sparql endpoint than Virtuoso ? say, Sesame for example ?

All the best
Thomas

All full-text search capabilities of this method are supported by Solr itself. Chinese charsets are supported by Solr, the only thing we should check is if there is any Solr “Chinese” text-analyser out there. If there is, then we shouldn’t have any issues using this architecture to support Chinese languages.

Does that answer your question?

Thanks!

Take care,

Fred

What i am concerned about is, if this tech can provide the user-experience as same as that offered by traditional search engine(google or yahoo, for instance). And what about the full-text search on RDF about chinese or japanese characters?

Thanks,

Lau

Yes, you can get it from here:

http://code.google.com/p/structwsf/source/browse/trunk/framework/solr_schema.xml

This is the latest version available right now (and the trunk get always updated, so check that URL for the latest version).

Hope this help,

Thanks!

Fred

The link to the solr schema files seems to be broken. Is there somewhere we can download this?

Thanks,

John

First, I think you could be interested in this thread on the Semantic Web Drupal group page.

About structWSF’s Solr instance: what is happening with it? Well, it is really just a fulltext Solr index which leverage the structured content that it ingest. This means that you can filter by type (with inference), and by properties. However, you don’t have the flexibility that you have (at least, with the current Solr index used) to do this kind of search using Solr. This is really what SPARQL is about. If you want to perform this kind of searches on your system (lets say, some Drupal module you want to create that interact with a structWSF instance), then you would probably use the SPARQL endpoint to do such queries.

Otherwise, the current index schema doesn’t accommodate this kind of queries to Solr. Dynamics properties would be needed, and more complex Solr queries. The question would be: how Solr would behave with big datasets with non-heterogeneous dataset(s) (hundred of existing properties)?

The current goal by using Solr is to enable the fastest fulltext searches possible over a set of structured (rdf) datasets while leveraging some of its structure for leveraging inference and & faceting.

Hope it helps!

Thanks!

Take care,

Fred

I have one question: how do you go about, using your example data, filtering articles through more than one property of their authors, using only Solr. For example, search for all articles whose author name contains Bob and live in Canada (assuming authors have a country property).

Thanx,

Dado