Subject:
[Fwd: Thoughts on 5.2 of ISERVO]
From:
Marlon Pierce <mpierce@cs.indiana.edu>
Date:
Mon, 21 Feb 2005 20:30:45 -0500
To:
Geoffrey Fox <gcf@grids.ucs.indiana.edu>

Does the list below look OK?

-------- Original Message --------
Subject:     Thoughts on 5.2 of ISERVO
Date:     Mon, 21 Feb 2005 18:04:53 -0500
From:     Marlon Pierce <mpierce@cs.indiana.edu>
To:     Dennis McLeod <mcleod@usc.edu>, Bertram Ludaescher <ludaesch@sdsc.edu>



I talked with Geoffrey to get a recap of the Saturday morning session on the iSERVO proposal.  See http://hirsute.cse.ucdavis.edu/~rundle/PROPOSALS/ISERVO/iSERVO_with_Table_Contents.doc.  The TOC of this document is more important than the current, placeholding material that follows, and it will probably be easier to throw out the current text than to revise it.

Here is a list of thoughts on section 5.
* Given the limited amount of money, we really need a "deployment" track that focuses on simplifying things to get them to work, and an IT "research" track.  That is, the whole thing has to work pretty early into the funding, but there is also going to be a wealth of stuff for topics like information modeling that will make a good graduate research topic.

*  We can follow a BIRN/GEON model for building the grid: resources publish their availability and metadata about themselves in order to become an ISERVO node. So we need a registry and some metadata conventions (GIS standards will be useful for the metadata).

* There is some registry service for managing all the participating ISERVO nodes.  This can be simple (like UDDI at first), becoming more sophisticated as we go.

* We define what an ISERVO node is.  It will be some combination of data, executable application codes, and other resources that is accessed through one
or more Web Services.  So there are standard services for GPS data, Seismic data, Fault data, and standard services for describing and executing codes.  Our job is to tell people how to set this up and to make their data and codes available, not to run their services.

* I think it is reasonable to assume that there is a lot of archival data available (the Japanese, etc, equivalents to the California GPS and Seismic data).  Probably it will not be available in any sophisticated form.  So defining data models for these basic data types (faults, GPS, seismicity) is one initial activity.

* There must be some need for "schema resolution" or similar for resolving small differences between legacy data models.  I base this on the experience with GPS and Seismic data.  So ontology work will be important here.
* Code resources can be treated similarly: there needs to be ontological descriptions of how codes and data match up.  So if Ayers Rock University publishes the availability of some Pattern Informatics code that works with seismic catalogs, this sort of stuff is modeled.  This helps someone find codes that apply to a particular problem domain and also match them up with appropriate data.

* We expect the various ontology models to evolve over time.

* The ontology models will be used to build sophisticated higher end tools such as workflow systems.


Marlon