Hi Amirouche, The version history and time-travel features sound a lot like the "integrated versioning system" of Freebase, circa 2009 when they (Metaweb) presented at WWW. As Freebase's data was transferred to Wikidata, this sounds a little circular; I wonder what advantages datae would offer vis-a-vis Freebase. Disclaimer: this is coming from a Wikidata lurker who just happens to like the Freebase approach to versioning of knowledge graphs, similar to what you have described.
Josh On Sat, May 4, 2019 at 5:49 AM Amirouche Boubekki < amirouche.boube...@gmail.com> wrote: > Le sam. 4 mai 2019 à 04:00, Yuri Astrakhan <yuriastrak...@gmail.com> a > écrit : > >> Sounds interesting, is there a github repo? >> > > Thanks for your interest. This is still a work-in-progress. I made a > prototype that demos > that the history significance measure allows to do time travelling queries > in the v0 branch. > Right now, I am working on getting it all together. > > > https://github.com/awesome-data-distribution/datae/tree/master/docs/SCHEME20XY#abstract > > On Fri, May 3, 2019 at 8:19 PM Amirouche Boubekki < >> amirouche.boube...@gmail.com> wrote: >> >>> GerardM post triggered my interest to post to the mailing list. As you >>> might know I am working on functional quadstore that is quadstore that >>> keeps around old version of data, like a wiki but in direct-acyclic-graph. >>> It only stores differences between commits. It rely on snapshot of the >>> latest version for fast reads. My ultimate goal is to build somekind of >>> portable knowlege base. That is something like WikiBase + blazegraph but >>> that you spinup on regular machine with the press of button. >>> >>> Enought brag about me. I wont't reply to all the message of the threads >>> one by one but: >>> >>> Here is what SHOULD BE possible: >>> >>> - incremental dumps >>> - time traveling queries >>> - full dumps >>> - The federation of wikibase SHOULD BE possible since it stored in a >>> history like GIT and git pull git push are planned in the ROADMAP >>> >>> And online edition of the quadstore. >>> >>> Access Control List are not designed yet, I except that this should be >>> enforced by the application layer. >>> >>> I planned start working on Data Management System (something like CKAN) >>> with search featrure. But I would gadly work with wikimedia instead. >>> >>> Also, given it modeled after git, one can do merge-request like >>> features, ie. exit the massive import that is crippled. >>> >>> What I would need is logs possibly with timing of queries (read and >>> write) to do benchmarks. >>> >> > Request: > > - Is it possible to have logs of read queries done against blazegraph > with timings? > - Is it possible to have logs of write queries done against mysql with > timings? > > In the best of the worlds, it would be best to have logs to replicate the > workload of the producion databases. > > >> Maybe I should ask for fund at mediawiki? >>> >> > What about this? Any possibility to have my project funded by the > foundation somehow? > > >> >>> FWIW, I got 2 times faster than blazegraph on microbenchmark. >>> >>> >>>> Hoi, >>>> Wikidata grows like mad. This is something we all experience in the >>>> really bad response times we are suffering. It is so bad that people are >>>> asked what kind of updates they are running because it makes a difference >>>> in the lag times there are. >>>> >>>> Given that Wikidata is growing like a weed, it follows that there are >>>> two issues. Technical - what is the maximum that the current approach >>>> supports - how long will this last us. Fundamental - what funding is >>>> available to sustain Wikidata. >>>> >>>> For the financial guys, growth like Wikidata is experiencing is not >>>> something you can reliably forecast. As an organisation we have more money >>>> than we need to spend, so there is no credible reason to be stingy. >>>> >>>> For the technical guys, consider our growth and plan for at least one >>>> year. When the impression exists that the current architecture will not >>>> scale beyond two years, start a project to future proof Wikidata. >>>> >>>> It will grow and the situation will get worse before it gets better. >>>> Thanks, >>>> GerardM >>>> >>>> PS I know about phabricator tickets, they do not give the answers to >>>> the questions we need to address. >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Wikidata mailing list >>> Wikidata@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>> >> _______________________________________________ >> Wikidata mailing list >> Wikidata@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> > _______________________________________________ > Wikidata mailing list > Wikidata@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata >
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
