Change Details

We want to build a GraphQL endpoint that allows users to query for labels of linked entities of items Offering this as an alternative to WDQS or making multiple API calls through Action API or REST API **Acceptance criteria:** - Available through reading of an item - Response includes all the elements of the requested entity (labels, descriptions, aliases, sitelinks etc.) - Ensure that only the //labels //of linked entities (statement property, statement value items, statement qualifier and statement references) can be requested, and not everything else (for example, descriptions or subsequent statements and so on.) - Pagination is not needed ------------------------------------ - Multiple instance of one field can be added to the same request, we want to figure out if there is an upper bound here **Task breakdown**: General considerations: * create a `reuse/` domain * ~~use the `GetItem` use case in the item resolver~~ create a BatchGetItems use case * we will need a batch use case anyway for the upcoming batch item story and because GraphQL already allows requesting multiple items at once by using aliases * creating this as a reuse use case means that we stick to the control flow rule of [REST ADR 1](https://doc.wikimedia.org/Wikibase/master/php/rest_adr_0001.html) - "Inputs and outputs of the system must flow from the user side through the business logic to the data side and back. The code on the outermost level must not skip the business logic." * create the following two reuse use cases: * BatchGetItemLabels * takes a list of item ids and a list of label language codes to fetch * BatchGetPropertyLabels * takes a list of property ids and a list of label language codes to fetch Sub-tasks: * create the initial GraphQL server * delete GraphQL prototype code * on a special page * fetches all item data excluding statements (labels, descriptions, aliases, sitelinks) * handles invalid item id * add statements field to item data * include qualifiers and references * excluding value types other than wikibase-entityid and string * excluding labels of linked entities * create BatchGetItemLabels use case * create BatchGetPropertyLabels use case * allow fetching labels of linked properties and items * support additional wikibase core data types (those defined within wikibase repo itself): globecoordinate, monolingualtext, ... * handle unknown value types * ensure that the code doesn't error when encountering data types or value types it doesn't know by either filtering those statements out or displaying them as unknown values * handle value types added by extensions(?) * limit the number of `item` fields used at the root level to 5 * error message TBD * introduce a feature flag for the special page (opt-in)

We want to build a GraphQL endpoint that allows users to query for labels of linked entities of items Offering this as an alternative to WDQS or making multiple API calls through Action API or REST API **Acceptance criteria:** - Available through reading of an item - Response includes all the elements of the requested entity (labels, descriptions, aliases, sitelinks etc.) - Ensure that only the //labels //of linked entities (statement property, statement value items, statement qualifier and statement references) can be requested, and not everything else (for example, descriptions or subsequent statements and so on.) - Pagination is not needed Schema in SDL: ``` type Query { item(id: String!): Item } type Item { id: String! label(languageCode: String!): String description(languageCode: String!): String aliases(languageCode: String!): [String]! # statements and sitelinks TBD } ``` ------------------------------------ - Multiple instance of one field can be added to the same request, we want to figure out if there is an upper bound here **Task breakdown**: General considerations: * create a `reuse/` domain * ~~use the `GetItem` use case in the item resolver~~ create a BatchGetItems use case * we will need a batch use case anyway for the upcoming batch item story and because GraphQL already allows requesting multiple items at once by using aliases * creating this as a reuse use case means that we stick to the control flow rule of [REST ADR 1](https://doc.wikimedia.org/Wikibase/master/php/rest_adr_0001.html) - "Inputs and outputs of the system must flow from the user side through the business logic to the data side and back. The code on the outermost level must not skip the business logic." * create the following two reuse use cases: * BatchGetItemLabels * takes a list of item ids and a list of label language codes to fetch * BatchGetPropertyLabels * takes a list of property ids and a list of label language codes to fetch Sub-tasks: * create the initial GraphQL server * delete GraphQL prototype code * on a special page * fetches all item data excluding statements (labels, descriptions, aliases, sitelinks) * handles invalid item id * add statements field to item data * include qualifiers and references * excluding value types other than wikibase-entityid and string * excluding labels of linked entities * create BatchGetItemLabels use case * create BatchGetPropertyLabels use case * allow fetching labels of linked properties and items * support additional wikibase core data types (those defined within wikibase repo itself): globecoordinate, monolingualtext, ... * handle unknown value types * ensure that the code doesn't error when encountering data types or value types it doesn't know by either filtering those statements out or displaying them as unknown values * handle value types added by extensions(?) * limit the number of `item` fields used at the root level to 5 * error message TBD * introduce a feature flag for the special page (opt-in)

We want to build a GraphQL endpoint that allows users to query for labels of linked entities of items Offering this as an alternative to WDQS or making multiple API calls through Action API or REST API **Acceptance criteria:** - Available through reading of an item - Response includes all the elements of the requested entity (labels, descriptions, aliases, sitelinks etc.) - Ensure that only the //labels //of linked entities (statement property, statement value items, statement qualifier and statement references) can be requested, and not everything else (for example, descriptions or subsequent statements and so on.) - Pagination is not needed Schema in SDL: ``` type Query { item(id: String!): Item } type Item { id: String! label(languageCode: String!): String description(languageCode: String!): String aliases(languageCode: String!): [String]! # statements and sitelinks TBD } ``` ------------------------------------ - Multiple instance of one field can be added to the same request, we want to figure out if there is an upper bound here **Task breakdown**: General considerations: * create a `reuse/` domain * ~~use the `GetItem` use case in the item resolver~~ create a BatchGetItems use case * we will need a batch use case anyway for the upcoming batch item story and because GraphQL already allows requesting multiple items at once by using aliases * creating this as a reuse use case means that we stick to the control flow rule of [REST ADR 1](https://doc.wikimedia.org/Wikibase/master/php/rest_adr_0001.html) - "Inputs and outputs of the system must flow from the user side through the business logic to the data side and back. The code on the outermost level must not skip the business logic." * create the following two reuse use cases: * BatchGetItemLabels * takes a list of item ids and a list of label language codes to fetch * BatchGetPropertyLabels * takes a list of property ids and a list of label language codes to fetch Sub-tasks: * create the initial GraphQL server * delete GraphQL prototype code * on a special page * fetches all item data excluding statements (labels, descriptions, aliases, sitelinks) * handles invalid item id * add statements field to item data * include qualifiers and references * excluding value types other than wikibase-entityid and string * excluding labels of linked entities * create BatchGetItemLabels use case * create BatchGetPropertyLabels use case * allow fetching labels of linked properties and items * support additional wikibase core data types (those defined within wikibase repo itself): globecoordinate, monolingualtext, ... * handle unknown value types * ensure that the code doesn't error when encountering data types or value types it doesn't know by either filtering those statements out or displaying them as unknown values * handle value types added by extensions(?) * limit the number of `item` fields used at the root level to 5 * error message TBD * introduce a feature flag for the special page (opt-in)