Change Details

As a user I want to see what is behind a link to a lexeme in a statement, recent changes, page history and more. I also want to be able to find a lexeme by one of its forms in an entity selector. For the display part we need a way to derive a label and description from the data in a Lexeme. For the search part we need to treat all the forms of a lexeme as aliases. The derived label would be the lemma. The derived description would be a combination of lexical category and language of lexeme. The derived aliases would be all the representations of the forms of the lexeme. =Task breakdown by Daniel= * define service interface (consider defining separate entities for display and for indexing) * define base implementation for entities that have labels/descriptions/aliases (those that implement LabelsProvider, etc) * define extension point for alternative mappings for labels, descriptions and aliases for entity types that do not define those directly * replace direct access to labels, descriptions, aliases and fingerprint in code that should work for all entity types. Code that is specific to an entity type can and should still access labels, descriptions and aliases directly, as structural elements of the data model.

As a user I want to see what is behind a link to a lexeme in a statement, recent changes, page history and more. I also want to be able to find a lexeme by one of its forms in an entity selector. For the display part we need a way to derive a label and description from the data in a Lexeme. For the search part we need to treat all the forms of a lexeme as aliases. The derived label would be the lemma. The derived description would be a combination of lexical category and language of lexeme. The derived aliases would be all the representations of the forms of the lexeme. LabelDescriptionLookup should now be interpreted to return //display// labels and descriptions, not //model// label and descriptions. =Task breakdown by Daniel= * define service interface for mapping entities to labels, descriptions, and aliases (consider defining separate entities for display and for indexing). The interface can be modeled after LabelDescriptionLookup, but would get an Entity object, not just an EntityId. * define base implementation for entities that have labels/descriptions/aliases (those that implement LabelsProvider, etc) * define extension point for alternative mappings for labels, descriptions and aliases for entity types that do not define those directly * replace direct access to labels, descriptions, aliases and fingerprint in code that should work for all entity types. Code that is specific to an entity type can and should still access labels, descriptions and aliases directly, as structural elements of the data model.

As a user I want to see what is behind a link to a lexeme in a statement, recent changes, page history and more. I also want to be able to find a lexeme by one of its forms in an entity selector. For the display part we need a way to derive a label and description from the data in a Lexeme. For the search part we need to treat all the forms of a lexeme as aliases. The derived label would be the lemma. The derived description would be a combination of lexical category and language of lexeme. The derived aliases would be all the representations of the forms of the lexeme. LabelDescriptionLookup should now be interpreted to return //display// labels and descriptions, not //model// label and descriptions. =Task breakdown by Daniel= * define service interface for mapping entities to labels, descriptions, and aliases (consider defining separate entities for display and for indexing). The interface can be modeled after LabelDescriptionLookup, but would get an Entity object, not just an EntityId. * define base implementation for entities that have labels/descriptions/aliases (those that implement LabelsProvider, etc) * define extension point for alternative mappings for labels, descriptions and aliases for entity types that do not define those directly * replace direct access to labels, descriptions, aliases and fingerprint in code that should work for all entity types. Code that is specific to an entity type can and should still access labels, descriptions and aliases directly, as structural elements of the data model.