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
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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.
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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@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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On Tue, Oct 27, 2015 at 10:24 PM, Markus Krötzsch < markus@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@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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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
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.
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/
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
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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@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@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@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
, 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@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
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.
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata