Hi Jeroen I was interested to take a look at your API but I was surprised to see it described as REST. It doesn't look like hypertext to me. In a REST API, related resources should be represented using hyperlinks.
Conal On 2 December 2015 at 09:23, Jeroen De Dauw <[email protected]> wrote: > 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata > > -- Conal Tuohy http://conaltuohy.com/ @conal_tuohy +61-466-324297
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
