Blogs

Will the real speed issue (with the rdf store) please stand up? (WE NEED AGGREGATE FUNCTIONS!)

212 queries to load the front page of AHIRC. That'll do it.
This happens because I am trying to emulate the "COUNT" mixed with "GROUP BY" you'd find in SQL. One company has it:
http://docs.openlinksw.com/virtuoso/rdfsparqlaggregate.html
And looks like others are anxious:
http://simile.mit.edu/mail/ReadMsg?listId=14&msgId=16326
But it's not an easy problem in a broader context:
http://www.ldodds.com/wordtin/Wiki.jsp?page=UniqueNamesAssumption

Using Sesame opens up new possibilities for Semantic Search

Development is coming along, and there are a number of possibilities that Sesame opens up.

When you can run complex queries on Drupal data, maybe that will convince some skeptics of the value. Take for example:
http://www.openrdf.org/contrib.jsp
like
http://www.ontotext.com/bor/ (rules engine) and http://www.ontotext.com/owlim/ (OWL store and engine)

Presenation of SemanticSearch for DrupalCon 2007

I've proposed to present the module at DrupalCon 2007 in Barcelona. I've got quite a bit of work to do before the official "dev" release (beta) - but solving the speed issues will help tremendously.

see http://barcelona2007.drupalcon.org/node/633

PHP HTTP client for Sesame completed

The holdup was a 20 second delay per request from the a bug in the Zend Framework (not officially described as a bug yet).
Everything seems to be fast now!

I still need to connect the adapter which will send the Drupal data to Sesame.

I've created a patch to the Zend Framework here (one line).
The patch is here http://semanticsearch.org/patch-zend-framework-socket-php-http-client
I documented the process here
http://www.openrdf.org/forum/mvnforum/viewthread?thread=1417

HTTP client for Sesame nearing completion

The client is nearing completion. I'm working on create, update, and Delete. I'll post a version of the file on this site when done
Thanks for the help from Sesame's project leader in the following forum thread.

http://www.openrdf.org/forum/mvnforum/viewthread?thread=1417

Zend Platform HTTP client and Sesame

I've successfully built an HTTP client using the Zend Platform against Sesame 2.0. Phesame was a very similar project which used PEAR and was only compatible with Sesame 1.x.

Sesame returns JSON it appears, and the Zend platform has a nice decode which works well for that. Still todo is complete SPARQL HTTP POST, and see if the SeRQL has the ORDER BY I need that Sesame doesn't support in SPARQL.

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

Worked on AHIRC

AHIRC gained a couple of features today via Semantic Search.
Taxonomy weights now sort the display of subcategories, and a hack was completed to do double ORDER BY (see previous post).
Doesn't sound like much, but as they say here in Spain - poco a poco.

using the rdf store to retrieve objects - slow or incomplete

RDF stores are not simply returning table rows, the return parts of triplets:
SELECT DISTINCT ?s WHERE{?s ?p ?o. }

You can structure the query to return full "data objects" of sorts:
SELECT DISTINCT ?objectid ?param ?literal WHERE{?objectid rdf:type <[http://example.com/Class#y]>. ?objectid ?param ?literal. }

Then you can ORDER by a specific field:

Today's Technical issues.

With a bit more work to get done with AHIRC (work I'm doing with CivicActions and LINC) - I'll need to make Semantic Search fast enough for importing more than 2000 nodes. AHIRC has around 6000 nodes and can take 10-12 seconds for longer searches. Why?

  • MySQL 4 had a bug* with the statistics phase of optimizing SQL when you had many inner joins on one large table (this actually caused queries to hang)
Syndicate content