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&languages=en&format=json 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 <jeroended...@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@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata > _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
