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]!
sitelink(siteId: String!): Sitelink
statements(propertyId: String!): [Statement]!
}
type Sitelink {
title: String!
url: String!
}
type Statement {
id: String!
property: PredicateProperty!
value: Value!
rank: Rank!
qualifiers(propertyId: String!): [PropertyValuePair]!
references: [Reference]!
}
type PropertyValuePair {
property: PredicateProperty!
value: Value!
}
type Reference {
parts: [PropertyValuePair]!
}
type PredicateProperty {
id: String!
data_type: String # ideally enum but TBD
}
enum Rank {
PREFERRED
NORMAL
DEPRECATED
}
type Value {
# ...
}- 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 resolvercreate 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 - "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
- BatchGetItemLabels
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)