Hey Jeroen,
awesome. I think it's very important to make sure everyone can access
Wikidata's data as easy as possible. For many, i suppose SPARQL is
just a bit too complex, and the API is lacking in simplicity as well.
Considering common use cases, i've built the Sum of All Knowledge
where i needed to tackle the same problem (read-only access), it might
be interesting to compare how our approaches differ.
This is an example of a Sum page:
http://sum.bykr.org/328523
Which maps to this Wikidata item:
https://www.wikidata.org/wiki/Q328523
The Sum application has a strict separation of concerns model, where
the backend is a separate Python application called Chantek:
https://github.com/hay/chantek
Here's the JSON format that is served over the wire to the Sum frontend:
http://api.haykranen.nl/wikidata/entity?q=Q328523
And here's the one from QueryR:
http://queryr.wmflabs.org/api/items/Q328523
For comparison, here's the one from the official API:
https://www.wikidata.org/w/api.php?action=wbgetentities&ids=Q328523&…
I suppose the main difference is that your API is even simpler than
mine. One thing that might be difficult is having the property labels
as keys in the JSON. Those things tend to change, and having the
Property ID there is probably safer.
One other thing that i've added is a direct link to the image,
otherwise that's another query.
-- Hay
On Mon, Nov 30, 2015 at 2:55 PM, Jeroen De Dauw <jeroendedauw(a)gmail.com> wrote:
Hey all,
I've created a very rough REST API for Wikidata and am looking for your
feedback.
* About this API:
http://queryr.wmflabs.org
* Documentation:
http://queryr.wmflabs.org/about/docs
* API root:
http://queryr.wmflabs.org/api
At present this is purely a demo. The data it serves is stale and
potentially incomplete, the endpoints and formats they use are very much
liable to change, the server setup is not reliable and I'm not 100% sure
I'll continue with this little project.
The main thing I'm going for with this API compared to the existing one is
greater ease of use for common use cases. Several factors make this a lot
easier to do in a new API than in the existing one: no need the serve all
use cases, no need to retain compatibility with existing users and no
framework imposed restrictions. You can read more about the difference on
the website.
You are invited to comment on the concept and on the open questions
mentioned on the website.
Cheers
--
Jeroen De Dauw -
http://www.bn2vs.com
Software craftsmanship advocate
~=[,,_,,]:3
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata