[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries across Wikimedia
dbarratt added a comment.
In T173214#4736866, @Tpt wrote:
I just had a quick review of the current GraphQL structure for Wikibase entities. It looks great! Thank you!
No problem. I'm learning a lot about GraphQL (and the Action API) so it's been fun. :)
I would switch the Entity type to an interface and have Item, Property, Lexeme... implementations
I went back and forth on this a whole lot. I started out with it just as you described, and I abandoned it. At a certain level, I completely agree this is the way it should be. The entities are different types, so GraphQL should expose it the same way. On the other side of this... it is a dark rabbit hole of despair. We have different types of things all over the place. We have different types of pages, we have different types of images, we have different type of blocks, we even have different types of sites (some have Wikibase, some do not).
Even within entity, it's not clear. You've listed the types of entities, but those are specific to Wikidata. Commons for instance will have a Media type which is M. Should we include that?
Eventually I came to this "rule of the road"
Nullable fields do not justify new types.
What I mean by this, is that if the only difference between a two types is that one has a field and one does not, that does not mean that they should become new types. Actually avoiding new types seems to be way easier (from a development side).
However, I realize that this is probably not ideal. Indeed, the typing can be used for conditions that I hadn't really thought about. For instance, MediaWiki has different image types DRAWING and BITMAP are examples. I implemented the method to get thumbnail images, but without the typing, it makes requests for thumbnail images even if you don't want/need them (for instance, on DRAWING).
I also noticed that the Action API uses a lot of enums for values... should the server maintain a list of these values?
Having robust typing, that is aware of the domain knowledge of the wiki (which is completely configurable), seems like way outside of the scope of the server. For one thing, half of things you'd need to know (like which types of entities exist on a wiki and which fields they have) do not even have API endpoints that you can lookup this information, it only exists in code or in configuration.
With all of that... I think GraphQL requests should be delegated to their individual sites T209133. This way each site runs it's own GraphQL server (as a MediaWiki extension) and can be aware of it's own extensions, and allow each extension to implement it's own typings. That way, the decisions of what types should exist or not exist is delegated to the extensions themselves rather than trying to make that decision for everyone.
type, datatype and snaktype fields values should probably be enumerations to be more GraphQLish
I'm not sure what that means? I'm just returning what comes back from the Action API, but yeah if we implemented different types that field would no longer be needed.
I would merge the EntityLabel and SnakValueMonolingualTextValue types because they represent the same object according to the Wikibase DataModel.
That's a great idea. T209439
I would remove the SnakValue* types (SnakValueString, SnakValueEntity...) because they only provide the "type" field that seems not needed and the feature it covers is already done by the __type introspection field
They actually implement a value key:
type SnakValueString implements SnakValue {
value: String
# SnakValue
type: String
}
type SnakValueEntity implements SnakValue {
value: Entity
# SnakValue
type: String
}
This is actually one of the reasons I'm not a huge fan of having multiple types, it's not obvious that you need to specify the types. I had the same problem in T173214#4442448 haha. :)
I would do something like this:
type SnakValue {
value: Entity | String
type: String
}
but GraphQL does not allow a union on a scalar. :( and I wanted it to be as close to the existing Action API as possible.
Ironically, this is the place where I did implement different types (out of necessity) and both of us found it more difficult to use. :/ I can't imagine how hard it would be to use if there were different types everywhere, but then again if you expect it maybe it's not that bad?
I would rename the Claim type to Statement. In the Wikibase DataModel a "claim" is an affirmation (i.e. a main snak and some qualifiers) and the (claim, references, rank) structure is a "statement"
I decided that claims was more apporiate for two reasons.
Wikibase uses claims in it's API response and I wanted to stay as close to that as possible. https://www.wikidata.org/w/api.php?action="">
Wikibase exposes a getclaims action to get the claims: https://www.wikidata.org/w/api.php?action="">
From the API response, it actually appears that a Statement is a type of Claim. So really a Claim should be an interface, but the field should
[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries across Wikimedia
gerritbot added a project: Patch-For-Review. TASK DETAILhttps://phabricator.wikimedia.org/T173214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Smalyshev, Lydia_Pintscher, Addshore, larsgw, Saerdnaer, simon04, bearND, Siznax, Tpt, Jonas, Ricordisamoa, hoo, Lucas_Werkmeister_WMDE, Aklapper, dbarratt, PokestarFan, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, He7d3r, Jdforrester-WMF, Mbch331, Jay8g, Tgr___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries
Smalyshev removed a project: Wikidata-Query-Service.Smalyshev added a comment. Sounds very interesting but probably not part of any work for #wikidata-query-service, so I am removing the tag.TASK DETAILhttps://phabricator.wikimedia.org/T173214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, Lydia_Pintscher, Addshore, larsgw, Saerdnaer, simon04, bearND, Siznax, Tpt, Jonas, Ricordisamoa, hoo, Lucas_Werkmeister_WMDE, Aklapper, dbarratt, PokestarFan, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331, EBjune, merbst, Xmlizer, jkroll, Jdouglas, Tobias1984, Manybubbles___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries
dbarratt added a revision: D1082: CORS Preflight causes a PHP Fatal Error. TASK DETAILhttps://phabricator.wikimedia.org/T173214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: dbarrattCc: Addshore, larsgw, Saerdnaer, simon04, bearND, Siznax, Tpt, Jonas, Ricordisamoa, hoo, Lucas_Werkmeister_WMDE, Aklapper, dbarratt, PokestarFan, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries
dbarratt edited projects, added MediaWiki-extensions-WikibaseRepository; removed wikibase-registry. TASK DETAILhttps://phabricator.wikimedia.org/T173214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: dbarrattCc: Addshore, larsgw, Saerdnaer, simon04, bearND, Siznax, Tpt, Jonas, Ricordisamoa, hoo, Lucas_Werkmeister_WMDE, Aklapper, dbarratt, PokestarFan, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331, LJ, SandraF_WMF, Andrawaag, Daniel_Mietchen, Lydia_Pintscher___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries
dbarratt added projects: Wikidata.org, Wikidata-Query-Service, wikibase-registry. TASK DETAILhttps://phabricator.wikimedia.org/T173214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: dbarrattCc: Addshore, larsgw, Saerdnaer, simon04, bearND, Siznax, Tpt, Jonas, Ricordisamoa, hoo, Lucas_Werkmeister_WMDE, Aklapper, dbarratt, PokestarFan, LJ, Lahi, Gq86, SandraF_WMF, Andrawaag, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Daniel_Mietchen, Manybubbles, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries
dbarratt added a revision: D1081: Add CORS Header. TASK DETAILhttps://phabricator.wikimedia.org/T173214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: dbarrattCc: Addshore, larsgw, Saerdnaer, simon04, bearND, Siznax, Tpt, Jonas, Ricordisamoa, hoo, Lucas_Werkmeister_WMDE, Aklapper, dbarratt, PokestarFan, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries
dbarratt added a comment. @Tpt Here's a patch to enable CORS on the graphql endpoint. :) D1081TASK DETAILhttps://phabricator.wikimedia.org/T173214EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: dbarrattCc: Addshore, larsgw, Saerdnaer, simon04, bearND, Siznax, Tpt, Jonas, Ricordisamoa, hoo, Lucas_Werkmeister_WMDE, Aklapper, dbarratt, PokestarFan, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T173214: Support GraphQL Queries
Tpt added a comment.
I just started to implement a simple GraphQL wrapper on top of the Wikibase API in order to see how it could be implemented in practice. It currently maps most of the PHP DataModel structures with an interface similar to the one of the JSON API and provides some demo queries and mutations.
Here are some samples (click on the execute button to retrieve the execution of the query):
Get the English label, the French description of aliases of Q42 and its sitelink in ruwiki with the English label of its badges: https://tools.wmflabs.org/tptools/wdql.html?query=%7B%0A%20%20champollion%3A%20item(id%3A%20%22Q260%22)%20%7B%0A%20%20%20%20id%0A%20%20%20%20labels%20%7B%0A%20%20%20%20%20%20en%20%7B%0A%20%20%20%20%20%20%20%20value%0A%20%20%20%20%20%20%20%20language%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%20%20descriptions%20%7B%0A%20%20%20%20%20%20fr%20%7B%0A%20%20%20%20%20%20%20%20value%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%20%20aliases%20%7B%0A%20%20%20%20%20%20fr%20%7B%0A%20%20%20%20%20%20%20%20value%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%20%20sitelinks%20%7B%0A%20%20%20%20%20%20ruwiki%20%7B%0A%20%20%20%20%20%20%20%20site%0A%20%20%20%20%20%20%20%20title%0A%20%20%20%20%20%20%20%20badges%20%7B%0A%20%20%20%20%20%20%20%20%20%20id%0A%20%20%20%20%20%20%20%20%20%20labels%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20en%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20value%0A%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D%0A
Retrieve the VIAF id of Q260 with some data about the property and references: https://tools.wmflabs.org/tptools/wdql.html?query=%7B%0A%20%20champollion%3A%20item(id%3A%20%22Q260%22)%20%7B%0A%20%20%20%20claims%20%7B%0A%20%20%20%20%20%20P214%20%7B%0A%20%20%20%20%20%20%20%20id%0A%20%20%20%20%20%20%20%20rank%0A%20%20%20%20%20%20%20%20mainsnak%20%7B%0A%20%20%20%20%20%20%20%20%20%20...%20on%20PropertyValueSnak%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20property%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20id%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20datatype%0A%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20datatype%0A%20%20%20%20%20%20%20%20%20%20%20%20value%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20type%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20...%20on%20StringValue%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20value%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20references%20%7B%0A%20%20%20%20%20%20%20%20%20%20hash%0A%20%20%20%20%20%20%20%20%20%20snaks%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20P143%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20type%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20...%20on%20PropertyValueSnak%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20value%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20...%20on%20Entity%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20id%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D%0A
An example of mutation (set the English label of Q42):
mutation foo {
foo: setLabel(id: "Q42", language: "en", value: "Douglas Adams")
}
Warning: there is no way to log-in yet so if you try to execute it is going to fail because labs IPs are blocked.
Implementation related points:
Source code is here: https://phabricator.wikimedia.org/source/tool-tptools/browse/master/ the interesting files are public_html/wdql.php (entry point) and src/GraphQL/*
I am using a GraphQL PHP library https://webonyx.github.io/graphql-php/ that is fairly stable and provides advanced features like query complexity limitations. If we want in the far future provide a GraphQL API in Wikibase it seems possible to use it with MediaWiki.
To make the data look more like a graph and less than a set of documents each time a field in the JSON API has for value an EntityId, an EntityIdValue or an entity URI the GraphQL API returns an Entity instead.
The type system reuses the naming used in https://www.mediawiki.org/wiki/Wikibase/DataModel with a top interface called Value that is extended by both Entity and the different DataValues.
TODO:
Solve the questions below
Do a lot of optimizations.
Implement more mutations
See if the could merge the MonolingualTextValue and Term objects (they seems duplicate to me)
Implement more lookups (by sitelink, by property/value...).
Questions:
Is it moving into the right direction?
Is the structure well designed?
There is no way currently to get all statements
