[seek-dev] update on TOS Kepler actors

[Matt Jones]

Hi Rob,

Thanks for the summary.  We agreed on the approach of using simpleTypes,
and I still think that is the best approach, so no changes there.  Could
you send seek-dev a configured workflow that exercises all of the TOS
functions via the web services actor?  That way Dan and I can see it in
action using Kepler.  I'll probabaly check it in so Dan can see how to
use it within the ENM workflow.  Thanks.

I mostly agreed with the ENM workflow you described below, but I think
there is a critical modification that I think you missed.  We need to
make sure name strings are not used multiply among different concepts,
i.e. each name is assigned to only one concept.  Procedurally, once we
have the list of accepted species-concepts from TOS, we get the list of
synonym names that have been used for that concept.  Then for each
synonym name, we see what the most likely concept is for that name, then
assign it to that (and only that) concept.  Then you move onto querying
DiGIR for each concept using the associated set of names we've established.

This addition is important to make sure that we are not re-using
collection records in multiple species runs of the ENM.

Thanks.
Matt

Robert Gales wrote:
> Hi Matt,
> 
> After our phone discussion, I thought we had agreed that the best route
> would be for Taxon was to modify (or add to) our SOAP API such that
> simple types and arrays of simple types could be used to take advantage
> of the web services actor.  So after the phone call, I did exactly that,
> adding any methods that the niche modelling case would require so that
> they act on only simple types.  During that time, I also completely
> isolated the SOAP layer from the business logic, which has been a
> maintenance pain for quite some time.
> 
> I ran quite a number of tests with the web service actor to become
> familiar with, and ensure that everything we needed was working
> correctly.  I found a few bugs in the handling of arrays which I fixed
> and sent a patch to Ilkay, who forwarded it to Nandita.  There is still
> one noticeable problem I found recently with it dealing with in/out
> parameters, basically because it assigns the ports the same name, which
> causes a failure because multiple ports with the same name are not
> allowed in Kepler/Ptolemy.
> 
> As of now, we have all but one of the necessary API methods implemented,
> some of which (getAuthoritativeList in particular) required some changes
> in the database/hibernate model.  The one that is still under
> investigation is get best concept from a name.  Currently Aimee's
> working on a dictionary system to handle and match mispellings to the
> most appropriate concepts, once it has been completed, the remainder of
> the implementation should be trivial.  This is the key API method
> however, because it will be the entry point into the TOS for the niche
> modeling case.
> 
> The workflow for the TOS portion of the niche modeling use case as I
> understood it from Estes Park looks like the following:
> 
> get the best concept according to ITIS for Mammalia (TOS responsibility)
>   * returns the guid of the Mammalia concept from ITIS
> 
> given the returned guid, get the authoritative list at the level of
> species from the subtree rooted at the guid and within ITIS'
> classification (TOS responsibility)
>   * returns a list of the guids of the species that are descendants
>     of Mammalia according to ITIS
> 
> using the array actors in kepler, iterate through the list, calling
> get synonymous names with each guid (TOS responsibility)
>   * returns a list of all names that TOS knows about that have been
>     associated with that guid, this includes the names pulled from
>     MaNIS
> 
> use those names to create the DiGIR query
> 
> All of those methods have been implemented such that they take simple
> types and return one or more simple types or arrays of simple types in
> order to work with the web services actor.
> 
> This is what I understood needed to be done from the Estes Park meeting
> and our phone call.  If since then, something has changed that require
> custom TOS actors that use our complicated object model then I'll
> redirect my code cleanup/maintenance enhancing/testing efforts back
> towards the Kepler actor issue.
> 
> - Rob
> 
> Matt Jones wrote:
> 
>> Hi Rob,
>>
>> I was wondering what the status is on this project.  Have you started
>> work on the Kepler actors?  If not, has something been getting in the
>> way in the TOS work?  Thanks for the info.
>>
>> Matt
>>
> 

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------