java

Notes on Using Sesame for Faceted Search App

There's a few anomalies with the current setup.
First, Sesame's memory store is truly stored in memory, and I access via both a custom app, and the standard REST interface. This produces concurrency issues, since the Sesame application stored for the REST interface doesn't seem to sync as often. Also, the console fails to catch this unless the url at http://localhost:8080/openrdf-sesame has its web container restarted.

These are all stored in memorystore.data. I plan to ask if sync is set to 0, how long does it take?

Caucho Resin PHP bridge showing renewed promise for Speed Improvements

Looks like I'll be using a hybrid approach of the HTTP client, and a custom class running on JAVA to do the aggregation emulation.

Here's a recap of the consequences.
The first points of failure are (since the HTTP client for Sesame works great):

* SPARQL/Sesame not having Aggregate functions
* Sesame not having ORDER BY

This produces large amounts of results and/or queries, which then need to be parsed by JSON, leading to the second point of failure

* Zend JSON and native php 5.2 JSON are not fast enough (perhaps they should not be expected to be for 6000 results)

Yars and Sesame instead of ARC?

Sesame 2.0 is 2-10 times as fast for the queries I perform than ARC. However, Sesame 2.0 SPARQL doesn't have some features I need, like ORDER BY and full support for OPTIONAL. If these come through soon, I'm going to still need to build a bridge between Drupal/PHP and Sesame. I'll either need:

  • Resin, and run PHP inside Java for Sesame
  • PHP REST against YARS which uses N3 and no SPARQL
  • Redland, with maybe the new lib-b
  • PHP REST against Sesame, and just deal with current SPARQL limitations
Syndicate content