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 <kide...@openlinksw.com <mailto:kide...@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 ontolo...@gmail.com <mailto:ontolo...@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
