| Lines 48-53 were replaced by lines 48-53 |
| - • 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: 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. |
| + * __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. |
| Lines 58-64 were replaced by lines 58-64 |
| - • 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. |
| + * __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. |
| Line 66 was replaced by line 66 |
| - ---- |
| + |
