If you are using the P/Q/whatever markers in the id, then you should not differentiate on items and properties in the root. The path /items/{item_id}/data/{property_label} should use the property id and not the property label. The later is not stable. On Mon, Nov 30, 2015 at 2:55 PM, Jeroen De Dauw <jeroendedauw(a)gmail.com> wrote:

It may not be stable but it is what PEOPLE understand. What you can do

<grin> I salute the effort and I appreciate the critique </grin> however many approaches do not have ordinary people in mind but are from ones own perspective. When that is of a developer of a data scientist it is often correct but hardly usable.

Hoi, You are right. However, Hay was critiqued for his approach. Arguably he is absolutely using the right approach for his use case. When you state that people have to go back to Wikidata, it is easier to search for a label than it is to search for an ID. When you are developing software and you use whatever technology, please appreciate that in the final analysis what you create is to be used. JSON, the REST API are for developers but it is a technique not a tool. What Hay demonstrates is a usable tool. Thanks, GerardM On 1 December 2015 at 09:14, Stas Malyshev &lt;smalyshev(a)wikimedia.org&gt; wrote: _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Hoi, In the browsers that I use, when you hover over a property it shows both in Reasonator and in Wikidata .. Hope it helps. Thanks, GerardM On 1 December 2015 at 10:24, Jane Darnell &lt;jane023(a)gmail.com&gt; wrote: _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Hey all, Thanks a lot for your valuable input. ## Labels vs ids This has been raised by several people and for good reason. It's very important to use the stability of ids, which the current item response format does not allow. This is because I've not figured out yet how to best **serve both** the users that want to use the ids, and those that do not want to be forced into dealing with them. I've written down some thoughts on what can be done in this issue [0], and welcome your input (be it here on the mailing list or on the issue). [0] https://github.com/JeroenDeDauw/QueryrAPI/issues/36 If accessing data by relying on labels is ever a good idea has been put into question. The answer to this is not clear to me. Most developers out there do not know about Wikidata, so the most common use case seems to be "get some information out of Wikipedia". In case such developers want to do something where for whichever reason high stability is not required, then it is presumably not nice to force them to figure out what these P123 things are and which one they need. I certainly understand the arguments of "not entirely correct" and "might cause them to make the wrong choice", though forcing casual users to do the more advanced thing rather than just recommending might end up being quite frustrating for them. Note that the item response format is now actually documented :) http://queryr.wmflabs.org/about/docs/item ## /items and /properties vs /entities Can the people that suggested this motivate why they think having a single endpoint would be better? I know that is what the Wikidata API does, though think that is a design flaw which we've not been able to move away from with reasonable cost due to API compatibility concerns. Reasoning from my side is that the type of resource is different (both conceptually and in response format), thus that different endpoints make sense. An added advantage is that you have collection endpoints for just items and just properties. If you only have one for entities, it becomes a lot harder to just walk through properties. ## Entity lookup by non-id info back, but only if I click the option "View on QueryR" do I see the access syntax (2]. I think the user interface should accept Q and P numbers, not labels, though it could provide a lookup gadget. I agree it makes sense to use ids here (as is currently done). At the same time I think it's very important to provide convenient access by Wikipedia page name. That is what the demo search thing does (those are not labels). Such access is crucial for people that want to "get data for this/these Wikipedia page(s)" or "get this specific data for this/these Wikipedia page(s)". The little demo thing currently resolves the page name via the Wikidata API as such lookup is not yet possible via QueryR. I'm thinking of having redirects to the canonical resource: * /wikipedia/$enWikiPageName => /items/$itemId * /wikipedia/$subdomain/$pageName => /items/$itemId $subdomain being the part before ".wikipedia.org" of the relevant Wikipedia ("en" for the English Wikipedia). Does that sound reasonable? Is there a better way to do this? (This is now also tracked by https://github.com/JeroenDeDauw/QueryrAPI/issues/37) ## Sum of All Knowledge Interesting project, and nice separation of concerns! Too bad I was not aware of this when I started writing QueryR. Though it is now indeed certainly nice to learn by looking at the differences between them. The point on having direct links to images is well taken - the reason this is not done yet is because I've yet to get to it. One key difference is that Chantek forwards directly to the Wikidata API, while QueryR has its own persistence. (If you can get away with not having the persistence, then that is definitely the way to go, as it's significantly simpler.) Would you have done anything different in the format you created if you had such persistence? ## Not all values shown? Only the highest ranked values are returned. In case of this set of values, one is preferred and the rest are normal, so only the preferred one is shown. Do you think a different behaviour makes makes more sense? 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

Hey Conal, it described as REST. It doesn't look like hypertext to me. In a REST API, related resources should be represented using hyperlinks. There are hyperlinks in various places. For instance at [0], the items are linked, and pagination can be done via link headers in the response. Are these the type of hyperlinks you are looking for? In addition, are there links that you'd expect at other locations and that are not there yet? Note that a lot of stuff might not be there yet simply due to the very preliminary state of the API, for instance [1]. [0] http://queryr.wmflabs.org/api/items [1] https://github.com/JeroenDeDauw/QueryrAPI/issues/13 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

And if the data serialization is JSON, why not use JSON-LD which is all the rage these days? http://www.w3.org/TR/json-ld/ On Wed, Dec 2, 2015 at 8:27 AM, Conal Tuohy &lt;conal.tuohy(a)gmail.com&gt; wrote: _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

And if the data serialization is JSON, why not use JSON-LD which is all the rage these days? http://www.w3.org/TR/json-ld/

some custom JSON and JSON-LD (and by extension, RDF) as two alternative formats for doing the same thing, than clearly one fails to grasp what the semantics and web of data are about.

Hey, Conal, thanks for explaining. The items are indeed not linked. Indeed, the current format hides the fact that they are items altogether. Perhaps this is going a step too far, and it is better to take an approach similar to that of Hay: still have a dedicated wikibase-item data type for which the value includes the id, but also the label. What are your thoughts on using this approach [0]? (Everyone is welcome to comment on this.) As you can see, it makes the format significantly more verbose and is not quite as trivial to use when you don't care about the links or ids. It's still a lot simpler than dealing with the canonical Wikibase item format, and perhaps strikes a better balance than what I created initially. [0] https://gist.github.com/JeroenDeDauw/fc17f9fdd2e4567a17ff Thanks for the suggestion. I'm not really familiar with JSON-LD and quickly read through the examples there. While this is certainly interesting, I wonder what the actual benefits are, going on the assumption that most developers are unfamiliar with this format. It does add complexity, so I'm quite hesitant to use this in the main format. That said, this might be a good candidate for an additional response format. (And adding additional formats to the API in a clean way ought to be quite easy, see https://github.com/JeroenDeDauw/QueryrAPI/issues/39) 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

An often-cited complaint to me about the Wikidata API is that it's obscure and hard to use. Simple things, like needing the QID of a page rather than being able to give it a URL of a page from a client wiki, can make a big difference to third parties that aren't super familiar with Wikidata.