[Wikidata] [OM-2019] Final CFP: 14th workshop on Ontology Matching collocated with ISWC

2019-06-10 Thread Pavel Shvaiko
... Most often we need to integrate together data sources that were not aiming at their integration while being designed, thus, increasing the difficulty of the matching operation. Even if a good progress has been made in the matching field as such, ontology matching may appear to be virtually impo

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Sebastian Hellmann
Yes, I can ask. I am talking a lot with them as we are redeploying DBpedia live and also pushing the new DBpedia to them soon. I think, they also had a specific issue with how Wikidata does linked data, but I didn't get it, as it was mentioned too briefly. All the best, Sebastian On 10.06.

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Stas Malyshev
Hi! > thanks for the elaboration. I can understand the background much better. > I have to admit, that I am also not a real expert, but very close to the > real experts like Vidal and Rahm who are co-authors of the SWJ paper or > the OpenLink devs. If you know anybody at OpenLink that would be in

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Sebastian Hellmann
Hi Stas, thanks for the elaboration. I can understand the background much better. I have to admit, that I am also not a real expert, but very close to the real experts like Vidal and Rahm who are co-authors of the SWJ paper or the OpenLink devs. I am also spoiled, because OpenLink solves the

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Stas Malyshev
Hi! > Yes, sharding is what you need, I think, instead of replication. This is > the technique where data is repartitioned into more manageable chunks > across servers. Agreed, if we are to get any solution that is not constrained by hardware limits of a single server, we can not avoid looking at

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Stas Malyshev
Hi! > I am not sure how to evaluate this correctly. Scaling databases in > general is a "known hard problem" and graph databases a sub-field of it, > which are optimized for graph-like queries as opposed to column stores > or relational databases. If you say that "throwing hardware at the > proble

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Guillaume Lederrey
On Mon, Jun 10, 2019 at 9:03 PM Sebastian Hellmann wrote: > > Hi Guillaume, > > On 10.06.19 16:54, Guillaume Lederrey wrote: > > Hello! > > On Mon, Jun 10, 2019 at 4:28 PM Sebastian Hellmann > wrote: > > Hi Guillaume, > > On 06.06.19 21:32, Guillaume Lederrey wrote: > > Hello all! > > There has b

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Sebastian Hellmann
Hi Guillaume, On 10.06.19 16:54, Guillaume Lederrey wrote: Hello! On Mon, Jun 10, 2019 at 4:28 PM Sebastian Hellmann wrote: Hi Guillaume, On 06.06.19 21:32, Guillaume Lederrey wrote: Hello all! There has been a number of concerns raised about the performance and scaling of Wikdata Query Se

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Guillaume Lederrey
Hello! On Mon, Jun 10, 2019 at 4:28 PM Sebastian Hellmann wrote: > > Hi Guillaume, > > On 06.06.19 21:32, Guillaume Lederrey wrote: > > Hello all! > > There has been a number of concerns raised about the performance and > scaling of Wikdata Query Service. We share those concerns and we are > doin

Re: [Wikidata] Scaling Wikidata Query Service

2019-06-10 Thread Sebastian Hellmann
Hi Guillaume, On 06.06.19 21:32, Guillaume Lederrey wrote: Hello all! There has been a number of concerns raised about the performance and scaling of Wikdata Query Service. We share those concerns and we are doing our best to address them. Here is some info about what is going on: In an ideal