Blazegraph - Wikidata - lists.wikimedia.org

List overview All Threads
Download

Blazegraph

Happy 3rd Birthday, Wikidata!

Three birthday gifts for...

Gerard Meijssen

25 Oct 2015 25 Oct '15

7:28 a.m.

Hoi, Arguments have been raised where Blazegraph was key to the problem. It is however a server based tool. Would someone please install it on labs and thereby making it available to all of us. In the process the argument becomes an argument that is of relevance to all of us. At this stage it is very much a niche issue. Thanks, GerardM

Attachments:

attachment.htm (text/html — 423 bytes)

Reply

Show replies by date

James Heald

25 Oct 25 Oct

2:51 p.m.

Hi Gerard. Blazegraph is the name of the open-source SPARQL engine being used to provide the Wikidata SPARQL service. So Blazegraph *is* available to all of us, at https://query.wikidata.org/ , via both the query editor, and the SPARQL API endpoint. It's convenient to talk describe some issues with the SPARQL service being "Blazegraph issues", if the issues appear to lie with the query engine. Other query engines that other people be running might be running might have other specific issues, eg "Virtuoso issues". But it is Blazegraph that the Discovery team and Wikidata have decided to go with. Hope that helps, All best, James. On 25/10/2015 07:28, Gerard Meijssen wrote:

Hoi, Arguments have been raised where Blazegraph was key to the problem. It is however a server based tool. Would someone please install it on labs and thereby making it available to all of us. In the process the argument becomes an argument that is of relevance to all of us. At this stage it is very much a niche issue. Thanks, GerardM _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Reply

Kingsley Idehen

26 Oct 26 Oct

3:31 p.m.

On 10/25/15 10:51 AM, James Heald wrote:

Hi Gerard. Blazegraph is the name of the open-source SPARQL engine being used to provide the Wikidata SPARQL service. So Blazegraph *is* available to all of us, at https://query.wikidata.org/ , via both the query editor, and the SPARQL API endpoint. It's convenient to talk describe some issues with the SPARQL service being "Blazegraph issues", if the issues appear to lie with the query engine. Other query engines that other people be running might be running might have other specific issues, eg "Virtuoso issues". But it is Blazegraph that the Discovery team and Wikidata have decided to go with.

The beauty of SPARQL is that you can use URLs to show query results (and even query definitions). Ultimately, engine aside, there is massive utility in openly sharing queries and then determining what might the real problem. Let's use open standards to work in as open a fashion as is possible. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Reply

Paul Houle

27 Oct 27 Oct

2:34 p.m.

One thing I really liked about Kasabi was that it had a simple interface for people to enter queries and share them with people. The "Information Workbench" from fluidOps does something similar although I never seen it open to the public. A database of queries also is a great tool for testing both the code and the documentation, both of the reference and cookbook kind. I see no reason why one instance of Blazegraph is having all the fun. With a good RDF dump, people should be loading Wikidata into all sorts of triple stores and since Wikidata is not that terribly big at this time, "alternative" endpoints ought to be cheap and easy to run On Mon, Oct 26, 2015 at 11:31 AM, Kingsley Idehen <kidehen(a)openlinksw.com> wrote:

On 10/25/15 10:51 AM, James Heald wrote: Hi Gerard. Blazegraph is the name of the open-source SPARQL engine being used to provide the Wikidata SPARQL service. So Blazegraph **is** available to all of us, at <https://query.wikidata.org/>https://query.wikidata.org/ , via both the query editor, and the SPARQL API endpoint. It's convenient to talk describe some issues with the SPARQL service being "Blazegraph issues", if the issues appear to lie with the query engine. Other query engines that other people be running might be running might have other specific issues, eg "Virtuoso issues". But it is Blazegraph that the Discovery team and Wikidata have decided to go with. The beauty of SPARQL is that you can use URLs to show query results (and even query definitions). Ultimately, engine aside, there is massive utility in openly sharing queries and then determining what might the real problem. Let's use open standards to work in as open a fashion as is possible. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

