| daniel changed the title from "[Epic] support for sub-entities for forms and senses" to "[Tracking] Support for Forms and Senses". daniel edited projects, added Tracking; removed Epic. daniel edited the task description. (Show Details) |
EDIT DETAILS
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 Senses.
{F6371011} {F6371012} {F6371010}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.
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 itForms and Senses shall be stored 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_pagesame page as the Lexeme they belong to, PropertyInfoTableBuilderand thus share that page's history, SqlEntityInfoBuildertalk page, …
* see also {T95685}
* Display and editing
* investigate work needed for static display of nested entititesprotection status, 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)etc.
{F6371011} {F6371012} {F6371010}
In order to properly support lexicographical data we need the concept of a sub-entity for Forms and Senses.
{F6371011} {F6371012} {F6371010}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.
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 itForms and Senses shall be stored 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_pagesame page as the Lexeme they belong to, PropertyInfoTableBuilderand thus share that page's history, SqlEntityInfoBuildertalk page, …
* see also {T95685}
* Display and editing
* investigate work needed for static display of nested entititesprotection status, 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)etc.
{F6371011} {F6371012} {F6371010}
TASK DETAIL
EMAIL PREFERENCES
To: daniel
Cc: WMDE-leszek, Jan_Dittrich, Liuxinyu970226, daniel, Aklapper, Lydia_Pintscher, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Darkdadaah, Mbch331
Cc: WMDE-leszek, Jan_Dittrich, Liuxinyu970226, daniel, Aklapper, Lydia_Pintscher, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Darkdadaah, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
