[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JDOM Parsing error

John Caron wrote:
> 
> Daniel Holloway wrote:
> 
> >address@hidden 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.

We have always talked about adding spatial and time coverage information to feed
into discovery systems. Much more abstract and high level than what we're
talking about here. However, one could think of the aggregation information as
an extension to coverage information. Perhaps in thinking about changes for 0.7
we should be sure to look at the similarities between these two kinds of
information.

> >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?

I'm not sure I understand what you (Dan) mean by "true catalog"? I'm guessing
you mean being able to represent collections of datasets where a hierarchical
list doesn't fully describe the relationship(s) between those datasets.

The aggregation work and the queriable catalogs can both be seen as attempts to
extend the range of possible relationships we can express. The Agg Server
handles a limited set of "simple" aggregation types. The queriable catalog (DQC)
effort currently handles a limited set of more complex aggregations. Or, if not
more complex, at least not as easy to implement as a single OPeNDAP dataset.

Do you have a set of specific relationships you want to be able to describe?

Ethan

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