Re: one-to-very-many link associations

Eric Gaumer wrote: On Thu, Apr 22, 2010 at 4:47 PM, Orlin Bozhinov > 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 r

Re: one-to-very-many link associations

On Thu, Apr 22, 2010 at 4:47 PM, Orlin Bozhinov 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.

Re: one-to-very-many link associations

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.

Re: one-to-very-many link associations

Sean, Sure, mapping is another way, but even with very few object-encapsulated links it's slower than header link walking, correct? I just wanted to treat them all the same. More importantly, get decent response times, appropriate for an interactive ui. Perhaps with stored map functions an

Re: one-to-very-many link associations

On Thu, Apr 22, 2010 at 9:01 AM, Sean Cribbs wrote: > > One of the "other options" that I didn't mention was a graph database. If > your model seems to beg lots and lots of links, you might be better off > looking at something that fits the traversal model better, like Neo4J, > AllegroGraph, etc

Re: one-to-very-many link associations

Don't fall into the trap of "one size fits all". Riak is an amazing product that can solve a number of tough problems. I don't think this is one of them. You need/want a triple store to (correctly) model this sort of problem. You need flexible schemas, ontologies, and a graph based query language.

Re: one-to-very-many link associations

Orlin, One thing that you imply is that you would always be using the Link header to represent links. Another way to cope with large numbers of links is to encapsulate them in the object itself, rather than in the headers. This removes the header-length/count limitation, but would require you