Change Details

In order to properly support lexicographical data we need the concept of a sub-entity for Form and Sense. 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 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 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 Sense.s. {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)