NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
----- Original Message ----- Sent: Wednesday, May 15, 2002 1:11 PM > Hi John, > > An example would certainly be in order. Within Ingrid/IRI data library, the > url for a dataset is a virtual directory, different files within that > directory contain the different representations of that dataset, e.g. > dods.das, dods.dds, dods.dods, data.cdf, data.r4, data.s4, data.txt, > index.html, index.xml, .... . Filters on the data and metadata appear as > subdirectories, e.g. a filter which transforms the metadata to be COARDS > compliant would mean appending COARDS/ to the dataseturl. There are also > filters for averaging, svd analysis, etc, but I was not trying to go there at > the moment. > > To describe this as a serviceList, I would envision something like the > following: > > <servicelist ID="Ingrid" base="http://iridl.ldeo.columbia.edu/";> > <service type="DODS" urlsuffix="dods"> > <service type="DODS" subtype="COARDS" urlsuffix="COARDS/dods"> > <service type="netcdf" urlsuffix="data.cdf"> > <service type="netcdf" subtype="COARDS" urlsuffix="COARDS/data.cdf"> > </servicelist> > > ... > <collection name="LEVITUS94"> > <collection name="ANNUAL"> > <dataset name="PO4" serverID="Ingrid" dataType="GRID" > urlPath="SOURCES/.LEVITUS94/.ANNUAL/.PO4/"/> > <dataset name="NO3" serverID="Ingrid" dataType="GRID" > urlPath="SOURCES/.LEVITUS94/.ANNUAL/.NO3/"/> > <dataset name="temp" serverID="Ingrid" dataType="GRID" > urlPath="SOURCES/.LEVITUS94/.ANNUAL/.temp/"/> > > ... > </collection> > > ... > </collection> > > ..... > > > And I would hope the client would generate DODS base urls like > > http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.ANNUAL/.PO4/dods > > or > > http://iridl.ldeo.columbia.edu/SOURCES/.LEVITUS94/.ANNUAL/.PO4/COARDS/dods > > depending on whether it wanted the COARDS subtype or not. So you have added a few new twists to the proposed <serviceList> element: 1) allow servicelist to have a base attribute, which its service elements inherit. 2) add a urlsuffix attribute to service element, meaning "append this to URL". 3) add a subtype atttribute to service element, meaning 3.1 "display this to the user so they can choose" ?? in which case you probably want a subtype on the other element, which in this case would mean "raw - not augmented with COARDS" ? (or) 3.2 "clients should know which service they want and filter accordingly" (client = software client). The last question is really more general than subtypes, its really what does a client do when it sees multiple services for the same dataset? > > > One could envision large service lists, so one might want to allow doing it by > reference (would only have to download a servers servicelist once). > > Benno > > P.S. the 'netcdf' service above refers to http delivery of complete netcdf > files: I only include it as an example and probably would not advertise the > service since I would rather clients use DODS anyway. Actually, service="NetCDF" currently means Netcdf access (including subsetting) through HTTP, which is in the Netcdf-Java library (version 2). We'd have to name your service something different (its more like FTP except over HTTP).
thredds archives: