[seek-dev] kepler quicksearch

Mon Sep 19 11:14:45 PDT 2005

Ok, I'll bite. What were you thinking of renaming the EcoGrid api to?

Let me throw in one thought. We (my lab, that is) currently make our
data available through a web service that as yet has no convenient way
of conveying through EML how to connect to it - ie, there is no handy
url scheme like
xylopia://hostname:port?id="[dataset_id]"&query_expression="[query
expression]". I could publish a WSDL for my service, but unless you can
also access the namespace for the xsd that defines what "query
expression" looks like, that does you little good. I could also use the
connectionDefinition element that already exists in EML, but I suspect
that ASU is the only place really using this and we don't particularly
like it anyway. So I'd like to suggest when renaming our api, we
consider how we can formalize some url schemes for data services so that
we can put webservice connections in the URL element of eml. 

I think this is an issue across all of LTER. Most sites currenly use
some local code to manage security and logging of data access, requiring
users to actually go to their website to use the gui interface. If we
get them to make wrappers to these services such that kepler or other
programs could access the data without using the gui, setting a standard
for a URI scheme would help set some stardards for how they write these.

Peter McCartney(peter.mccartney at asu.edu)
International Institute for Sustainability
Arizona State University
480-965-6791

> -----Original Message-----
> From: seek-dev-bounces at ecoinformatics.org 
> [mailto:seek-dev-bounces at ecoinformatics.org] On Behalf Of 
> Bertram Ludaescher
> Sent: Friday, September 16, 2005 8:31 PM
> To: Matt Jones
> Cc: seek-dev; Bertram Ludaescher
> Subject: Re: [seek-dev] kepler quicksearch
> 
> 
> 
> Matt:
> 
> You dispelled (at least in part ;-) my concerns already...
> Once I start worrying again (e.g., about the urgent need for 
> a Kepler repository (of actors and workflows in particular), 
> I'll let you know
> :-)
> 
> Bertram
> 
> Matt Jones writes:
>  > Bertram,
>  > 
>  > This is already how it works.  Quick search is configured 
> in a text 
>  > config file to set the fields that are searched from 
> multiple metadata 
>  > standards.  I'm simply asking Jing to add to this default 
> set of fields 
>  > one that I think would be useful i the default search -- 
> taxonomy.  > 
>  > Personally, I think the EcoGrid API (I am going to ask 
> that we rename 
>  > this soon) is pretty lightweight itself -- its the GT 
> implementation 
>  > that is a bit heavier.  Perosnally I don't think EcoGrid 
> is big and 
>  > bulky at all -- in fact, it a super simple API with only a 
> handful of 
>  > methods.  Which makes implementation on new data systems 
> relatively 
>  > easy.  Earlier suggested approaches (like support for 
> XQuery that we 
>  > rejected) would have been much bigger and bulkier, and far 
> harder to tie 
>  > into existing data systems in use around the country.
>  > 
>  > Could you calrify what you think is bulky?  get()?  
> query()?  login()?  
>  > logout()?  put()?  something else? or are you referring to 
> the use of 
>  > globus mainly?  Thanks for the clarification.
>  > 
>  > GAMA is also pretty straightforward.  Given we want access 
> to resources 
>  > that use a variety of authentication and authorizaiton 
> schemes, it seems 
>  > like a great approach to me.  Do you know of a better API 
> that we should 
>  > consider that support, e.g., LDAP and MyProxy?
>  > 
>  > Matt
>  > 
>  > Bertram Ludaescher wrote:
>  > 
>  > >One other concern regarding this solution: I fear that 
> this will be  > >hardwired in the code, right? 
>  > >
>  > >I think a better solution would be to declare, e.g., via 
> a set of views,  > >which fields are being queried.  > >  > 
> >That one the code wouldn't have to be changed when one 
> decides to turn  > >on/off certain fields for search. In 
> fact, the user could specify which  > >parts are to be 
> searched..  > >  > >We could have a user-definable search 
> option (where to search) and a  > >full-text index...  > >  > 
> >Bertram  > >  > >On Fri, 16 Sep 2005, Jing Tao wrote:  > >  > >  
>  > >
>  > >>Hi, matt:
>  > >>
>  > >>I will do it.
>  > >>
>  > >>Thanks,
>  > >>
>  > >>Jing
>  > >>
>  > >>Jing Tao
>  > >>National Center for Ecological
>  > >>Analysis and Synthesis (NCEAS)
>  > >>735 State St. Suite 204
>  > >>Santa Barbara, CA 93101
>  > >>
>  > >>On Fri, 16 Sep 2005, Matt Jones wrote:
>  > >>
>  > >>    
>  > >>
>  > >>>Date: Fri, 16 Sep 2005 15:47:52 -0800
>  > >>>From: Matt Jones <jones at nceas.ucsb.edu>
>  > >>>To: Jing Tao <tao at nceas.ucsb.edu>
>  > >>>Cc: seek-dev <seek-dev at ecoinformatics.org>
>  > >>>Subject: kepler quicksearch
>  > >>>
>  > >>>Jing,
>  > >>>
>  > >>>Could you modify the current QuickSearch in Kepler 
> against EML and make sure 
>  > >>>that it is searching the taxonomic fields, mainly 
> "taxonRankValue", along 
>  > >>>with the other title/abstract/keywords/creator fields?  
> That way, when 
>  > >>>someone searches for a scientific name in Kepler they 
> should get results back 
>  > >>>from both EML and DarwinCore.  Thanks.
>  > >>>
>  > >>>Matt
>  > >>>
>  > >>>
>  > >>>
>  > >>>      
>  > >>>
>  > >>_______________________________________________
>  > >>Seek-dev mailing list
>  > >>Seek-dev at ecoinformatics.org
>  > 
> >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinf
o/seek-dev
 > >>
 > >>    
 > >>
 > >
 > >  
 > >
 > 
 > 
 > -- 
 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 > Matt Jones
 > jones at nceas.ucsb.edu                         Ph: 907-789-0496
 > National Center for Ecological Analysis and Synthesis (NCEAS)
 > UC Santa Barbara     http://www.nceas.ucsb.edu/ecoinformatics
 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
Seek-dev mailing list
Seek-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev