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

> So when I type in "Leo Gestel" to the [1] Api demo interface I get the 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.

> [1] http://queryr.wmflabs.org/about/demo

> [2] http://queryr.wmflabs.org/api/items/Q597999

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?

> * http://queryr.wmflabs.org/api/items/Q42/data/occupation returns only
> one value, shouldn't it return multiple ones?

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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata