Thanks Magnus! You've been heroic. We'll target getting a version up and
running in labs as soon as we can so people can poke holes in it.
Regarding Markus' points:
BigData == BlazeGraph
---
I agree this is confusing, sorry I didn't mention it. When we started
On Mar 5, 2015 8:50 PM, Nikolas Everett never...@wikimedia.org wrote:
TL/DR: We're selected BlazeGraph to back the next Wikidata Query Service.
After Titan evaporated about a month ago we went back to the drawing
board on back ends for a new Wikidata Query Service. We took four weeks
On Fri, Mar 6, 2015 at 11:28 AM, Dimitris Kontokostas jimk...@gmail.com
wrote:
On Mar 5, 2015 8:50 PM, Nikolas Everett never...@wikimedia.org wrote:
2. How should we represent the data in the database? BlazeGraph (and
only BlazeGraph) has an extension that *could* us called RDR. Should we
On 06.03.2015 15:05, Nikolas Everett wrote:
...
Regarding Markus' points:
...
The obvious question that comes from this point is why not use
Virtuoso? it is exposed publicly all over the place, you can talk to
the dbpedia folks, they do it and this is a very compelling argument
As long as
Hi,
Thanks for all the work. I think this is a sensible decision. What
confused me at first is that I did not know BlazeGraph (and when you
google for it, the first thing is an unrelated sourceforge project). An
important insight for me thus was that BlazeGraph is the project that
has up
Nik,
Will you be incorporating MapGraph, as well, with GPU hardware as part of
the scope of the Wikidata Query Service ? Or is that out of scope until
you know what the load limits will be and just use BlazeGraph as is with
CPU-bound memory ?
What are the scalability plans for also using
TL/DR: We're selected BlazeGraph to back the next Wikidata Query Service.
After Titan evaporated about a month ago we went back to the drawing board
on back ends for a new Wikidata Query Service. We took four weeks
(including a planed trip to Berlin) to settle on a backend. As you can see
from