Re: [tangle] getting the semweb exactly wrong

Kjetil Kjernsmo wrote:
> On Wednesday 04 January 2006 20:03, Tim Berners-Lee wrote:
> 
>>One answer is: don't!  The SemWeb is about conecting the data to what
>>  it means.
>>Keep the data in the place where it works and runs fast.
> 
> 
> Actually, I wouldn't dismiss it so fast. On the border between Perl-land 
> and Redland there has been much experimenting lately with using a 
> Redland model and toolchain as the model of a Model-View-Controller, 
> and from the reports I've heard this has been successful. 
> Unfortunately, many of the details are under NDA's so I haven't got 
> them, but I did some experiments with my own Redland-based SPARQL 
> engine, and the results where "OKish", some SPARQL queries against the 
> Redland model where not substantially slower than querying the RDBMS 
> for the same using the underlying engine. Others weren't as good, but I 
> didn't experiment enough to understand what the issues could be. 

Interesting.  Note that Redland's current SPARQL implementation makes no
use of underlying database technology as the query engine (in Rasqal) is
just operating over the triple view of the redland stores.  Rewriting
direct to SQL is on the list of things to do.  An alternative is to use
the 3store v3 backend to redland which has it's own SPARQL to SQL engine
and store.

> I think modelling the data as RDF and use a Redland model for the model 
> of the MVC is emerging as a very interesting architecture for web apps, 
> at least for smaller or medium sized applications with a few million 
> triples (which is the range I've worked in). This has the added benefit 
> that the whole app is trivially semweb, and therefore that the model 
> can be anywhere and anything, the model is the web. I have about two 
> lines of code of a album app I will build this way... :-) I'm sure the 
> Java world might feel the same about their tools. 

For what it's worth I haven't been concentrating on making the Redland
storage models scale beyond a few million triples.  Until recently.
3store v3 also should get you a lot further on appropriate hardware.

> However, it is clear that there exists relatively little experience 
> around this and that if one goes with it, itrequires a lot of 
> experimentation. I would therefore not argue that any approach is to be 
> preferred over the other, but I would certainly be interested in 
> hearing from people who try. I think the main performance challenge 
> will be to cache the results of common queries and connected to 
> validating the cache.

caching triple pattern matches, graph pattern matches.  Trying to get
away from the granularity of single triples into some larger lump of
work that can be more efficiently stored, transfered given overheads of
networking and de/serializing to syntaxes.

Dave

Received on Wednesday, 4 January 2006 21:31:55 UTC