Thanks, that looks great!
On Tue, Mar 17, 2015 at 5:59 AM Stas Malyshev smalys...@wikimedia.org
wrote:
Hi!
I wrote a small translation tool from WDQ to SPARQL, which can be seen
here:
http://tools.wmflabs.org/wdq2sparql/
Currently it supports only one model of data and only subset of WDQ
Hi!
I wrote a small translation tool from WDQ to SPARQL, which can be seen here:
http://tools.wmflabs.org/wdq2sparql/
Currently it supports only one model of data and only subset of WDQ
syntax, but this can be extended. I wrote it just as PoC to see how hard
it would be (not too hard) and to see
Hi!
The choice for SPARQL was not made by me or by anyone who has a special
interest in pushing this particular formalism (in fact Nik and Stas can
confirm that I have been quite sceptical about the feasibility of using
BlazeGraph at first). It was the result of an open-minded discussion
We
Am 11.03.2015 um 10:43 schrieb Markus Krötzsch:
I was referring to the investigations that have led to this spreadsheet:
https://docs.google.com/a/wikimedia.org/spreadsheets/d/1MXikljoSUVP77w7JKf9EXN40OB-ZkMqT8Y5b2NYVKbU/edit#gid=0
That's the backend evaluation spreadsheet. I'm not arguing
On 11.03.2015 00:44, Magnus Manske wrote:
To be fair, the discussion is not what will we do till the end of
time, rather what do we start with.
Knowing neither SPARQL nor the data storage engine terribly well, it
would not be helpful if the service can be DOSed by innocent-looking
queries,
On 11.03.2015 05:59, Tom Morris wrote:
On Tue, Mar 10, 2015 at 6:17 PM, Markus Krötzsch
mar...@semantic-mediawiki.org mailto:mar...@semantic-mediawiki.org
wrote:
TL;DR: No concrete issues with SPARQL were mentioned so far; OTOH
many *simple* SPARQL queries are not possible in WDQ; there
Am 11.03.2015 um 10:08 schrieb Markus Krötzsch:
What I don't see is how the use of a WDQ API on top of SPARQL would make the
overall setup any less vulnerable; it mainly introduces an additional
component
on top of SPARQL, and we can have a simpler SPARQL-based filter component
there
if we
On Tue, Mar 10, 2015 at 6:17 PM, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
TL;DR: No concrete issues with SPARQL were mentioned so far; OTOH many
*simple* SPARQL queries are not possible in WDQ; there is still time to
restrict ourselves -- let's give SPARQL a chance before going
How long has WDQ been in service? What proportion of the total aggregate
lifetime Wikidata apps, presuming it survives, do the current, as of Mar
2015, Wikidata apps represent?
Should the question of premature optimization (or optimisation) be
considered?
Tom
p.s. Since your opinion doesn't
Some thoughts:
* Either way, there will be a WDQ-like wrapper around SPARQL, maybe as the
official interface, maybe only at the current WDQ URL (and I'll have to
read up on SPARQL to write that, so if someone else writes it for me, all
the better!)
* WDQ syntax is very limited (no references, no
Am 10.03.2015 um 18:22 schrieb Thomas Tanon:
I support Magnus point of view. WDQ is a very good proof of concept but is,
I think, to limited to be the primary language of the Wikidata query
system.
It can be extended. What I want is a limited domain specific language tailored
to our primary
Hi Daniel,
I can understand your thoughts to some extent, but they seem to apply to
any potential solution. Committing to a primary query interface will
always be, well, a committment. Because of this, I think the big
advantage of SPARQL is exactly that it is a technology standard that is
Hi all!
After the initial enthusiasm, I have grown increasingly wary of the prospect of
exposing a SPARQL endpoint as Wikidata's canonical query interface. I decided to
share my (personal and unfinished) thoughts about this on this list, as food for
thought and a basis for discussion.
Basically,
Am 10.03.2015 um 21:09 schrieb Stas Malyshev:
People would ask us for full SPARQL as soon as they'd know we're
running SPARQL db.
Sure. And I'D tell them you can use SPARQL on labs, but beware that it may
change or go away.
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Hi!
So, my proposal is to expose a WDQ-like service as our primary query
interface.
This follows the general principle having narrow interfaces to make it easy to
swap out the implementation.
WDQ query language is somewhat limited as I understand. We can of write
WDQ-SPARQL translator, I
TL;DR: No concrete issues with SPARQL were mentioned so far; OTOH many
*simple* SPARQL queries are not possible in WDQ; there is still time to
restrict ourselves -- let's give SPARQL a chance before going back.
Hi Daniel,
This discussion is way too abstract. I am missing hard facts about the
16 matches
Mail list logo
