Editor Strategies¶
Handling protected cache fields and atomized data, freetext areas and structure data input, objects that need to be updated but are related to other objcets, and other issues at the same time needs defined stratagies.
This page tries to point out the different strategies and to lay emphasis on the possible alternatives and considered rules.
- Table of contents
- Editor Strategies
Strategies¶
Strategies to be considere are
Interaction of cache / atomized fields and protected /non protected states
Locking freetext area
Object change strategy
NameRelationships: Editing (in particular basionyms and replaced synonyms, parsing of homonyms)
Interaction of cache / atomized fields and protected /non protected states¶
to be done
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Just some text to move this all down
Locking freetext area¶
Attributes that will lead to a lock independent of the object change strategy¶
Attribute | Reasoning | Example(s) | Actions needed | Notes |
---|---|---|---|---|
name.appendedPhrase | a change in name.appededPhrase is shown in the fullTitleCache and therefore in the freetext, but name.appended phrase can not be parsed | |||
NOT: taxon.appendedPhrase | a change in taxon.appededPhrase is not shown in the freetext area | |||
All protected caches like | a change in one of the cache fields is reflected in the fullTitleCache and the freetext. Generally the parser may not be able to set the same protected caches as the details view (either it may unprotect parts that are protected on purpose or more often it will protect other caches that do not need to be protected | Areca calisoA Becc., Leafl. Philipp. Bot. 8: 2998 (1919) may have a protected namecache because the name part is not parsable. Ones you edit this in the freetext the whole string will not be parsable resulting in a protected full title cache | ||
name.fullTitleCache | ||||
name.titleCache | ||||
name.nameCache | ||||
name.authorshipCache | ||||
name.combinationAuthorTeam.nomenclaturalCache (and other teams) |
Attributes that will lead to a lock dependent of the object change strategy¶
- to be done
Object Change Strategy¶
Intentions¶
In general a user may have three main intentions to change an object:
Correct a typo / minor corrections
Change the representation of an existing object
Change "invisible" information
Change the object itself
A user may also change a name unintentionally.
- Unintended change of data
Examples:
Askellia elegans (Hook.) W. A. Weber in Phytol*go*ia 55: 6. 1984 -> Askellia elegans (Hook.) W. A. Weber in Phytol*og*ia 55: 6. 1984
Askellia elegans (Hook.) W. A. Weber in Phytologia 55: 6. 1984 -> A. *elegans (Hook.) W. A. Weber in Phytologia 55 (1984): 6.*
Askellia elegans (Hook.) W. A. Weber in Phytologia 55: 6. 1984 -> Askellia elegans (Hook.) W. A. Weber in Phytologia 55: 6. 1984 + ISBN 1-23-456-78 and article title "The beauty of being Askellia"
Askellia elegans (Hook.) W. A. Weber in Phytologia 55: 6. 1984 -> Askellia elegans (Hook.) W. A. Weber in Trans. Amer. Philos. Soc. 23: tab 7. 1999.
Unintended hit of key or unintended drag&drop
The four types of object changes differ in the most probable intended object change strategy.
For typos / minor corrections the most probable intended change strategy is to change the object itself because also in other contexts the corrected version of the object will be the preferred one.
For representation changes it depends on further conditions what the preferred strategy is.
a. In a single-user environment or an environment that agrees on sharing the same objects and the same representation for an object the most probable intended change strategy is to keep the object and save it updated.
b. In an environment that shares objects but may want to use different representations for objects (due to personal preferences or due to some other demands, e.g. the need to show historical representations) the most probable intended change strategy is to create a new object / find a matching object
For changing the object itself the most probable intended change strategy is to create a new object / find a matching object.
For unintended changes the most probable intended change strategy is to create a new object (to reduce the damage to a minimum)
Unfortunately we often do not know if a change is intended to be a change of type 1, 2, 3 or 4. However there are different ways to guess what type was intended. You may guess via
compare functions like Levenshtein distance or others
the way how the user entered the change
... in work ...
Object change stragies may have two extremes. The first resulting in almost no new objects when you change any data. The second resulting in only new objects with even objects created new because they relate to a changed object, e.g. a TaxonName may be created new because its nomenclatural reference has been changed.
In the following these two strategies are described and some rules are extracted.
The objects we talk about are:
taxon
taxon name
all author teams
all author team members
nomenclatural reference
nomeclatural inreference
nomenclatural status (set)
name relationships (set)
type designations
(homotypical groups)
| taxon
taxon name
all author teams
all author team members
nomenclatural reference
nomeclatural inreference
nomenclatural status (set)
name relationships (set)
type designations
(homotypical groups)
Strategy 1: Do not create any new objects: all objects will be changed and saved, no new objects are created if not necessary¶
Updated by Katja Luther over 2 years ago · 19 revisions