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 > use it? > > I don't think RDR is compatible with the existing reification techniques > chosen, at least for the Wikidata toolkit RDF exports. > > Yup, mostly around values. We'd have to take that into account. Markus and I've talked there. Wikidata Toolkit is very complete. I want queries to be relatively simple to write but still have access to the same data that Wikidata Toolkit exports. We're experimenting with lots of things - changing the export, inference, and query rewrites. And we think that some combination of those will be required. Changing the export is both the hardest and easiest of the three to do. The BlazeGraph developers think of RDR as semi-independent things: 1. A storage layer optimization that can be performed against regular triples and SPARQL. 2. A syntax extension that looks like << :foo :bar :baz >> :quz :norf that explicitly invokes that optimization. The syntax is extension is one of our options for exposing qualifies and reference to the query language. Its just one of the options. Some days I wake up and think "We can just use RDR. The lock in isn't that bad because we could reimplement the syntax it elsewhere." Other days I don't. We're working to experiment with different RDF exports now and we'll get a better feeling about it soon. I can certainly expand on what I mean by "queries must be relatively simple to write" later. Nik
_______________________________________________ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
