On Thu, Apr 22, 2010 at 4:47 PM, Orlin Bozhinov <o...@soundsapiens.com> wrote:
> Eric, > > Thanks for the bigdata.com link. It's something I had missed spotting. > > The Semantic Web doesn't fit it all either. I anticipate to much rather > search riak (with its upcoming query language) than rely entirely on > sparql. Though I've always had the option in mind. If you look at my > previous reply you'll see I'm considering it. I wonder what you think about > the combined idea... > > If riak won't also become a real graph backend, then I'll likely go with an > additional hosted database. It could be a relational db (the most readily > available kind), mongodb (i.e. mongohq), talis, etc. > > Given today's landscape, and lessons learned, anyone who isn't thinking in terms of diverse storage infrastructures isn't listening. There is no single magic solution and in fact, the NoSQL ideology frees us from that mentality (directed toward the relational database). So yes, a combination of diverse components sounds like a reasonable architecture. Is it the ideal architecture? That's something you'll have to work out given your technical requirements. In terms of storage adapters, you're misunderstanding things. What they're referring to is the ability to get RDF statements in/out of the these backends. This doesn't imply that they transform them into graph databases. The graph aspect would actually be something that RDF.rb would have to provide on top of the underlying storage mechanism (via a SPARQL query engine). Without such, you have no means of traversal. RDF.rb does not support RDFS, OWL, or SPARQL. It's essentially an RDF serializer that can retrieve/store RDF statements via storage adapters. Not to imply that's a bad thing, you're just not going to get graph like behavior from it. Regards, -Eric
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
