One thing I dont understand is what is the relationship between whats
contained inside the collection vs. whats in the dataset you specify through
the access element? The user should understand them to be the same (although
in fact the writer could accidentally or on purpose make them unrelated)?
It is not a dataset that I specify through the access element -- it is a DODS access for the collection (collections are the same as datasets -- we cannot even formulate a reasonable distinction). Most collections would not have DODS access, but some do. The writer cannot make them different, that violates the meaning of access belonging to the collection.
IThey are subdatasets, i.e. different ways of accessing the collection dataset. In practice this is important because some DODS clients can handle DODS datasets that contain nest variables (i.e. structures), and some DODS clients can only handle flat datasets, i.e. a collection of simple variables. The DODS clients that can handle nesting can use the collection access through DODS: DODS clients that cannot need to drill farther before using DODS.
presume that the ANNUAL, MONTHLY, and SEASONAL datasets are a different way
of accessing the collection dataset? Or should they be thought of as
different, but related datasets?
In this spscific example, you also specify that the collection has a servicea catalog with a single collection is the collection: your formulation as best I can understand it (i.e. I see no different between catalogs that contain single collections and collections, which is implicit in your dropping the level of nesting under that circumstance). I think I should omit that circular reference (not that the client would get too confused: when it constructed the url it would find it the url of the document), e.g. the file should be
of type Catalog <service serviceType="Catalog" suffix="thredds.xml"/>. What
is the relationship between that catalog and what is contained in the
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE catalog SYSTEM "http://www.unidata.ucar.edu/projects/THREDDS/xml/InvCatalog.0.6a.dtd">
<service ID="IngridDataset" serviceType="Compound" base="http://iridl.ldeo.columbia.edu/">
<service serviceType="DODS" suffix="dods"/>
<service serviceType="Catalog" suffix="thredds.xml"/>
<service ID="JustDODS" serviceType="DODS" suffix="dods"/>
<attribute name="fullname" value="LEVITUS94"/>
<access serviceID="JustDODS" urlPATH="SOURCES/.LEVITUS94/"/>
<attribute name="references" value="Conkright:etal1994 Levitus:Boyer1994a Levitus:etal1994 Levitus:Boyer1994c"/>
<documentation>LEVITUS94: World Ocean Atlas 1994, an atlas of objectively analyzed fields of major ocean parameters</documentation>
<document xlink:href=""http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.oceanviews.html">http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.oceanviews.html" name="oceanviews"/>
<document xlink:href=""http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.oceanviews2.html">http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.oceanviews2.html" name="oceanviews2"/>
<document xlink:href=""http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.Zmix.html">http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.Zmix.html" name="Zmix"/>
<access serviceID="IngridDataset" urlPATH="SOURCES/.LEVITUS94/.ANNUAL/"/>
<access serviceID="IngridDataset" urlPATH="SOURCES/.LEVITUS94/.MONTHLY/"/>
<access serviceID="IngridDataset" urlPATH="SOURCES/.LEVITUS94/.SEASONAL/"/>
-- 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
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.