[kepler-dev] Re: [seek-dev] testing Ecogrid services in Kepler!?

Matt Jones jones at nceas.ucsb.edu
Thu Oct 14 09:10:50 PDT 2004


Hi Bertram,

Bertram Ludaescher wrote:
> Matt:
> 
> Thanks for the prompt reply. This sounds very cool.
> 
> A question in the general Kepler (not SEEK only) context is this: Will
> there be alternative ways to query data sources that are not Ecogrid
> sources? Of course the purpose of the Ecogrid registry was (I remember
> well) to precisely be the "mother of grids".
Yes.  There is nothing specifically ecological about the ecogrid.  All 
it does is to use Grid Services to standardize some metadata and data 
communication services that are commonly needed.  So, anybody exposing 
data via these interfaces would immediately make their data available in 
Kepler.

> 
> Maybe we can ultimately rename Ecogrid to Datagrid or KeplerDataGrid
> something to not scare our non-eco Kepler users (hey, I'm doing this
> chemistry, geologie, astrophysics, genomics stuff -- why would I put
> it on the Ecogrid??? ;-)
Yeah, we discussed renaming it several times.  Dave Vieglais argued that 
we had lots of momentum with this name.  But I think we all agree the 
name limits our outreach opportunities a lot.  I think we should 
seriously consider renaming it.

> 
> Also could one envision (for Kepler) to have different "data tabs" or
> one data tab that can be connected to different data grids? 
> For example a native Metacat data tab, a native SRB data tab etc? 
Sounds a bit cluttered.  THe whole point of the EcoGrid interfaces is to 
make it so that clients like Kepler only need to program to one API, 
significantly reducing the burden of developing clients that work on 
multiple data networks.

> 
> The disadvantage (that the Ecogrid overcomes) is that different APIs
> would have to be implemented. But actually once in Kepler the
> difference seems to disappear.
> The advantage would be that additional functions might be available.
Maybe there would be some additional methods, but we've discussed it 
quite a bit and have a pretty extensive set of methods planned (even 
though not implemented) based onthe current feature set in SRB, Metacat, 
Xanthoria, and DiGIR.  The EcoGrid API benefitted from evaluating all of 
these systems.

> 
> Anyways, just an observation...
Thanks.

Matt

> 
> Bertram
> 
> 
> 
> 
>>>>>>"MJ" == Matt Jones <jones at nceas.ucsb.edu> writes:
> 
> MJ> 
> MJ> Hi Bertram,
> MJ> They already are being put into Kepler, but as part of the UI rather 
> MJ> than as actors.  Adding them as actors too wouldn't be a problem, but it 
> MJ> hasn't been our emphasis yet.
> MJ> 
> MJ> By selecting the 'Data' tab, typing a phrase, and hitting 'Go' you run 
> MJ> an ecogrid "query".  Dragging a resulting data object to the canvas 
> MJ> results in running an EcoGrid "get".  We have not yet exposed the 
> MJ> "authenticate" or "put" routines, but soon we will.  Bing and Jing are 
> MJ> working on getting the registry exposed in Kepler so that you can choose 
> MJ> which EcoGrid nodes are searched and accessible, but for now the nodes 
> MJ> are in a configuration file.  Eventually I'd like this interface to 
> MJ> include all of the appropriate data access systems (e.g., JDBC, etc.), 
> MJ> but for now its just EcoGrid.
> MJ> 
> MJ> Bertram Ludaescher wrote:
> 
>>>For example, sth like this:
>>>
>>>[authenticate]-->[query]-->[get]->[some_local_update]->[put]
>>>
>>>Is that a meaningful exercise? It seems in this way we could not only
>>>test and debug Ecogrid functions but also communicate to the outside
>>>world some functionality...
> 
> MJ> 
> MJ> Yep, I think that would be very meaningful.  We're close.  Of course, 
> MJ> some EcoGrid systems support all of those calls (Metacat, SRB) while 
> MJ> others only support a subset (DiGIR).  So the system needs to fail 
> MJ> gracefully for those that don't.
> MJ> 
> MJ> Matt
> MJ> -- 
> MJ> -------------------------------------------------------------------
> MJ> Matt Jones                                     jones at nceas.ucsb.edu
> MJ> http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
> MJ> National Center for Ecological Analysis and Synthesis (NCEAS)
> MJ> University of California Santa Barbara
> MJ> Interested in ecological informatics? http://www.ecoinformatics.org
> MJ> -------------------------------------------------------------------

-- 
-------------------------------------------------------------------
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
-------------------------------------------------------------------



More information about the Kepler-dev mailing list