Return to Answer

As Magnus Manske points out, SPARQL is the preferred way since, I would add, SPARQL is standardized BUT, here is the downside:

The SPARQL endpoint, at this point in time, is NOT as stable as WDQ yet, for example a query like this:

https://wdq.wmflabs.org/api?q=tree[729][150][171,273,75,76,77,70,71,74,89]

Which returns all animals in wikidata, takes 15 seconds to complete as WDQ query, and the equivalent (via https:// tools.wmflabs.org/wdq2sparql/w2s.php) in SPARQL:

prefix wdt: <http://www.wikidata.org/prop/direct/>
prefix wd: <http://www.wikidata.org/entity/>
SELECT ?item WHERE {
  ?tree0 (wdt:P150)* ?item .
  ?tree0 (wdt:P171|wdt:P273|wdt:P75|wdt:P76|wdt:P77|wdt:P70|wdt:P71|wdt:P74|wdt:P89)* wd:Q729 .
}

Times out HORRIBLY (test it!).

My advice is to follow Magnus advice to invest in SPARQL, but if you are serious about using this in your project, I'll add a abstraction layer and be prepared to failed queries. (which you should do anyway).

Edit:

Despite of this, WDQ seems more unstable (or maybe it's the fact that it is in the domain wmflabs.org, being a DNS problem or not):

As Magnus Manske points out, SPARQL is the preferred way since, I would add, SPARQL is standardized BUT, here is the downside:

The SPARQL endpoint, at this point in time, is NOT as reliable as WDQ yet, for example a query like this:

https://wdq.wmflabs.org/api?q=tree[729][150][171,273,75,76,77,70,71,74,89]

Which returns all animals in wikidata, takes 15 seconds to complete as WDQ query, and the equivalent (via https:// tools.wmflabs.org/wdq2sparql/w2s.php) in SPARQL:

prefix wdt: <http://www.wikidata.org/prop/direct/>
prefix wd: <http://www.wikidata.org/entity/>
SELECT ?item WHERE {
  ?tree0 (wdt:P150)* ?item .
  ?tree0 (wdt:P171|wdt:P273|wdt:P75|wdt:P76|wdt:P77|wdt:P70|wdt:P71|wdt:P74|wdt:P89)* wd:Q729 .
}

Times out HORRIBLY (test it!).

My advice is to follow Magnus advice to invest in SPARQL, but if you are serious about using this in your project, I'll add a abstraction layer and be prepared to failed queries. (which you should do anyway).

Edit:

Despite of this, WDQ seems more unstable, at least from the availability perspective (maybe it´s just the wmflabs.org domain, or whatever, but here are the unfiltered results)  :

As Magnus Manske points out, SPARQL is the preferred way since, I would add, SPARQL is standardized BUT, here is the downside:

The SPARQL endpoint, at this point in time, is NOT as stable as WDQ yet, for example a query like this:

https://wdq.wmflabs.org/api?q=tree[729][150][171,273,75,76,77,70,71,74,89]

Which returns all animals in wikidata, takes 15 seconds to complete as WDQ query, and the equivalent (via https:// tools.wmflabs.org/wdq2sparql/w2s.php) in SPARQL:

prefix wdt: <http://www.wikidata.org/prop/direct/>
prefix wd: <http://www.wikidata.org/entity/>
SELECT ?item WHERE {
  ?tree0 (wdt:P150)* ?item .
  ?tree0 (wdt:P171|wdt:P273|wdt:P75|wdt:P76|wdt:P77|wdt:P70|wdt:P71|wdt:P74|wdt:P89)* wd:Q729 .
}

Times out HORRIBLY (test it!).

My advice is to follow Magnus advice to invest in SPARQL, but if you are serious about using this in your project, I'll add a abstraction layer and be prepared to failed queries. (which you should do anyway).

As Magnus Manske points out, SPARQL is the preferred way since, I would add, SPARQL is standardized BUT, here is the downside:

The SPARQL endpoint, at this point in time, is NOT as stable as WDQ yet, for example a query like this:

https://wdq.wmflabs.org/api?q=tree[729][150][171,273,75,76,77,70,71,74,89]

Which returns all animals in wikidata, takes 15 seconds to complete as WDQ query, and the equivalent (via https:// tools.wmflabs.org/wdq2sparql/w2s.php) in SPARQL:

prefix wdt: <http://www.wikidata.org/prop/direct/>
prefix wd: <http://www.wikidata.org/entity/>
SELECT ?item WHERE {
  ?tree0 (wdt:P150)* ?item .
  ?tree0 (wdt:P171|wdt:P273|wdt:P75|wdt:P76|wdt:P77|wdt:P70|wdt:P71|wdt:P74|wdt:P89)* wd:Q729 .
}

Times out HORRIBLY (test it!).

My advice is to follow Magnus advice to invest in SPARQL, but if you are serious about using this in your project, I'll add a abstraction layer and be prepared to failed queries. (which you should do anyway).

Edit:

Despite of this, WDQ seems more unstable (or maybe it's the fact that it is in the domain wmflabs.org, being a DNS problem or not):

As Magnus Manske, SPARQL is the preferred way since, I would add, that SPARQL is standardized and it's the main reason for it's preference BUT, here is the downside.

The SPARQL endpoint, in this point in time, is NOT as stable as WDQ, for example (extreme but it's completely valid) a query like this:

https://wdq.wmflabs.org/api?q=tree[729][150][171,273,75,76,77,70,71,74,89]

Which returns all animals in wikidata, takes 15 seconds to complete as WDQ query, and the equivalent (via https:// tools.wmflabs.org/wdq2sparql/w2s.php) in SPARQL:

prefix wdt: <http://www.wikidata.org/prop/direct/>
prefix wd: <http://www.wikidata.org/entity/>
SELECT ?item WHERE {
  ?tree0 (wdt:P150)* ?item .
  ?tree0 (wdt:P171|wdt:P273|wdt:P75|wdt:P76|wdt:P77|wdt:P70|wdt:P71|wdt:P74|wdt:P89)* wd:Q729 .
}

Times out HORRIBLY (test it!).

My advice is to follow Magnus Manske advice to invest in SPARQL, but if you are serious about using this in an API, I'll add a abstraction layer or be prepared to query to fail.

As Magnus Manske points out, SPARQL is the preferred way since, I would add, SPARQL is standardized BUT, here is the downside:

The SPARQL endpoint, at this point in time, is NOT as stable as WDQ yet, for example a query like this:

https://wdq.wmflabs.org/api?q=tree[729][150][171,273,75,76,77,70,71,74,89]

Which returns all animals in wikidata, takes 15 seconds to complete as WDQ query, and the equivalent (via https:// tools.wmflabs.org/wdq2sparql/w2s.php) in SPARQL:

prefix wdt: <http://www.wikidata.org/prop/direct/>
prefix wd: <http://www.wikidata.org/entity/>
SELECT ?item WHERE {
  ?tree0 (wdt:P150)* ?item .
  ?tree0 (wdt:P171|wdt:P273|wdt:P75|wdt:P76|wdt:P77|wdt:P70|wdt:P71|wdt:P74|wdt:P89)* wd:Q729 .
}

Times out HORRIBLY (test it!).

My advice is to follow Magnus advice to invest in SPARQL, but if you are serious about using this in your project, I'll add a abstraction layer and be prepared to failed queries. (which you should do anyway).