one-to-very-many link associations

Eric Gaumer egaumer at
Thu Apr 22 21:43:58 EDT 2010

On Thu, Apr 22, 2010 at 4:47 PM, Orlin Bozhinov <om at> wrote:

>  Eric,
> Thanks for the 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

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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the riak-users mailing list