[ESP] Invitation to next ESP Meeting

[Ethan Davis]

Benno Blumenthal wrote:
> On Fri, 2003-07-04 at 07:59, Bryan Lawrence wrote:
> 
>>Folks
>>
>>I think Glenn's provided a list of issues which most of us would agree are 
>>important in one way or another. However, I suspect there are too many of 
>>them for a two day meeting, and we would end up with a show and tell, and 
>>we'd all walk away, with no progress on the issues and no real momentum with 
>>which to go forward.  Meanwhile, I'll follow up on some of Glenn's issues in 
>>another email.
>>
>>Do we have any consensus about what this meeting is for? My feeling is that 
>>this meeting is about portals. I would rather we concentrated on what 
>>technology we have available for portals, what the portals should be doing, 
>>who is doing what, and how we can interoperate etc. I'd be happy to propose 
>>some more specific items for an agenda if that's a consensus opinion about 
>>what this meeting should achieve.
>>
>>Bryan
> 
> 
> While your point is well-taken that Glenn has provided an extensive list
> of issues that might be difficult to handle in a short meeting, that
> fact remains that the best way (in my opinion) to create data portals is
> to solve the data organization/distribution problems that Glenn lists. 
> Once the data is well-organized/documented and on readily accessible
> servers such as DODS/THREDDS -- any corresponding client is a data
> portal.   I already have such a web-based client
> (iridl.ldeo.columbia.edu) whose entire interface is derived from the
> structure presented in a THREDDS document (and the subdocuments/datasets
> that are referenced), and there are (or will be soon) others.
> 
> On the other hand, the reverse is not true: simply creating a web-based
> interface will not get us the data interoperability needed.   And an
> human-operated interface to poorly organized/documented data does not
> get one very far.
> 
> Benno

Hi all,

I think Bryan and Benno both make good points. For me, what ties them together 
are two questions:

1) What are the desired capabilities of the portal framework?
2) What information does the portal need to satisfy those capabilities?

 From there we can attack the painful question of

3) How do various standards/formats map into the required information set?

It is also important to remember that different portal sites are going to have 
different setups including not having all the required/desired information. Do 
we need levels of required information that map onto levels of portal 
capabilities? How do we provide for adding ancillary information to satisfy the 
requirements without requiring a complete reshuffle of existing metadata?

Once we're talking about available technologies we need to focus on both 
technologies for portals themselves and technologies for metadata and format 
interoperability.

Ethan

-- 
Ethan R. Davis                       Telephone: (303) 497-8155
Software Engineer                    Fax:       (303) 497-8690
UCAR Unidata Program Center          E-mail:    edavis@ucar.edu
P.O. Box 3000
Boulder, CO  80307-3000              http://www.unidata.ucar.edu/