| Tpt added a comment. |
Indeed the set of property and their datatypes is very static and cachable so we could use them as keys of a StatementByProperty object and then have StringStatement, StringSnak... types. The object would just be huge and maybe raise some performance problems of the various GraphQL tools (we would have 4K+ keys).
A simple simplification we could do is to add to the Snak interface a nulllable version of the "value" key and keep the not-nullable version to the PropertyValueSnak type. It would allow to avoid most of the ...on PropertyValueSnak checks. But it has the disadvantages of making the output less safe (more possible nulls) and do not highlighting the fact that some snak do not have a value.
For statement filtering by qualifier a good solution is maybe to add an extra parameter "hasStatement" to the statements field and give to it a value of type SnakInput (a GraphQL input type that would be used to encode a snak provided by the GraphQL client). What do you think about it?
Cc: Lydia_Pintscher, 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
