Hi Benno, At first I thought I agreed with you on the dataset aliasing issue. Now I'm not so sure. It seems like the problem boils down to the ability to reference a dataset in an external catalog. Currently, the only external reference is a catalogRef which dereferences into a collection. One solution would be to switch things around in one way or another so that catalogRef could be dereferenced into a dataset. On the other hand, an aliased dataset already gets dereferenced into a dataset. There are two issues at this point: first, dataset aliases are currently restricted to local datasets; second, datasets aren't complete (i.e., it doesn't necessarily contain a service). But that shouldn't matter, the client would need to parse the entire catalog doc to find the referenced dataset so the dereferencing step could also grab the required service. Here's an example: Top level catalog (cat1.xml) that references datasets (sorry, I don't know XPointer well so I'm faking the actual references): <catalog name="catalog 1" version="0.6d"> <collection name="collection 1"> <service name="motherlode" serviceType="DODS" base="http://motherlode.ucar.edu/cgi-bin/dods/nph-dods" /> <dataset alias="http://.../cat2.xml#id(ds1)" /> <dataset alias="http://.../cat3.xml#id(ds2)" /> <dataset alias="http://.../cat4.xml#id(ds3)" /> </collection> </catalog> Lower level catalog (cat2.xml) that contains info on a single dataset that is referenced by cat1.xml: <catalog name="catalog 2" version="0.6d"> <collection name="collection 2"> <service name="motherlode" serviceType="DODS" base="http://motherlode.ucar.edu/cgi-bin/dods/nph-dods" /> <dataset name="dataset 1" ID="ds1" dataType="Grid"> <access serviceName="motherlode" urlPath="ds1.nc" /> <dataset alias="http://.../cat5.xml#id(ds5)" /> <dataset alias="http://.../cat6.xml#id(ds6)" /> </dataset> </collection> </catalog> Not sure if this is cleaner than figuring out how to get catalogRefs to dereference into datasets rather than collections. The incompleteness of a dataset seems to make it a bit harder on the client side. What does everyone think? Also, one comment on efficiency of transmission. I certainly agree that it won't always be reasonable to represent an entire sites holdings in a single THREDDS catalog. But doesn't going to one dataset per step go to the other extreme which could also be somewhat inefficient? It certainly side-steps any opportunity to reduce the number of HTTP requests involved in the clients navigation of the hierarchy. Obviously, though, it will sometimes be desirable to do just that. Ethan Benno Blumenthal wrote: > > Hi Ethan, > > I don't think so, but I don't know what you are talking about either, so that > is not definitive. Let me remind you what I am trying to do. I contend > (though people do not necessarily believe me) that it is not reasonable to > expect the THREDDS catalog at a particular site to fit into a single file. > It is certainly grossly inefficient to transmit the whole tree when the user > is only interested in a small branch. I think the IRI Data Library catalog > is one of those catalogs. The way I do that is to transmit one level of > nesting at a time, using catalogREF to point to the sub-catalogs. Those > subcatalogs may contain a collection or a dataset: there is no real > difference as far as the Ingrid is concerned, though I am perfectly happy to > call objects without DODS access collections and objects with DODS access > datasets. If you use datasetaliasing, then you still have the problem of > creating a THREDDS document that describes a dataset within a collection, > which means a catalog must be able to contain a single dataset. No real > progress. > > Benno > > > Ethan Davis wrote: > > > Benno Blumenthal wrote: > > > > > > This does not quite work for me, unless you allow a catalog to > > > contain exactly one collection or exactly one dataset. Right > > > now the only thredds thing that can be pointed to is a catalog, > > > with the added provision that a catalog with one collection is > > > effectively that collection -- I would like to point to datasets > > > with thredds, which requires either that a catalog can point to > > > a dataset or a collection, or that you extend collection to be > > > isomorphic to dataset. The catalog modification would be > > > preferable. > > > > Currently dataset aliasing is confined to the current document. What do > > people > > think of extending dataset aliasing to reference datasets external to the > > current document. It means a bit higher maintenance risk as far as broken > > links > > but not much more than the catalogRef already implies. Would that work for > > you > > Benno? > > > > Ethan > > > > > > 6) access element can specify an absolute URL with a serverType -or- a > > > > reletive URL with a serverID. > > > > > > > > > > If you are going to have a base element in service, it is only fair that > > you > > > have a suffix element, too. Please leave the suffix element in. > > > > -- > > 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/ > > -- > Dr. M. Benno Blumenthal address@hidden > International Research Institute for climate prediction > Lamont-Doherty Earth Observatory of Columbia University > Palisades NY 10964-8000 (845) 680-4450 > > -- 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/
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.