-- Paul Houle *Applying Schemas for Natural Language Processing, Distributed Systems, Classification and Text Mining and Data Lakes* (607) 539 6254 paul.houle on Skype ontology2(a)gmail.com :BaseKB -- Query Freebase Data With SPARQL http://basekb.com/gold/ Legal Entity Identifier Lookup https://legalentityidentifier.info/lei/lookup/ <http://legalentityidentifier.info/lei/lookup/> Join our Data Lakes group on LinkedIn https://www.linkedin.com/grp/home?gid=8267275

Reply

Markus Krötzsch

8:24 p.m.

On 27.10.2015 15:34, Paul Houle wrote:

One thing I really liked about Kasabi was that it had a simple interface for people to enter queries and share them with people. The "Information Workbench" from fluidOps does something similar although I never seen it open to the public. A database of queries also is a great tool for testing both the code and the documentation, both of the reference and cookbook kind.

Have you had a look at http://wikidata.metaphacts.com/? It has some interesting data presentation/visualisation features that are tied in with a SPARQL endpoint over Wikidata (not sure if it is the same one now).

I see no reason why one instance of Blazegraph is having all the fun. With a good RDF dump, people should be loading Wikidata into all sorts of triple stores and since Wikidata is not that terribly big at this time, "alternative" endpoints ought to be cheap and easy to run

Definitely. However, there is some infrastructural gap between loading a dump once in a while and providing a *live* query service. Unfortunately, there are no standard technologies that would routinely enable live updates of RDF stores, and Wikidata is rather low-tech when it comes to making its edits available to external tools. One could set up the code that is used to update query.wikidata.org (I am sure it's available somewhere), but it's still some extra work. Regards, Markus

On Mon, Oct 26, 2015 at 11:31 AM, Kingsley Idehen <kidehen(a)openlinksw.com <mailto:kidehen@openlinksw.com>> wrote: On 10/25/15 10:51 AM, James Heald wrote:

Hi Gerard. Blazegraph is the name of the open-source SPARQL engine being used to provide the Wikidata SPARQL service. So Blazegraph **is** available to all of us, at <https://query.wikidata.org/>https://query.wikidata.org/ , via both the query editor, and the SPARQL API endpoint. It's convenient to talk describe some issues with the SPARQL service being "Blazegraph issues", if the issues appear to lie with the query engine. Other query engines that other people be running might be running might have other specific issues, eg "Virtuoso issues". But it is Blazegraph that the Discovery team and Wikidata have decided to go with.

The beauty of SPARQL is that you can use URLs to show query results (and even query definitions). Ultimately, engine aside, there is massive utility in openly sharing queries and then determining what might the real problem. Let's use open standards to work in as open a fashion as is possible. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web:http://www.openlinksw.com Personal Weblog 1:http://kidehen.blogspot.com Personal Weblog 2:http://www.openlinksw.com/blog/~kidehen Twitter Profile:https://twitter.com/kidehen Google+ Profile:https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile:http://www.linkedin.com/in/kidehen Personal WebID:http://kingsley.idehen.net/dataspace/person/kidehen#this _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata -- Paul Houle *Applying Schemas for Natural Language Processing, Distributed Systems, Classification and Text Mining and Data Lakes* (607) 539 6254 paul.houle on Skype ontology2(a)gmail.com <mailto:ontology2@gmail.com> :BaseKB -- Query Freebase Data With SPARQL http://basekb.com/gold/ Legal Entity Identifier Lookup https://legalentityidentifier.info/lei/lookup/ <http://legalentityidentifier.info/lei/lookup/> Join our Data Lakes group on LinkedIn https://www.linkedin.com/grp/home?gid=8267275 _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Reply

Dimitris Kontokostas

28 Oct 28 Oct

9:11 a.m.

On Tue, Oct 27, 2015 at 10:24 PM, Markus Krötzsch < markus(a)semantic-mediawiki.org> wrote:

On 27.10.2015 15:34, Paul Houle wrote:

One thing I really liked about Kasabi was that it had a simple interface for people to enter queries and share them with people. The "Information Workbench" from fluidOps does something similar although I never seen it open to the public. A database of queries also is a great tool for testing both the code and the documentation, both of the reference and cookbook kind.

Have you had a look at http://wikidata.metaphacts.com/? It has some interesting data presentation/visualisation features that are tied in with a SPARQL endpoint over Wikidata (not sure if it is the same one now).

I see no reason why one instance of Blazegraph is having all the fun. With a good RDF dump, people should be loading Wikidata into all sorts of triple stores and since Wikidata is not that terribly big at this time, "alternative" endpoints ought to be cheap and easy to run

Definitely. However, there is some infrastructural gap between loading a dump once in a while and providing a *live* query service. Unfortunately, there are no standard technologies that would routinely enable live updates of RDF stores, and Wikidata is rather low-tech when it comes to making its edits available to external tools. One could set up the code that is used to update query.wikidata.org (I am sure it's available somewhere), but it's still some extra work.

DBpedia Live does that for some years now. The only thing that is non-standard in DBpedia Live are the changeset format but now this is covered by LDPAtch http://www.w3.org/TR/ldpatch/ At the moment DBpedia Live only produces the changeset that other servers can consume. The actual SPARQL Endpoint is located in an Openlink server and we already use the same model to feed & update an LDF Endpoint (Still in beta)

Regards, Markus

On Mon, Oct 26, 2015 at 11:31 AM, Kingsley Idehen <kidehen(a)openlinksw.com <mailto:kidehen@openlinksw.com>> wrote: On 10/25/15 10:51 AM, James Heald wrote:

Hi Gerard. Blazegraph is the name of the open-source SPARQL engine being used to provide the Wikidata SPARQL service. So Blazegraph **is** available to all of us, at <https://query.wikidata.org/>https://query.wikidata.org/ , via both the query editor, and the SPARQL API endpoint. It's convenient to talk describe some issues with the SPARQL service being "Blazegraph issues", if the issues appear to lie with the query engine. Other query engines that other people be running might be running might have other specific issues, eg "Virtuoso issues". But it is Blazegraph that the Discovery team and Wikidata have decided to go with.

The beauty of SPARQL is that you can use URLs to show query results (and even query definitions). Ultimately, engine aside, there is massive utility in openly sharing queries and then determining what might the real problem. Let's use open standards to work in as open a fashion as is possible. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web:http://www.openlinksw.com Personal Weblog 1:http://kidehen.blogspot.com Personal Weblog 2:http://www.openlinksw.com/blog/~kidehen Twitter Profile:https://twitter.com/kidehen Google+ Profile:https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile:http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata -- Paul Houle *Applying Schemas for Natural Language Processing, Distributed Systems, Classification and Text Mining and Data Lakes* (607) 539 6254 paul.houle on Skype ontology2(a)gmail.com <mailto:ontology2@gmail.com> :BaseKB -- Query Freebase Data With SPARQL http://basekb.com/gold/ Legal Entity Identifier Lookup https://legalentityidentifier.info/lei/lookup/ <http://legalentityidentifier.info/lei/lookup/> Join our Data Lakes group on LinkedIn https://www.linkedin.com/grp/home?gid=8267275 _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

_______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

-- Kontokostas Dimitris

Reply

Markus Krötzsch

10:25 a.m.

On 28.10.2015 10:11, Dimitris Kontokostas wrote: ...

Definitely. However, there is some infrastructural gap between loading a dump once in a while and providing a *live* query service. Unfortunately, there are no standard technologies that would routinely enable live updates of RDF stores, and Wikidata is rather low-tech when it comes to making its edits available to external tools. One could set up the code that is used to update query.wikidata.org <http://query.wikidata.org> (I am sure it's available somewhere), but it's still some extra work. DBpedia Live does that for some years now. The only thing that is non-standard in DBpedia Live are the changeset format but now this is covered by LDPAtch http://www.w3.org/TR/ldpatch/ At the moment DBpedia Live only produces the changeset that other servers can consume. The actual SPARQL Endpoint is located in an Openlink server and we already use the same model to feed & update an LDF Endpoint (Still in beta)

If there *were* an ldpatch service for Wikidata, then you *could* do this for Wikidata as well, using standard tools (on the W3C "WG Note" level) from this point on. However, there is no such service now, and I am not aware of any activity that is aimed at building such a service. It's not rocket science to set this up, but it requires non-standard techniques and custom tools (starting with parsing edit histories of Wikidata). Markus

Reply

Kingsley Idehen

11:27 a.m.

On 10/28/15 6:25 AM, Markus Krötzsch wrote:

On 28.10.2015 10:11, Dimitris Kontokostas wrote: ...

Definitely. However, there is some infrastructural gap between loading a dump once in a while and providing a *live* query service. Unfortunately, there are no standard technologies that would routinely enable live updates of RDF stores, and Wikidata is rather low-tech when it comes to making its edits available to external tools. One could set up the code that is used to update query.wikidata.org <http://query.wikidata.org> (I am sure it's available somewhere), but it's still some extra work. DBpedia Live does that for some years now. The only thing that is non-standard in DBpedia Live are the changeset format but now this is covered by LDPAtch http://www.w3.org/TR/ldpatch/ At the moment DBpedia Live only produces the changeset that other servers can consume. The actual SPARQL Endpoint is located in an Openlink server and we already use the same model to feed & update an LDF Endpoint (Still in beta)

If there *were* an ldpatch service for Wikidata, then you *could* do this for Wikidata as well, using standard tools (on the W3C "WG Note" level) from this point on. However, there is no such service now, and I am not aware of any activity that is aimed at building such a service. It's not rocket science to set this up, but it requires non-standard techniques and custom tools (starting with parsing edit histories of Wikidata). Markus

Markus, You can use existing standards to achieve these goals, as is already demonstrated. Fundamentally, you can use RDF Language to describe anything for machine processing, and of course that includes feeds, and the nature of said feeds (formats, deltas, refresh schedules etc..). Standards and technology aren't the problem here, so let's not frame matters that way, for broad clarity. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Reply

Kingsley Idehen

11:24 a.m.

On 10/27/15 4:24 PM, Markus Krötzsch wrote:

Definitely. However, there is some infrastructural gap between loading a dump once in a while and providing a *live* query service. Unfortunately, there are no standard technologies that would routinely enable live updates of RDF stores, and Wikidata is rather low-tech when it comes to making its edits available to external tools. One could set up the code that is used to update query.wikidata.org (I am sure it's available somewhere), but it's still some extra work. Regards, Markus

Markus, Are you aware DBpedia-Live? It is based on existing open standards. Links: [1] http://live.dbpedia.org [2] http://dbpedia-live.openlinksw.com/live/ -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Reply

Markus Krötzsch

1:17 p.m.

On 28.10.2015 12:24, Kingsley Idehen wrote:

On 10/27/15 4:24 PM, Markus Krötzsch wrote:

Definitely. However, there is some infrastructural gap between loading a dump once in a while and providing a *live* query service. Unfortunately, there are no standard technologies that would routinely enable live updates of RDF stores, and Wikidata is rather low-tech when it comes to making its edits available to external tools. One could set up the code that is used to update query.wikidata.org (I am sure it's available somewhere), but it's still some extra work. Regards, Markus

Markus, Are you aware DBpedia-Live? It is based on existing open standards.

Yes, but we are talking about Wikidata here. The question discussed in this thread is how much work it would be for others to build a third-party *Wikidata* live endpoint. I think we agree on the fact that it would be nice if standards-based support would be available here -- but it isn't at the moment. Markus

Reply

Gerard Meijssen

29 Oct 29 Oct

10:08 a.m.

Hoi, Sorry for not replying earlier.. I am busy in real life. It is good to be wrong, particularly about something like this. It is much better to have this engine available to people. What I find relevant is that additional tools are needed to make it shareable. This combined with the learning curve involved, I do not have much time available to me lately, prevent me from exploring it. I do not really feel the need as WDQ fulfills my needs perfectly. It is because it integrates with the tools that I use. For me SPARQL may be awesome but as long as it does not integrate with tools and is all over the place, it remains a niche; it is there for some but not others. Once it does integrate and is mostly hidden from view, its power becomes relevant. This has been as true for WDQ; most people use its engine in tools but do not make queries themselves. Thanks, GerardM On 26 October 2015 at 16:31, Kingsley Idehen <kidehen(a)openlinksw.com> wrote:

On 10/25/15 10:51 AM, James Heald wrote: Hi Gerard. Blazegraph is the name of the open-source SPARQL engine being used to provide the Wikidata SPARQL service. So Blazegraph **is** available to all of us, at <https://query.wikidata.org/>https://query.wikidata.org/ , via both the query editor, and the SPARQL API endpoint. It's convenient to talk describe some issues with the SPARQL service being "Blazegraph issues", if the issues appear to lie with the query engine. Other query engines that other people be running might be running might have other specific issues, eg "Virtuoso issues". But it is Blazegraph that the Discovery team and Wikidata have decided to go with. The beauty of SPARQL is that you can use URLs to show query results (and even query definitions). Ultimately, engine aside, there is massive utility in openly sharing queries and then determining what might the real problem. Let's use open standards to work in as open a fashion as is possible. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Reply

Martynas Jusevičius

10:14 a.m.

Maybe you should put it the other way: as long as Wikidata's tools do not integrate with SPARQL? Because SPARQL is well-supported outside Wikidata, much more so than Wikidata's tools. So I think you focus on the wrong "niche". On Thu, Oct 29, 2015 at 11:08 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote:

Hoi, Sorry for not replying earlier.. I am busy in real life. It is good to be wrong, particularly about something like this. It is much better to have this engine available to people. What I find relevant is that additional tools are needed to make it shareable. This combined with the learning curve involved, I do not have much time available to me lately, prevent me from exploring it. I do not really feel the need as WDQ fulfills my needs perfectly. It is because it integrates with the tools that I use. For me SPARQL may be awesome but as long as it does not integrate with tools and is all over the place, it remains a niche; it is there for some but not others. Once it does integrate and is mostly hidden from view, its power becomes relevant. This has been as true for WDQ; most people use its engine in tools but do not make queries themselves. Thanks, GerardM On 26 October 2015 at 16:31, Kingsley Idehen <kidehen(a)openlinksw.com> wrote:

On 10/25/15 10:51 AM, James Heald wrote: Hi Gerard. Blazegraph is the name of the open-source SPARQL engine being used to provide the Wikidata SPARQL service. So Blazegraph *is* available to all of us, at https://query.wikidata.org/ , via both the query editor, and the SPARQL API endpoint. It's convenient to talk describe some issues with the SPARQL service being "Blazegraph issues", if the issues appear to lie with the query engine. Other query engines that other people be running might be running might have other specific issues, eg "Virtuoso issues". But it is Blazegraph that the Discovery team and Wikidata have decided to go with. The beauty of SPARQL is that you can use URLs to show query results (and even query definitions). Ultimately, engine aside, there is massive utility in openly sharing queries and then determining what might the real problem. Let's use open standards to work in as open a fashion as is possible. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

_______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Reply

Gerard Meijssen

10:20 a.m.

Hoi. I have been involved with Wikidata for a long time. I know about SPARQL, when I learned about it, it had major limitations and it was highly split up in flavours. We are talking Wikidata here and when tools are not available to Wikidata people, they are hardly relevant in the Wikidata context. When you look at Wikidata, Wikidata is increasingly relevant because of its scope and its link to people who actually care about the data and are willing to work on items one at a time. I will accept your point if you are willing and able to bring those tools in the Wikidata world. Give them relevance and by inference they become relevant. As long as they are outside looking in, they do not really matter except for the people lucky enough to have them. Thanks, GerardM On 29 October 2015 at 11:14, Martynas Jusevičius <martynas(a)graphity.org> wrote:

Maybe you should put it the other way: as long as Wikidata's tools do not integrate with SPARQL? Because SPARQL is well-supported outside Wikidata, much more so than Wikidata's tools. So I think you focus on the wrong "niche". On Thu, Oct 29, 2015 at 11:08 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote:

Hoi, Sorry for not replying earlier.. I am busy in real life. It is good to be wrong, particularly about something like this. It is

much

better to have this engine available to people. What I find relevant is

that

additional tools are needed to make it shareable. This combined with the learning curve involved, I do not have much time available to me lately, prevent me from exploring it. I do not really feel the need as WDQ fulfills my needs perfectly. It is because it integrates with the tools that I use. For me SPARQL may be awesome but as long as it does not integrate with

tools

and is all over the place, it remains a niche; it is there for some but

not

others. Once it does integrate and is mostly hidden from view, its power becomes relevant. This has been as true for WDQ; most people use its

engine

in tools but do not make queries themselves. Thanks, GerardM On 26 October 2015 at 16:31, Kingsley Idehen <kidehen(a)openlinksw.com>

wrote:

> > On 10/25/15 10:51 AM, James Heald wrote: > > Hi Gerard. Blazegraph is the name of the open-source SPARQL engine

being

> used to provide the Wikidata SPARQL service. > > So Blazegraph *is* available to all of us, at

https://query.wikidata.org/

> , via both the query editor, and the SPARQL API endpoint. > > It's convenient to talk describe some issues with the SPARQL service

being

> "Blazegraph issues", if the issues appear to lie with the query engine. > > Other query engines that other people be running might be running might > have other specific issues, eg "Virtuoso issues". But it is Blazegraph

that

> the Discovery team and Wikidata have decided to go with. > > > The beauty of SPARQL is that you can use URLs to show query results (and > even query definitions). Ultimately, engine aside, there is massive

utility

> in openly sharing queries and then determining what might the real

problem.

> > Let's use open standards to work in as open a fashion as is possible. > > -- > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog 1: http://kidehen.blogspot.com > Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen > Twitter Profile: https://twitter.com/kidehen > Google+ Profile: https://plus.google.com/+KingsleyIdehen/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > Personal WebID:

http://kingsley.idehen.net/dataspace/person/kidehen#this

_______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

_______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

_______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Reply

Kingsley Idehen

30 Oct 30 Oct

12:30 p.m.

On 10/29/15 6:08 AM, Gerard Meijssen wrote:

For me SPARQL may be awesome but as long as it does not integrate with tools and is all over the place, it remains a niche; it is there for some but not others. Once it does integrate and is mostly hidden from view, its power becomes relevant. This has been as true for WDQ; most people use its engine in tools but do not make queries themselves. Thanks, GerardM

Gerard, SPARQL is an Open Standard for querying relations. Application & Services may or may not be SPARQL-compliant, not the other way around. Would you say "SQL doesn't integrate with anything" for instance? SPARQL and SQL are query languages that target different representations of relations. Both are Open Standards. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Reply

Gerard Meijssen

2:26 p.m.

Hoi, I would say something different. Typically SQL is something I would not touch with a barge pole. At the same time it is used in so many tools that make use of SQL behind the scenes. I do not care really what flavour of SQL is in use, the proof of the pudding is in the eating. The same holds for SPARQL. I do not care to learn another language. For SPARQL to be relevant it needs to be embedded in tools that provide a function. To be brutally honest WDQ is useful BECAUSE it is used in tools. On its own it is interesting but hardly of interest. I do understand the need for open standards but it is like so many other standards, it is in the implementation that it has its merit. They are the tools, that is what I am looking for. Thanks, Gerard On 30 October 2015 at 13:30, Kingsley Idehen <kidehen(a)openlinksw.com> wrote:

On 10/29/15 6:08 AM, Gerard Meijssen wrote:

For me SPARQL may be awesome but as long as it does not integrate with tools and is all over the place, it remains a niche; it is there for some but not others. Once it does integrate and is mostly hidden from view, its power becomes relevant. This has been as true for WDQ; most people use its engine in tools but do not make queries themselves. Thanks, GerardM

Gerard, SPARQL is an Open Standard for querying relations. Application & Services may or may not be SPARQL-compliant, not the other way around. Would you say "SQL doesn't integrate with anything" for instance? SPARQL and SQL are query languages that target different representations of relations. Both are Open Standards. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Reply

3102

days inactive

3107

days old

wikidata@lists.wikimedia.org

Manage subscription

14 comments

7 participants

tags (0)

participants (7)

Dimitris Kontokostas
Gerard Meijssen
James Heald
Kingsley Idehen
Markus Krötzsch
Martynas Jusevičius
Paul Houle