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?
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)
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: