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

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)



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

    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.


    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>

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

:BaseKB -- Query Freebase Data With SPARQL

Legal Entity Identifier Lookup

Join our Data Lakes group on LinkedIn

Wikidata mailing list

Wikidata mailing list

Kontokostas Dimitris