| Line 9 was replaced by line 9 |
| - Each Tool should ultimately have its own scoping document, specifying the user requirements and technical demands (including assessment of any need for refinement of the TOS APIs). Our goal is to prepare all these documents for group discussion, refinement, and prioritization at the SEEK Taxon meeting of February 15-17, 2005. We anticipate considerable interaction with members of SEEK Taxon during the development of the scoping documents prior to the meeting. |
| + __Each Tool__ should ultimately have its own scoping document, specifying the user requirements and technical demands (including assessment of any need for refinement of the TOS APIs). Our goal is to prepare all these documents for group discussion, refinement, and prioritization at the SEEK Taxon meeting of February 15-17, 2005. We anticipate considerable interaction with members of SEEK Taxon during the development of the scoping documents prior to the meeting. |
| Removed lines 34-41 |
| - III. Concept/Relationship/Status Exploration Tool |
| - Potential users: Ecologists engaged in marking up their names with concepts and taxonomists exploring the concept holdings of the TOS. |
| - Functionality: Users should be able to determine whether a particular concept or view is represented in SEEK or whether it needs to be added. If it is present, they will want to know how to reference it (obtain its GUID). The Tool should allow users to query concepts by entering a name (simple query) or any other information tied to concepts (advanced query) and receive back a list of candidates, with some flexibility as to how widely the net is cast for candidates. Options should include ability to select preferred views and dates, ability to view parents and children. Once a concept is identified, the user should be able to identify related concepts via various filters. |
| - Use Cases: Use Case 3: select preferred view on concepts; Use Case 4: display concepts associated with names (isolated, statically); Use Case 5: display connections to synonymous concepts (statically); Use Case 6: display connections to parent or child concepts (statically); Use Case 9: display concepts associated with information (references, specimens, etc.) other than names (alternative query); and Use Case 10: display information (references, specimens, etc.) associated with concepts (reverse query). |
| - Integration: See Potential users above the Tool is part of the mark-up process for ecologists; and assists taxonomists in exploring concepts; can interact with the Multi-Classification Visualization Tool. |
| - Design needs: Can represent the structure of the TCS; should be based on text boxes and tables, not fancy visual displays. |
| - Further details: various similar tools (Euro+Med, etc.) already exists - potential design lessons. |
| - Priority/development: High priority; a lot of Use Cases are represented here; and a lot of workflows depend on this Tool. Because of the range of functionality required, we anticipate that the tool will be built in stages with functionality added incrementally. |
| At line 42 added 8 lines. |
| + !! III. Concept/Relationship/Status Exploration Tool |
| + * __Potential users:__ Ecologists engaged in marking up their names with concepts and taxonomists exploring the concept holdings of the TOS. |
| + * __Functionality:__ Users should be able to determine whether a particular concept or view is represented in SEEK or whether it needs to be added. If it is present, they will want to know how to reference it (obtain its GUID). The Tool should allow users to query concepts by entering a name (simple query) or any other information tied to concepts (advanced query) and receive back a list of candidates, with some flexibility as to how widely the net is cast for candidates. Options should include ability to select preferred views and dates, ability to view parents and children. Once a concept is identified, the user should be able to identify related concepts via various filters. |
| + * __Use Cases:__ Use Case 3: ''select preferred view on concepts;'' Use Case 4: ''display concepts associated with names (isolated, statically);'' Use Case 5: ''display connections to synonymous concepts (statically);'' Use Case 6: ''display connections to parent or child concepts (statically);'' Use Case 9: ''display concepts associated with information (references, specimens, etc.) other than names (alternative query);'' and Use Case 10: ''display information (references, specimens, etc.) associated with concepts (reverse query).'' |
| + * __Integration:__ See Potential users above the Tool is part of the mark-up process for ecologists; and assists taxonomists in exploring concepts; can interact with the Multi-Classification Visualization Tool. |
| + * __Design needs:__ Can represent the structure of the TCS; should be based on text boxes and tables, not fancy visual displays. |
| + * __Further details:__ various similar tools (Euro+Med, etc.) already exists - potential design lessons. |
| + * __Priority/development:__ High priority; a lot of Use Cases are represented here; and a lot of workflows depend on this Tool. Because of the range of functionality required, we anticipate that the Tool will be built in stages with functionality added incrementally. |
| Lines 44-45 were replaced by lines 44-47 |
| - IV. Multi-Classification Visualization Tool |
| - Potential users: As with Tool III; and ecologists and taxonomists who wish to compare alternative perspectives. |
| + |
| + |
| + !! IV. Multi-Classification Visualization Tool |
| + * __Potential users:__ As with Tool III; and ecologists and taxonomists who wish to compare alternative perspectives. |
| Line 54 was replaced by lines 56-57 |
| - V. Concept/Relationship/Status Creation Tool |
| + |
| + !! V. Concept/Relationship/Status Creation Tool |
| At line 62 added 23 lines. |
| + ---- |
| + |
| + !! VI. Taxonomic Peer-Review Tool |
| + * __Potential users:__ Taxonomists, other authorities who can review the merits of actions performed in Tool V. |
| + * __Functionality:__ ''Any user'' can add concepts and relationships via Tool V. However, as concepts and relationships proliferate, sets of preferred views will be needed. Given the magnitude of the job, the greater taxonomic community will need to be involved. We should provide the ability for authority groups to become stewards of specific sets of taxa. Newly proposed concepts and relationships would be sent to these joint authorities for peer review and eventual inclusion in the perspective and maintained in the TOS. With this process in place, the naοve user will have the option to select from one of a few authoritative perspectives. This approach is modeled after the CI project of Crispin Wilson and might be viewed as closely related to an ITIS model with peer review. By empowering taxonomists to provide authoritative perspectives, the Tool will encourage greater participation. |
| + * __Use Cases:__ None specifically, though see Tool V. |
| + * __Integration:__ Is an "export option" in Tool V; once new information has been entered, it goes out for reviewfor possible incorporation as a preferred perspective. |
| + * __Design needs:__ See Xianhua's efforts; also IPNI, various others on-line peer-review projects. |
| + * __Further details:__ See Tool VII. |
| + * __Priority/development:__ We can build on a related Tool already under development for submitted plant communities, so it should be easily completed for linkage to Tool V. |
| + |
| + |
| + |
| + !! VII. GUID Request and Assignment Tool |
| + * __Potential users:__ "Authorities" this is done by whoever is allowed to issue GUIDs to taxonomic concept information. |
| + * __Functionality:__ Anytime someone has made it through Tool II or V and submitted one or more, concepts, names, references, relationships, etc. for inclusion in the TOS, GUIDs need to be obtained. The GUID request Tool could be a plug-in to Tools II and V, or it could be integral to the workings of the TOS and therefore unnecessary as a stand-alone Tool. It is unclear whether we want a GUID creation Tool for concepts and relationships etc. that are not submitted to the TOS. |
| + * __Use Cases:__ Use Case 15: ''assign GUID to taxonomic concept information (provisional).'' |
| + * __Integration:__ Assign GUIDs to concepts and relationships entered through Tools II and V. |
| + * __Design needs:__ See Dave Thau's prototype GUID server at [http://www-124.ibm.com/developerworks/downloads/detail.php?group_id=124&what=rele&id=725] |
| + * __Further details:__ None yet. |
| + * __Priority/development:__ Already under development (see above). |
| + |
| + |
| Lines 64-92 were replaced by lines 90-97 |
| - VI. Taxonomic Peer-Review Tool |
| - Potential users: Taxonomists, other authorities who can review the merits of actions performed in Tool V. |
| - Functionality: Any user can add concepts and relationships via Tool V. However, as concepts and relationships proliferate, sets of preferred views will be needed. Given the magnitude of the job, the greater taxonomic community will need to be involved. We should provide the ability for authority groups to become established around specific sets of taxa. Newly proposed concepts and relationships would be sent to these joint authorities for peer review and eventual inclusion in the perspective and maintained in the TOS. With this process in place, the naοve user will have the option to select from one of a few authoritative perspectives. This perspective is modeled after the CI project of Crispin Wilson and might be viewed as closely related to an ITIS model with peer review. By empowering taxonomists to provide authoritative perspectives, the Tool will encourage might greater participation. |
| - Use Cases: None specifically, though see Tool V. |
| - Integration: Is an "export option" in Tool V; once new information has been entered, it goes out for reviewfor possible incorporation as a preferred perspective. |
| - Design needs: See Xianhua's efforts; also IPNI, various others on-line peer-review projects. |
| - Further details: See Tool VII. |
| - Priority/development: We can build on a related tool already under development for submitted plant communities, so it should be easily completed for linkage to Tool V. |
| - |
| - |
| - VII. GUID request and assignment Tool |
| - Potential users: "Authorities" this is done by whoever is allowed to issue GUIDs to taxonomic concept information |
| - Functionality: Anytime someone has made it through Tool II or V and submitted one or more,concepts, names, references, relationships, etc. for inclusion in the TOS, GUIDs need to be obtained The GUID request tool could be a plug-in to tools II and V, or it could be integral to the workings of the TOS and therefore unnecessary as a stand-along tool. It is unclear whether we want a GUID creation tool for concepts and relationships etc. that are not submitted to the TOS.) |
| - Use Cases: Use Case 15: assign GUID to taxonomic concept information (provisional). |
| - |
| - Integration: Assign GUIDs to concepts and relationships entered through Tools II and V. |
| - Design needs: See Dave Thau's prototype GUID server at http://www-124.ibm.com/developerworks/downloads/detail.php?group_id=124&what=rele&id=725 |
| - Further details: None yet. |
| - Priority/development: Already under development (see above). |
| - |
| - |
| - VIII. Concept Mark-Up Tool |
| - Potential users: Ecologists using EML, submitting datasets with formal or informal taxonomic names. |
| - Functionality: Assists ecologists to move from names in their datasets to concepts referenced in EML. Some close affinities with Tool III, perhaps applied in batch mode. For each name in a dataset (names with or without a reference) candidate concepts would be provided following a preferred perspective, and those names with issues of resolution would be flagged. This Tool must also provide functionality for documenting a field ecologist's concepts that lack taxonomic standing by describing them and linking them to established concepts that reside on the TOS. |
| - Use Cases: See Tool III. |
| - Integration: Needs to initiate as part of EML, possibly Kepler; at this point the Concept Introduction Manual (Tool I) comes into play as well; ecologists have two core choices: (1) automated mark-up, and (2) manual mark-up; for choice (1) they can select one or few preferred reference taxonomies (such as FNA) in which to search for concepts matching the names contained in their datasets; they can also interactively specify certain algorithmic preferences to perform the name/concept match; once this is done the SEEK Taxon service automatically could match the names to concepts and fill in a short-hand annotation of the best-matching concept in EML; for choice (2), the ecologist has access to Tools III and IV and, if necessary, to Tool V (add concepts/relationships, etc.), in case no stored concept in the SEEK Taxon database matches his/her concept in the dataset; once the exploration/creation phase is over and a suitable concept has been located or newly entered, then ecologist must again paste a short-hand annotation of it into EML. |
| - Design needs: Basically a hub between EML/Kepler and the SEEK Taxon service; must support Tool I and assist in choosing automated vs. manual name-to-concept resolution. |
| - Further details: None yet. |
| - Priority/development: High priority, although there is need to have Tools III, and preferably also V in place before this tool can be applied; in the meantime, the taxonomic/voucher section of EML might need expansion/revision for compatibility with the TCS. |
| + !! VIII. Concept Mark-Up Tool |
| + * __Potential users:__ Ecologists using EML, submitting datasets with formal or informal taxonomic names. |
| + * __Functionality:__ Assists ecologists to move from names in their datasets to concepts referenced in EML. Some close affinities with Tool III, perhaps applied in batch mode. For each name in a dataset (names with or without a reference) candidate concepts would be provided following a preferred perspective, and those names with issues of resolution would be flagged. This Tool must also provide functionality for documenting a field ecologist's concepts that lack taxonomic standing by describing them and linking them to established concepts that reside on the TOS. |
| + * __Use Cases:__ See Tool III. |
| + * __Integration:__ Needs to initiate as part of EML, possibly Kepler; at this point the Concept Introduction Manual (Tool I) comes into play as well; ecologists have two core choices: (1) automated mark-up, and (2) manual mark-up; for choice (1) they can select one or few preferred reference taxonomies (such as FNA) in which to search for concepts matching the names contained in their datasets; they can also interactively specify certain algorithmic preferences to perform the name/concept match; once this is done the SEEK Taxon service automatically could match the names to concepts and fill in a short-hand annotation of the best-matching concept in EML; for choice (2), the ecologist has access to Tools III and IV and, if necessary, to Tool V (add concepts/relationships, etc.), in case no stored concept in the SEEK Taxon database matches his/her concept in the dataset; once the exploration/creation phase is over and a suitable concept has been located or newly entered, then ecologist must again paste a short-hand annotation of it into EML. |
| + * __Design needs:__ Basically a hub between EML/Kepler and the SEEK Taxon service; must support Tool I and assist in choosing automated vs. manual name-to-concept resolution. |
| + * __Further details: None yet.__ |
| + * __Priority/development:__ High priority, although there is need to have Tools III, and preferably also V in place before this Tool can be applied; in the meantime, the taxonomic/voucher section of EML might need expansion/revision for compatibility with the TCS. |
| Lines 99-103 were replaced by lines 104-108 |
| - Use Cases: None within SEEK Taxon directly, but our Use Cases and services are needed to support this scenario. We should develop more specific Use Case scenarios here! |
| - Integration: Not sure, presumable the names contained in the many independent ecological datasets have already been marked up as concepts? This might be handled through Kepler, after all. |
| - Design needs: Ability to import sets of concepts and find matches; suggesting when the ecological information can be merged and how to merge ambiguous matches. This is a complex task commonly undertaken in meta-analysis. We need to develop a scoping document that sets out in some detail the kinds of decisions that need to be made and the information needed to support those decisions. We anticipate providing requirements in some detail to SMS/Kepler for implementation as part of other data integration tools.? |
| - Further details: Need input from ecologists here
; SEEK Taxon will design the taxon-specific workflows/integration issues, but right now we think that SMS should end up completing the Tool. |
| - Priority/development: Lower priority than Tool VIII as we need datasets before we can merge them; still, supposedly high → see Mammal Use Case! |
| + * __Use Cases:__ None within SEEK Taxon directly, but our Use Cases and services are needed to support this scenario. We should develop ''more specific'' Use Case scenarios here! |
| + * __Integration:__ Not sure!; presumably the names contained in the many independent ecological datasets have already been marked up as concepts? This might be handled through Kepler, after all. |
| + * __Design needs:__ Ability to import sets of concepts and find matches; suggesting when the ecological information can be merged and how to merge ambiguous matches. This is a complex task commonly undertaken in meta-analyses. We need to develop a scoping document that sets out in some detail the kinds of decisions that need to be made and the information needed to support those decisions. We anticipate providing requirements in some detail to SMS/Kepler for implementation as part of other data integration tools. |
| + * __Further details:__ Need input from ecologists here
; SEEK Taxon will design the taxon-specific workflows/integration issues, but right now we think that SMS should end up completing the Tool. |
| + * __Priority/development:__ Lower priority than Tool VIII as we need datasets before we can merge them; still, supposedly high → see Mammal Use Case! |
| Removed line 122 |
| - |
