Change Details

As a user I want to be able to provide forms and senses of a lexeme. I want to be able to make statements (including references and qualifiers) about the different forms and senses of a lexeme. I also want to be able to make statements about the lexeme itself in order to record the etymology of a word for example. The statements should make use of the existing items and properties. Adding, editing, removing and history should work like they do for items. In order to properly support lexicographical data we need the concept of a sub-entity for Forms and Senses. {F6371011} {F6371012} {F6371010} Things to consider: * Structured IDs (we will use the hyphen as a separator, as in L768234-F7) * Lookup and Store (EntityRevisionLookup, EntityStore) need to support "structured" IDs. * Assigning fresh IDs (even after sub-entities have been deleted). * Just track it as part of the parent entity? Where should it (not) be exposed? * How to represent sub-entities in wb_terms. * See also {T159718} * Kill wb_entity_per_page, PropertyInfoTableBuilder, SqlEntityInfoBuilder, … * see also {T95685} * Display and editing * investigate work needed for static display of nested entitites, as well as for making the dynamic editing UI work with multiple (nested) entities. * Define an RDF binding (Special:EntityData). * Check how much we can rely on LEMON. * Serialization + Diffing (should be trivial)

As a user I want to be able to provide Forms and Senses of a Lexeme. I want to be able to make Statements (including References and Qualifiers) about the different Forms and Senses of a Lexeme. I also want to be able to make Statements about the Lexeme itself in order to record the etymology of a word for example. The existing Items and Properties can be used to make such Statements. Adding, editing, removing should work like they do for items. As a user, I also want to be able to reference individual Forms and Senses from Statements, in the same way I can reference Items and Properties. Forms and Senses shall be stored as part of the same page as the Lexeme they belong to, and thus share that page's history, talk page, protection status, etc. {F6371011} {F6371012} {F6371010}

As a user I want to be able to provide fForms and sSenses of a lLexeme. I want to be able to make sStatements (including rReferences and qQualifiers) about the different fForms and sSenses of a lLexeme. I also want to be able to make sStatements about the lLexeme itself in order to record the etymology of a word for example. The statements should make use of the existing items and propertiesexisting Items and Properties can be used to make such Statements. Adding, editing, removing and history should work like they do for items. In order to properly support lexicographical data we need the concept of a sub-entity for Forms and SensAs a user, I also want to be able to reference individual Forms and Senses from Statements, in the same way I can reference Items and Properties. Forms and Senses shall be stored as part of the same page as the Lexeme they belong to, and thus share that page's history, talk page, protection status, etc. {F6371011} {F6371012} {F6371010} Things to consider: * Structured IDs (we will use the hyphen as a separator, as in L768234-F7) * Lookup and Store (EntityRevisionLookup, EntityStore) need to support "structured" IDs. * Assigning fresh IDs (even after sub-entities have been deleted). * Just track it as part of the parent entity? Where should it (not) be exposed? * How to represent sub-entities in wb_terms. * See also {T159718} * Kill wb_entity_per_page, PropertyInfoTableBuilder, SqlEntityInfoBuilder, … * see also {T95685} * Display and editing * investigate work needed for static display of nested entitites, as well as for making the dynamic editing UI work with multiple (nested) entities. * Define an RDF binding (Special:EntityData). * Check how much we can rely on LEMON. * Serialization + Diffing (should be trivial)