[Esip-discovery] Tools Casting

[Hua, Hook (388C)]

Hi Sky,

I think you have good points and even drilled a step deeper into the mechanics of the Discovery conventions.

Most of the Discovery services enable machine-to-machine interfaces where the consumption of the returned content can be orchestrated by other software. For casting tools, where the notion is "rel=human", this would imply that more likely humans are consuming the content results. We could also explore methods to normalize how to represent casting of tools where ideally the rel is more machine-usable. From the original plan of a "dynamic online catalogue of decision tools", there could be many interfaces to the catalog (e.g. web "app store", ToolsCast, or even code package manager). 

Your suggestions on a ToolsCast sounds like a good use case for the Discovery testbed (funding pending). The Discovery testbed proposal already included standing up a ServiceCasts of our community services. It would also allow us to collaboratively further develop the ideas and setup an implementation were we can submit and cast out community tools.

--Hook



________________________________________
From: esip-discovery-bounces at lists.esipfed.org [esip-discovery-bounces at lists.esipfed.org] On Behalf Of Steve Aulenbach [saulenbach at neoninc.org]
Sent: Thursday, July 21, 2011 9:39 AM
To: Ruth Duerr
Cc: esip-discovery at lists.esipfed.org; Sky
Subject: Re: [Esip-discovery] Tools Casting

I am very interested.

Steve

________________________________
Steven M. Aulenbach
Scientist, LUAP/Cyberinfrastructure
National Ecological Observatory Network
NEON, Inc.
Boulder, CO 80301
(720) 746-4855
saulenbach at neoninc.org<mailto:saulenbach at neoninc.org>



On Thu, Jul 21, 2011 at 10:34 AM, Ruth Duerr <rduerr at nsidc.org<mailto:rduerr at nsidc.org>> wrote:
Hi Sky,

Yes, tools that range from an actual web application to a web service to a static map do all fall within the existing concept of ServiceCasting (or at least they do here though not all our services are yet cast). The only one I am not sure about is the to a discussion of a decision support methodology; mostly because I am not certain what that is - so perhaps a bit more discussion needs to happen around that.  However, I am open to ideas for making these discovery technologies more flexible and semantically meaningful.  As for your second question about collaboration - I can't speak for the cluster as a whole, but I certainly am open to that sort of collaboration (actually I kind of think that is the whole point of ESIP and clusters and what not).  What do others think?

Ruth

On Jul 20, 2011, at 5:01 PM, Sky wrote:

> Greetings,
>
> I thoroughly enjoyed attending my first ESIP meeting last week. There's certainly a wealth of good work going on, and I look forward to tying in much of our similar work from USGS.
>
> Along those lines, I had a great conversation today with Alison LaBonte with OSTP who gave a talk last week in one of the Energy and Climate cluster sessions on some work she is doing with a "Wind-Wildlife Federal Task Force." They are seeking to navigate the somewhat muddy waters of the many decision support tools available and forthcoming that are designed to help resource management agencies determine placement on wind development projects in relation to wildlife concerns. I wasn't there for it, but I understand that the Energy and Climate group ended up coming up with a proposal for a "dynamic online catalogue of decision tools."
>
> In looking this week at how we in USGS can add datacasting and servicecasting conventions and package the ATOM feeds from our ScienceBase cataloging platform, it occurs to me that we could look toward a toolscasting concept for this dynamic catalog of tools. In a lot of ways, the existing servicecasting conventions that I see referenced from a JPL source already fit the bill. Most of the decision support tools would fall into the category of a "rel=human" interface of one stripe or another. I can think of at least one example we're working on with NOAA that actually does take the form of a machine interactive service. The real work will be in developing the conventions for both basic descriptive information and possible "customElement" definitions (to borrow from the DataCasting concept) that would apply to the domain of decision support tools.
>
> So, does the description of a tool that might range from an actual web application to a web service to a static map to a discussion of a decision support methodology fall within the existing concept of ServiceCasting? Or does this area deserve its own branch of the concept into ToolsCasting? Would folks from the Discovery Cluster have an interest in collaborating with folks from the Energy and Climate Cluster, the USGS, OSTP, and this federal task force in developing a conceptual architecture for a solution and helping to set it in motion? Is this the kind of thing that goes on within this community space (for the barely initiated and not quite ESIP'd me)?
>
> «»«»«»«»«»«»«»«»«»«»«»«»«»
> Sky Bristol
> USGS Core Science Systems
> 303.241.4122<tel:303.241.4122>
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org<mailto:Esip-discovery at lists.esipfed.org>
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

_______________________________________________
Esip-discovery mailing list
Esip-discovery at lists.esipfed.org<mailto:Esip-discovery at lists.esipfed.org>
http://www.lists.esipfed.org/mailman/listinfo/esip-discovery