Change Details

With the #mediawiki-extensions-wikibasemediainfo and #lexicographical_data extensions we are going to introduce new term types that are not labels, descriptions and aliases. We already phased out all places in our code base that assumed all entity types do have labels, descriptions, and aliases, or made them flexible by type checking against the `LabelsProvider`, `DescriptionsProvider`, and `AliasesProvider` interfaces first. We figured that the `LabelDescriptionLookup` interface is one of the central remaining elements still assuming all entity types (might) have these term types. We may rethink this interface and its usages. Things we already know (from discussions within the team, mostly with @daniel): * We should **not** phase out the `LabelDescriptionLookup` interface, and **not** split it into two independent ones. These two elements belong together, e.g. when rendering search results or links where the description is used as a tooltip to disambiguate Items that have the same label. * It might help to introduce a `LabelLookup` interface for all use cases that do not need the description. * We might rethink what "label" and "description" mean. Currently, these are the names of two fields on the Item and Property entity types, and we decided to **not** have identical fields on the other entity types. But what if we auto-generate labels and descriptions for Lexeme and MediaInfo entities, auto-generated from other terms? @daniel named this concept "display label" and "display description" for now. If we go this route and start to distinguish these two meanings, we might need to rename some of the existing providers and lookups into `DisplayLabelLookup` and so on. So this is a research and discussion ticket, as well as a place to bikeshed about how to name things. ;-) #patch-for-review: * [ ] https://github.com/wmde/WikibaseDataModelServices/pull/176

With the #mediawiki-extensions-wikibasemediainfo and #lexicographical_data extensions we are going to introduce new term types that are not labels, descriptions and aliases. We already phased out all places in our code base that assumed all entity types do have labels, descriptions, and aliases, or made them flexible by type checking against the `LabelsProvider`, `DescriptionsProvider`, and `AliasesProvider` interfaces first. We figured that the `LabelDescriptionLookup` interface is one of the central remaining elements still assuming all entity types (might) have these term types. We may rethink this interface and its usages. Things we already know (from discussions within the team, mostly with @daniel): * We should **not** phase out the `LabelDescriptionLookup` interface, and **not** split it into two independent ones. These two elements belong together, e.g. when rendering search results or links where the description is used as a tooltip to disambiguate Items that have the same label. * It might help to introduce a `LabelLookup` interface for all use cases that do not need the description. * We might rethink what "label" and "description" mean. Currently, these are the names of two fields on the Item and Property entity types, and we decided to **not** have identical fields on the other entity types. But what if we auto-generate labels and descriptions for Lexeme and MediaInfo entities, auto-generated from other terms? @daniel named this concept "display label" and "display description" for now. If we go this route and start to distinguish these two meanings, we might need to rename some of the existing providers and lookups into `DisplayLabelLookup` and so on. Some critical places where LabelDescriptionLookup is used, which should probably also work in the same way (or in a very similar way) for Lexemes, Forms, MediaInfo, etc: * EntityIdValueFormatter as used when rendering statements (in HTML as well as Wikitext for ParserFunctions and Lua) * EntityIdFormatter as used when rendering edit summaries and when replacing page titles in listings. See e.g. HistoryEntityAction * TermsRdfBuilder providing rdfs:label, skos:prefLabel, schema:name, and schema:description. * TermIndexField (and subclasses) exposing the label and description to CirrusSearch, enabling prefix/completion matching for labels and display of descriptions in search results. * TermIndexSearchInteractor and EntitySearchTermIndex for formatting search results for the wbsearchentities API module * Entity.getLabel and Entity.getDescription in the Wikibase Lua module. * InfoActionHookHandler and EditActionHookHandler for displaying entity usage on action=info and action=edit, respectively When designing a mapping between entity types and "virtual" labels and descriptions, the above use cases should be considered. So this is a research and discussion ticket, as well as a place to bikeshed about how to name things. ;-) #patch-for-review: * [ ] https://github.com/wmde/WikibaseDataModelServices/pull/176

With the #mediawiki-extensions-wikibasemediainfo and #lexicographical_data extensions we are going to introduce new term types that are not labels, descriptions and aliases. We already phased out all places in our code base that assumed all entity types do have labels, descriptions, and aliases, or made them flexible by type checking against the `LabelsProvider`, `DescriptionsProvider`, and `AliasesProvider` interfaces first. We figured that the `LabelDescriptionLookup` interface is one of the central remaining elements still assuming all entity types (might) have these term types. We may rethink this interface and its usages. Things we already know (from discussions within the team, mostly with @daniel): * We should **not** phase out the `LabelDescriptionLookup` interface, and **not** split it into two independent ones. These two elements belong together, e.g. when rendering search results or links where the description is used as a tooltip to disambiguate Items that have the same label. * It might help to introduce a `LabelLookup` interface for all use cases that do not need the description. * We might rethink what "label" and "description" mean. Currently, these are the names of two fields on the Item and Property entity types, and we decided to **not** have identical fields on the other entity types. But what if we auto-generate labels and descriptions for Lexeme and MediaInfo entities, auto-generated from other terms? @daniel named this concept "display label" and "display description" for now. If we go this route and start to distinguish these two meanings, we might need to rename some of the existing providers and lookups into `DisplayLabelLookup` and so on. Some critical places where LabelDescriptionLookup is used, which should probably also work in the same way (or in a very similar way) for Lexemes, Forms, MediaInfo, etc: * EntityIdValueFormatter as used when rendering statements (in HTML as well as Wikitext for ParserFunctions and Lua) * EntityIdFormatter as used when rendering edit summaries and when replacing page titles in listings. See e.g. HistoryEntityAction * TermsRdfBuilder providing rdfs:label, skos:prefLabel, schema:name, and schema:description. * TermIndexField (and subclasses) exposing the label and description to CirrusSearch, enabling prefix/completion matching for labels and display of descriptions in search results. * TermIndexSearchInteractor and EntitySearchTermIndex for formatting search results for the wbsearchentities API module * Entity.getLabel and Entity.getDescription in the Wikibase Lua module. * InfoActionHookHandler and EditActionHookHandler for displaying entity usage on action=info and action=edit, respectively When designing a mapping between entity types and "virtual" labels and descriptions, the above use cases should be considered. So this is a research and discussion ticket, as well as a place to bikeshed about how to name things. ;-) #patch-for-review: * [ ] https://github.com/wmde/WikibaseDataModelServices/pull/176