| At line 0 added 40 lines. |
| + !!! Use Case 14: ''Acquire New Synonymy Or Parent/Child Connection From Expert'' |
| + |
| + !! Actors |
| + ; Primary Actor : a taxonomist or any individual with "permission" to newly ''create'' connections among same-level or hierarchically nested concepts, stored in the SEEK Taxon database, for later access by other users. |
| + |
| + !! Description |
| + This Use Case covers the situations where "experts" newly establish connections - credited to them - among multiple concepts (sets of concepts pairs) stored in the SEEK Taxon database. Prior to the interaction, these connections existed nowhere else, possibly because the traditional literature only addressed ''name'' synonymies or connections among parent/child ''names''. The only alternative to connecting these entries is probabilistically. |
| + |
| + !! Flow of Events |
| + |
| + ! Pre-conditions |
| + * Various "independent" taxonomic concepts orginating from multiple (unconnected) sources are stored in the SEEK Taxon database. The "expert" has passed the required steps with SEEK to author and contribute new connections among them. |
| + |
| + ! Basic Flow |
| + # The "expert" views an interface that makes it possible to view short-hands (and/or perhaps GUIDs) of a ''pair'' of taxonomic concepts, say (1) "name 1 sec. author A, GUID 123", and (2) "name 2 sec. author B, GUID 456". |
| + # In addition to the pair of concepts, the interface displays a set of fields that allow the expert to specify the kind of connection among them, and associate that connection with the with expert's name, and the reference "SEEK Taxon database (year, version, etc.)". |
| + # The expert now establishes a new connection among the pair of concepts, either a (lateral) synonymy connection or a (vertical) parent/child connection (see Use Case on transferring existing connections). |
| + # The author may add specific comments to the connection. |
| + # The transferred information is stored in the SEEK Taxon database, sitting "on top of" the core concept information. |
| + |
| + ! Examples |
| + # An ecologist, having entered all 10 concepts of "''Carya'' sec. Chapman 1883, Flora Southern US 3rd Edition 1883", now collaborates with an "expert" (say, a USDA Plant specialist) to newly connect them to those present in the latest version of the USDA Plant List. |
| + |
| + !! Post-conditions |
| + See comments on "Non-functional requirements". |
| + |
| + ! Alternative Flows |
| + * "Expert" connections among concepts exist already, or are calculated probabilistically. |
| + |
| + !! Further Details |
| + "Expert" connections are ultimately more desirable than probabilistic ones. Incentives are necessary to have "experts" participate in this process. |
| + |
| + ! Non-functional Requirements |
| + In the "concept world", often parent concepts are defined ''exclusively'' through their connections to child concepts. While it is possible to connect concepts "laterally" without creating new concepts (just new connections), changes in the vertical connections may - in some cases - require the (ad hoc) creation of new parent concepts. Two examples illustrate the problem. (1) If two (child) species concepts of "''Carya''" are newly synonymized, is a new (parent) concept of "Juglandaceae" created? The intuitive answer is "no". (2) If an author "reconnects" a (child) species concept previously placed by another author in the parent concept "''Carya'' (sec. ...)" to a different parent concept "''Juglans'' (sec. ...)", does this require the creation of a new concept for "''Carya''" - now explicitly excluding the child concept previously assigned to "''Carya''"? Here the answer may be "yes". It may be necessary to have some rules as to when new lateral vs. vertical connections among concepts require the creation of new concepts at higher levels. |
| + |
| + ! Issues |
| + See above. |
| + |
| + !! History |
| + ; 29 March 2004 : (NMF) Use Case created (somehow) from previous Word document. |
