Daniel Holloway wrote:
benno@xxxxxxxxxxxxxxxx wrote:
I have a proposal to make:
Is it possible that we want to have only one standard (the AggServer version)?
The argument is as follows. Suppose someone is describing a set of dods urls
that correspond to different times. They have no intention of running an
AggServer, so they confine themselves to the InvCatalog dtd. Wouldn't we be
better off if they had described the collection in the AggServer format, so that
we would then be able to detect that aggregation is the appropriate thing to do
with the collection, and to describe/index/present it to the user accordingly.
Or, if the software does not aggregate, just present the collection, nothing
lost relative to the InvCatalog description.
I think it could be a powerful notion to combine these two, but i havent
thought through all the consequences yet.
It seems that what you are proposing is to try to allow the
specification of how the datasets in a collection are precisely related,
eg "time series". This idea has also come up from the IDV group. With
this you can do essentially "client side aggregation".
Here are some possible problems:
1. On the agg server, the aggregation files can be local, ie not
available individually from the server. More generally, I would like to
add a mechanism to allow the server to create views of datasets; the
underlying implementation of those views could be hidden from the client.
2. AS config more or less assume the DODS/netCDF data model. But THREDDS
catalogs allow datasets using services other than DODS, so the meanings
of aggregated datasets may be less clear.
3. The AS config can add various XML elements that are specific to the
AS and DODS, without worrying about confusing things for non-AS users.
I tend to agree with Benno on this, though the one standard may end
up being slightly different than the current AggServer version. My concern
is that the current InvCatalog description isn't extensive enough to be
much more than a simple list which in the long run isn't sufficient to
represent a true catalog. I realize that work is underway to develop
queriable catalogs, if possible that effort should try to merge the
existing Aggregation descriptions into those catalogs since in some
sense there are clear similarities with building multi-dimensional
aggregations of simpler types and traversing organizational hierarchies
represented in catalogs to uniquely identify data granules of
interest.
Dan
I am more or less ready to start thinking about catalog version 0.7. If
I understand what you are thinking, you want to provide the same
functionality as dodsdir ? Can you give specifics of that?
