I had this exchange – figured I would put it in the blog.

— The note from Noah
I’m really interested in the Kowari stuff, but I’m just not sure about
expecting service/tool developers to push all their interesting data
atoms. I like the caching/speed options that offers, but that can’t be
the only way to get data. I guess there’s no reason at all that one of
these data queries couldn’t use whatever data was available in Kowari
and pull the other pieces needed. I just never want to tell someone
“you can’t get there from here”.
When I get some more of it built up, I’m sure there will be potent
examples (and pretty docs!) for the busiest among us to test drive
quickly and move on with life. Like you said, talented people are
crawling into the discussion, so this must not be too far off target.
I’ll keep you lightly posted on what’s happening.
—— My Response
Cool – I am looking to validate or reject a basic hypoethesis about Kowari.
Ian and others who I really respect tell me that Kowari is *different*. it scales unlike any prior object database or RDF store. It does this by *absolutely* not using any relational technology – it effectively used RAM and spinning disk with random I/O to do very fast has like stuff over large data sets. Also it spreads the data out over servers making best use of RAM and disk and CPU across the servers.
In a way, it is like Lucene – it takes a different approach and accomplishes something that RDB systems cannot no matter how much you tune them.
If on the other hand, Kowari is just another really rich API on top of a RDB – then I will be disappointed and relegate it to “something that sounded good but had no game in the final analysis. :)