Show HN: A database of everything (over 55M keys)
31–40 of 43 posts
Re: Show HN: A database of everything (over 55M keys)
#32If you search for the key "germany" it has no results, if you search "london" it finds no results.
The fluidity of the data is definitely a hindrance, if you wanted to use the dataset you'd have to already know what you are looking for to find the value.
Re: Show HN: A database of everything (over 55M keys)
#33Is 55 million keys a lot for tracking "everything"? My expectation was that "everything" would need more than 55 trillion keys.
"a journey of a thousand miles begins with a single step"
Re: Show HN: A database of everything (over 55M keys)
#34Re: Show HN: A database of everything (over 55M keys)
#35Re: Show HN: A database of everything (over 55M keys)
#36Earlier quoted context omitted.
This is exactly what I thought when I saw this project. Having worked with DBPedia data and the triples format ; I was just wondering how Outpan just stole the idea of Triples and packaged it as a new idea
And then, there's also ConceptNet ( http://conceptnet5.media.mit.edu/ )
Re: Show HN: A database of everything (over 55M keys)
#37What sort of backend storage does this use?
Re: Show HN: A database of everything (over 55M keys)
#38Shame it fails for the trap of natural language ambiguity. So on the front page I see "England -> capital -> London" and at a glance I thought the capital (as in money) flows from England and is accumulated in London.
Perhaps that reveals that a forward slash might be a better separator though - like a URI.
Re: Show HN: A database of everything (over 55M keys)
#39What sort of backend storage does this use?
Given that it's effectively key->key->value, I'm guessing Cassandra for the main backend. The data model fits very well, and it would give you the kind of scalability you would need for this sort of thing.
Re: Show HN: A database of everything (over 55M keys)
#40Earlier quoted context omitted.
Given that it's effectively key->key->value, I'm guessing Cassandra for the main backend. The data model fits very well, and it would give you the kind of scalability you would need for this sort of thing.
Given how ridiculously basic the website is, I think you're right. It should have been a real triplestore with a SPARQL endpoint though.