Bill Howe's blog

Last week, I had the opportunity to give two talks in Indianapolis: one at the IEEE eScience 2008 conference, and another at the co-located Microsoft eScience Workshop.

All the presentations were recorded and will soon be available online.

The event brought together a very diverse community, but managed to remain remarkably focused on the core research: new platforms for data-intensive science.

Key themes

A design goal for the Product Factory was to ensure that a permanent url existed for every product. Although every image and dataset generated through the factory is addressable in this way, "mashups" and HTML forms involving factory products must be manipulated interactively.

For example, a CMOP investigator was recently interested in inspecting Cast 77 and Cast 83 from the August 2007 cruise.

On her behalf, a data curator might gather up the relevant links like this:

Hourly data from a variety of sources extracted from the NANOOS database are attached.

We can easily create factory products to expose this data.

Further, these datasets ought to be extractable by a single query rather than one for each platform. Quarry supports this kind of interface.

Each platform generates measurements with a potentially unique signature. Quarry uses a generic RDF-like data model to enable uniform access to everything, but partitions incoming data by signature to maintain interactive performance.

Jim Gray, a Turing award winning computer science researcher at Microsoft Research, has used a "20 questions" methodology to gather data management requirements from scientists in Astronomy, Ecology, Materials Engineering, and more. Each of these efforts led to very successful projects.

Yesterday, I talked about the goals of the product factory, and made a few recommedations for how to use the CMOP product factory -- that is, what kind of products we should add to our repetoire.

Today, I want to set a roadmap for refactoring the factory itself -- What changes do we need to make to the design of the Factory based on feedback?

Observations about the Factory

[img_assist|nid=854|title=|desc=|link=popup|align=left|width=188|height=150]

There were two keynote talks this morning: BJ Penn, Assistant Secretary of the Navy, and Richard Spinrad, Assistant Administrator at NOAA.

Mr Penn spoke first, but I want to start with Dr. Spinrad. He spoke about the interoperability mandate for IOOS and GEOSS, but stressed that the design must be couched in the value to society -- which I interpret as emphasis on user-centered design.

Last week, I had the opportunity to visit the Scientific Computing and Imaging Institute at the University of Utah, where I met with Claudio Silva, Juliana Freire, and their students.

The ability to find the ETM is paramount for the August cruise, and our current capabilities do not provide sufficient help for this task.

I spoke with Joseph and Charles today and came up with possible solutions in increasing order of complexity.

Simplest solution: Manual transects across salinity intrusion boundary

Allow user to generate a transect by clicking points on the map. The transect will be colored by salinity and include barbs representing velocities.

Example:
[img_assist|nid=383|title=|desc=|link=popup|align=left|width=200|height=142]

With current capabilities, the user can visually locate the salinity intrusion at a particular time using the isolines plots in the cruise mapper.

Once located, the user can draw a transect across the salinity intrusion boundary and generate a transect plot like the one above. If the barbs indicate that the river velocity and the tidal velocity are opposed and "sufficiently strong," then the users can navigate to the corresponding lat/lon.