You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce a new field under models for all entity types, entitled 'spelling variants', a multiple field which will accept individual strings (one or more words). E.g., we want to create C "democratisation", and put "democratization" in 'spelling variants', and then find C democratisation also when searching for democratization.
In all searches, treat any of the spelling variants as the 'label' (I think you call label 'name' internally in the DB).
If the user confirms as spelling variant the same string as the 'label' or as any already existing spelling variant, it should not be added (this would create an unnecesary duplicate; message: 'spelling variant already exists').
The user needs to be able to remove any spelling variant later, design-wise probably the same way as you remove an entity class from lists of entity classes.
More detailed rationale (written esp. for historians):
C and A Entities are lemma-meaning units. Orthographic variation is not a difference of meaning, and should not matter and should not lead in creating them as new entities (linked as SYN), but is needed for querying. (Such over-burgeoning of entities makes the data quite messy to query and do research on, and in this case, quite unnecessarily.) Thus, I propose to add a new field to all entity types – a multifield, where individual items will be individual orthographic variants.
(In Persons, editors can, by perfectionism or doubt, decide that P. Fornerii and Petrus Fornerii will be created separately and linked with IDE – this is not necessarily discouraged and is not related to this proposal. This proposal argues that we need to have a way not to create A vocatus and A vochatus as two verbs, and double the work on the action description, but we still want to find find vocatus trough vochatus.
I don’t care whether some borderline cases will lead to more entities even in C and A, esp. if the variation is so massive as to constitute uncertainty of the same lemma and/or meaning. This will still be possible. My concern is to solve the normal case, where we have becharius, beccarius, becarius… and want to find trough InkVisitor Suggester field the basic variant when searching for any of them.
The text was updated successfully, but these errors were encountered:
davidzbiral
changed the title
Introduce new field under all entities 'spelling variants'
Introduce new field under all entities 'spelling variants', and include it in searches just as 'label'
Oct 3, 2024
davidzbiral
changed the title
Introduce new field under all entities 'spelling variants', and include it in searches just as 'label'
Introduce new field 'spelling variants' under all entity types, and include it in searches just as 'label'
Oct 3, 2024
@adammertel Endorsed by H4 and related to upcoming work. I prioritize - but still the working Annotator (user-friendly basic functionalities) is top priority.
Introduce a new field under models for all entity types, entitled 'spelling variants', a multiple field which will accept individual strings (one or more words). E.g., we want to create C "democratisation", and put "democratization" in 'spelling variants', and then find C democratisation also when searching for democratization.
In all searches, treat any of the spelling variants as the 'label' (I think you call label 'name' internally in the DB).
If the user confirms as spelling variant the same string as the 'label' or as any already existing spelling variant, it should not be added (this would create an unnecesary duplicate; message: 'spelling variant already exists').
The user needs to be able to remove any spelling variant later, design-wise probably the same way as you remove an entity class from lists of entity classes.
More detailed rationale (written esp. for historians):
The text was updated successfully, but these errors were encountered: