| Line 5 was replaced by lines 5-17 |
| - Possible collaboration point: reasoning over functional attribute database |
| + !Misc Thoughts/Facts |
| + * How associate growing body of functional/trait attributes with taxonomic information? |
| + ** Associate with GUIDs, names, other concept attributes? or associate dynamically? |
| + ** __Possible collaboration point: reasoning over functional attribute database__ |
| + * Semantic mediator will call TOS (Taxonomic Object Service) |
| + * For a more automated workflow approach - maybe associate taxonType[] as output port for dataset actor and input port for analysis actor |
| + * Weighted output from TCS is an issue—how use in Kepler? |
| + * Current TOS demo/SOAP service is not working because it is being upgraded. This should be up again soon. Even simple service will help identify issues to be addressed. |
| + * Split or lump to common resolution |
| + ** must define resolutions |
| + ** rank vs set operations |
| + ** original concepts vs third party relationship assertions |
| + * __Is the meeting in Estes Park necessary?__ |
| Line 7 was replaced by lines 19-20 |
| - Semantic mediator will call TOS |
| + !SMS focusing on following scenario: |
| + SMS WILL construct for a given (number of) dataset(s) the best set of information (limited/query concepts; as “complete a filled-in concept as possible”)) to feed to the TCS (binomial, year, location, e.g.)—and a specification of the grain to which you want these resolved (default to finest grain?). TCS then returns (a potentially integrated or presentation of possible integration options) of these two lists of concepts. Aimee says that Taxon is aware of this, but hasn't gotten to it yet, as it is the hardest/most complex function (and builds on the others). |
| Removed lines 9-17 |
| - EML |
| - * Maintain GUIDs in metadata or resolve dynamically |
| - ** Could bind resolution if done by original data collector/author |
| - ** Third party resolution results could improve over time until TOS cache is somewhat stable. |
| - ** Who is responsible for the association if not maintained in EML? |
| - |
| - SMS focusing on following scenario: |
| - SMS WILL construct for a given (number of) dataset(s) the best set of information (limited/query concepts; as “complete a filled-in concept as possible”)) to feed to the TCS (binomial, year, location, e.g.)—and a specification of the grain to which you want these resolved (default to finest grain?). TCS then returns (a potentially integrated or presentation of possible integration options) of these two lists of concepts. Aimee says that Taxon is aware of this, but hasn't gotten to it yet, as it is the hardest/most complex function (and builds on the others). |
| - |
| Line 20 was replaced by line 24 |
| - * Resolve names for each list |
| + * Resolve names for each li* st |
| Lines 28-30 were replaced by lines 32-37 |
| - |
| - |
| - For a more automated workflow approach - maybe associate taxonType[] as output port for dataset actor and input port for analysis actor |
| + !Relation with EML Taxonomic coverage |
| + * how capture results, esp if these required human intervention |
| + * is TCS resolution going to be associated with EML as semantic annotation or resolve dynamically? |
| + ** Could bind resolution if done by original data collector/author |
| + ** Third party resolution results could improve over time until TOS cache is somewhat stable. |
| + ** Who is responsible for the association if not maintained in EML? |
| Line 32 was replaced by line 39 |
| - Additions/Modifications to TOS: |
| + !Additions/Modifications to TOS: |
| Removed line 47 |
| - * Relation with EML Taxonomic coverage: if binomial, and launch TCS search, how capture results, especially if these required human intervention; is TCS resolution going to be associated with EML as semantic annotation. |
| Line 49 was replaced by line 55 |
| - SMS tasks: |
| + !SMS tasks: |
