At line 0 added 39 lines. |
+ !!! Use Case 11: ''Acquire Existing Concept (Manually)'' |
+ |
+ !! Actors |
+ ; Primary Actor : a taxonomist or any individual with "permission" to transfer taxonomic concept information from an unconnected source (not a SEEK Taxon-compatible provider) into the SEEK Taxon database, for later access by other users. |
+ |
+ !! Description |
+ The condition of this particular Use Case - relevant for proper crediting - is that the concepts ''newly transferred'' into the SEEK Taxon database nevertheless already existed ''somewhere else'', e.g. in a taxonomic publication. The author/contributor distinction is important here. The manual transfer of existing synonymy and parent/child connections, as well as the transfer of (existing or new) status assignments, are addressed in other Use Cases. This means that the transfer of "core concepts" (...) can occur in isolation (then SEEK will have to do all the concept-matching probabilistically), ''or'' in conjunction with the (simultaneous) transfer of individually authored connections and statuses. |
+ |
+ !! Flow of Events |
+ |
+ ! Pre-conditions |
+ * A database structure that can manage the various independent transfers and updates through time; possibly the initial population with an appropriate taxonomic range of concepts (to enable probabilistic concept-matching). |
+ |
+ ! Basic Flow |
+ # The Primary Actor "organizes" the transfer interaction with SEEK. This involves resolving issues about who authored and who contributes the information to be transferred (credit), and who has permission to access and edit it (peer review). It also includes a taxonomic "metadata" summary of the taxonomic scope, quantity, and quality (content) of transferred information. |
+ # Once the Primary Actor has passed the organizational steps, an interface is available to initiate the actual, manual transfer process. This interface makes (occasional) use of ''queries'' for information already stored in the SEEK Taxon database, to assist in the transfer process and to avoid multiple entries of the same information. For example, although certain new manual entries (e.g. "rank" or "year") should be entered without immediate checking, it is possible that the contributor transfers concepts from a comprehensive reference source that is already stored in the SEEK Taxon database (say, a coherent series of monographic treatments in a large volume). Checking this reference as the correct one ("yes, that's it", etc.) can speed up to entry process and stabilize the reference database. On the other hand, if both the name and reference entries are (sufficiently) identical to previously stored information, then the SEEK Taxon database needs to notify the contributor. So other (query) Use Cases ("check for synonymous concepts) are part of this Use Case. |
+ # Having entered the core concept information (including SEEK's confirmation that it is ''new'' to SEEK), the contributor is now asked to (1) contribute manual connections to existing synonymous and parent/child concepts, which may either already be stored in the SEEK Taxon database, or be a part of the set of concepts currently transferred. The contributor can also (2) enter a status assignment. Each of these additional steps are treated in separated Use Cases, even though they may be part of the same entry session. |
+ |
+ ! Examples |
+ # An ecologist enters the core concept information (name, reference, year, diagnosis, etc.) of "''Carya amara'' Nuttall" from the Flora Southern US 3rd Edition by Chapman, 1883 ("sec. Chapman, 1883"), into the SEEK Taxon database, since she has used this reference (rather than one that SEEK already stores) in her studies. |
+ # A taxonomist has recent published a new species of weevil "''Staminodeus vectoris'' Franz, 2001", and now enters the relevant information into the SEEK Taxon database ("sec. Franz, 2001"). |
+ |
+ !! Post-conditions |
+ An effective way to assist the contributor in connecting the just entered concept to similar ones, so that as many "expert" connections as possible are made at this point. |
+ |
+ ! Alternative Flows |
+ * See comments in "Issues". |
+ |
+ !! Further Details |
+ As in the automated transfer Use Case, there is a (variable) connection of the core transfer schema - now made accessible to users through an entry interface - and other transfer schemas (e.g. status) that may or may not be called upon at the same time. In Example 1. above, the concept author Chapman omitted synonymous names, which also means that the status of each concept - sec. Chapman, 1883 - is "valid". |
+ |
+ ! Non-functional Requirements |
+ A (prototype) system for consistently and permanently making transparent the author/contributor distinction when it comes to entering and connecting concepts, and assigning statuses to them. |
+ |
+ ! Issues |
+ Will SEEK permit the entry of synonymous ''names'' and parent/child ''names'', instead of synonymous concepts and parent/child concepts as envisioned here? |
+ |
+ !! History |
+ ; 27 March 2004 : (NMF) Use Case created from previous Word document. |