| At line 5 added 2 lines. |
| + → access the very similar (slightly less polished) MSWord document here: [TaxToolsOverview.doc] |
| + ---- |
| Line 9 was replaced by line 11 |
| - 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. |
| At line 31 added 92 lines. |
| + * __SBA Feb comment: need to pay attention to how well concepts are defined__ |
| + |
| + |
| + |
| + !! 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. |
| + |
| + |
| + |
| + !! IV. Multi-Classification Visualization Tool |
| + * __Potential users:__ As with Tool III; and ecologists and taxonomists who wish to compare alternative perspectives. |
| + * __Functionality:__ Represents ''visually'' the parent/child (vertical) relationships among concepts within one or more hierarchical classifications; as well as the (lateral) set-theory relations among concepts contained in alternative classifications. |
| + * __Use Cases:__ Use Case 7: ''display concept connections dynamically individual concept lineages;'' and Use Case 8: ''display concept connections dynamically partial or entire classifications.'' |
| + * __Integration:__ Integrates with Tool III. |
| + * __Design needs:__ We should refer to Martin Graham's work and expertise here. |
| + * __Further details:__ See [http://www.dcs.napier.ac.uk/~marting/] |
| + * __Priority/development:__ Relatively low ''only'' in the sense that MG has already created a Tool that works, e.g. with the moss concepts; pending resources we can expect the Tool to evolve and support the TCS structure; integration with Tool III is needed, though. |
| + |
| + |
| + |
| + !! V. Concept/Relationship/Status Creation Tool |
| + * __Potential users:__ Ecologists engaged in the mark-up process who realize that their concept is not adequately represented in the SEEK Taxon environment; taxonomists and aggregators contributing old or new concepts, relationships, and status assignments. |
| + * __Functionality:__ Allows users to enter information concerning concepts, their relationships, and their statuses in an interactive manner. (RKP comment: this is ''not'' the Tool for dealing with unusual concepts used by field ecologists and which lack taxonomic standing, → see Tool VIII) This should include both a basic functionality where concepts and concept relationships are entered from a simple set of forms, but with advanced visualization tools for more sophisticated applications. |
| + * __Use Cases:__ Use Case 1: ''assign status to concept;'' Use Case 11: ''acquire existing concept (manually);'' Use Case 12: ''acquire existing synonymy or parent/child connection (manually);'' Use Case 13: ''acquire new concept from expert;'' and Use Case 14: ''acquire new synonymy or parent/child connection from expert.'' |
| + * __Integration:__ Close integration with Tools III and IV, once information has been entered → passing-on to Tools VI and VII. |
| + * __Design needs:__ Xianhua's TCBE is approaching some of the needs, see also Nico's comments at [http://seek.ecoinformatics.org/Wiki.jsp?page=NicoImplementationThoughts] |
| + * __Further details:__ Potentially this will be a sophisticated tool. It needs to support both the structure of the TCS (see Tool III) and have the ability to represent at least two classifications and relationships among their concepts visually, so that experts can "see" what concepts they are connecting to each other. However, as with Tool III the development can be staged with the simple functionality added first and the visualization component added later as time and resources permit. Also, we need to incorporate a mechanisms by which work in progress is ''not'' published (integrated into the public side fo TOS) ''until'' a project is completed. This could be accomplished by storing the work in progress on TOS and flagging it as private, or by keeping the work in progress on a desktoi client and only porting to TOS when the project is complete. |
| + * __Priority/development:__ High priority for basic functionality and lower priority for the visualization process; similar to Tool III. |
| + |
| + |
| + |
| + !! 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). |
| + |
| + |
| + |
| + !! 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. |
| + * __Gathering the information necessary for the mark-up occurs by interacting with the TOS, but storing the information will happen in Morpho/EcoGRID__ |
| + |
| + !! IX. Concept Merge Tool |
| + * __Potential users:__ Ecologists who are conducting meta-analyses. |
| + * __Functionality:__ Merges concepts that are similar so that ecological information can be pooled this is actually the main functionality that ecologists need: what do the names mean?, and is it admissible to pool the information pertaining to multiple names/concepts? |
| + * __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! |
| + |
| + |
| + |
| + !! X. Map-to-TCS Tool |
| + * __Potential users:__ Taxonomic concepts providers who understand and wish to document the relations of objects in their preferred database to those represented in the TCS. |
| + * __Functionality:__ Assists in understanding the object relationships ("what are concepts?", etc.) according to different database structures. |
| + * __Use Cases:__ None specifically (but see below). |
| + * __Integration:__ Not clear, is sufficiently independent at this point. |
| + * __Design needs:__ → Trevor Paterson, MapForce
|
| + * __Further details:__ See above; also: this Tool could eventually plug-in to Tool II. |
| + * __Priority/development:__ Is in a sense already underway at Napier, the work started when Jessie and Robert tried to understand how other databases represent concepts; now this Tool would assist in storing and visualizing that information. |
| + |
| + ---- |
| + |
| + ! Next Steps |
| At line 32 added 4 lines. |
| + * Post a Wiki version + a Word document, and advertise to SEEK Taxon. |
| + * Franz, Liu, and Peet will continue scoping Tools II, III and V; starting with Tool III in particular. |
| + |
| + ---- |
| Lines 34-118 were replaced by line 132 |
| - 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. |
| - |
| - |
| - IV. Multi-Classification Visualization Tool |
| - Potential users: As with Tool III; and ecologists and taxonomists who wish to compare alternative perspectives. |
| - Functionality: Represents visually the parent/child (vertical) relationships among concepts within one or more hierarchical classifications; as well as the (lateral) set-theory relations among concepts contained in alternative classications. |
| - Use Cases: Use Case 7: display concept connections dynamically individual concept lineages; and Use Case 8: display concept connections dynamically partial or entire classifications. |
| - Integration: Integrates with Tool III. |
| - Design needs: We should refer to Martin Graham's work and expertise here. |
| - Further details: Wee http://www.dcs.napier.ac.uk/~marting/ |
| - Priority/development: Relatively low only in the sense that MG has already created a Tool that works, e.g. with the moss concepts; pending resources we can expect the Tool to evolve and support the TCS structure; integration with Tool III is needed, though. |
| - |
| - |
| - V. Concept/Relationship/Status Creation Tool |
| - Potential users: Ecologists engaged in the mark-up process who realize that their concept is not adequately represented in the SEEK Taxon environment; taxonomists and aggregators contributing old or new concepts, relationships, and status assignments. |
| - Functionality: Allows users to enter information concerning concepts, their relationships, and their statuses in an interactive manner. (This is NOT the Tool for dealing with unusual concepts used by field ecologists and which lack taxonomic standing -- see Tool VIII) This should include both a basic functionality where concepts and concept relationships are entered from a simple set of forms, but with advanced visualization tools for more sophisticated applications. |
| - Use Cases: Use Case 1: assign status to concept; Use Case 11: acquire existing concept (manually); Use Case 12: acquire existing synonymy or parent/child connection (manually); Use Case 13: acquire new concept from expert; and Use Case 14: acquire new synonymy or parent/child connection from expert. |
| - Integration: Close integration with Tools III and IV, once information has been entered → passing-on to Tools VI and VII. |
| - Design needs: Xianhua's TCBE is approaching some of the needs, see also Nico's comments at http://seek.ecoinformatics.org/Wiki.jsp?page=NicoImplementationThoughts |
| - Further details: Potentially this will be a sophisticated tool. It needs to support both the structure of the TCS (see Tool III) and have the ability to represent at least two classifications and relationships among their concepts visually, so that experts can "see" what concepts they are connecting to each other. However, as with Tool III the development can be staged with the simple functionality added first and the visualization component added later as time and resources permit. Also, we need to incorporate a mechanisms by which work in progress is not published (integrated into the public side fo TOS) until a project is completed. This could be accomplished by storing the work in progress on TOS and flagging it as private, or by keeping the work in progress on a desktoip client and only porting to TOS when the project is complete. |
| - Priority/development: High priority for basic functionality and lower priority for the visualization process; similar to Tool III. |
| - |
| - |
| - 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. |
| - |
| - |
| - IX. Concept Merge Tool |
| - Potential users: Ecologists who are conducting meta-analyses. |
| - Functionality: Merges concepts that are similar so that t ecological information can be pooled this is actually the main functionality that ecologists need: what do the names mean, and is it admissible to pool the information pertaining to multiple names/concepts. |
| - 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! |
| - |
| - |
| - X. Map-to-TCS Tool |
| - Potential users: Taxonomic concepts providers who understand and wish to document the relations of objects in their preferred database to those represented in the TCS. |
| - Functionality: Assists in understanding the object relationships (what are concepts?, etc.) according to different database structures. |
| - Use Cases: None specifically. |
| - Integration: Not clear, is sufficiently independent at this point. |
| - Design needs: → Trevor Paterson, MapForce
|
| - Further details: See above; also this Tool could eventually plug-in to Tool II. |
| - Priority/development: Is in a sense already underway at Napier, the work started when Jessie and Robert tried to understand how other databases represent concepts; now this Tool would assist in storing and visualization that information. |
| - |
| - |
| - Next steps. |
| - |
| - 1. Post a Wiki version + a Word document, and advertise to SEEK Taxon |
| - 2. Franz, Liu, and Peet will continue scoping Tools II, III and V; starting with Tool III in particular. |
| - |
| + * SBA February Taxon meeting: Susan Gauch suggests creation of additional tool, similar to the DOI system. The idea is that once someone finds a GUID in an (on-line) article, there is a service that will guide that person to the original concept definition. __Susan will fill in the details!__ |
