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.
Hi, comments below ----- Original Message ----- <thredds@xxxxxxxxxxxxxxxx> Sent: Tuesday, June 04, 2002 12:23 PM > Hi John, > > Thanks for the response. I have a couple of thoughts: > > 1) serviceType="Catalog" is the same as catalogRef elements, that is true, > *but* what I was trying to express is that the datasets that are available via > dods are also available as THREDDS catalogs. You have deleted that information > -- in your version, datasets are only available as DODS datasets. And deleting > the suffix part destroys the compact representation of compound services for > servers that uses suffixes, i.e. ingrid and typed-file servers (http,ftp, etc, > with a fileextension convention), and servers that have query-based urls with > one tag that distinguished the format of the response. I only had two > services to make the example clear -- many servers are going to have multiple > services, that was the point, and I have many more services that could be > described once THREDDS matures. For example, a lot of clients are written to > COARDS -- I can generate metadata and datasets that conform, though frequently > that is a poor description of the data. But if the client insists, and > THREDDS allows the constraint, the servers and clients could communicate. > The metadata tag is really a set of services for metadata (i.e. metadata as > DIF, etc), which you are certain will alway be multiple. Really I am playing devils advocate for simplicity, so I am just looking to see what happens to try to fit your examples into the current (sort of simple) design. So really we need a concrete example that could make good use of a compound service. Im trying to think what is the meaning of serviceType="Catalog" in general? What should the client assume? It seems that if you want the client to be able to get the collection as a dataset, then you add a dataset element. If you want the client to "drill down" further, then a collection or catalogRef element can do that. What I have removed is the clear association between the dataset element and the collection, eg that these are the same thing. I have also made it more cumbersome(need two elements). I agree these are weaknesses. The fact that you can produce a dataset as COARDS vs DIF, etc is also for me not so great of an example. Rather than modifying the underlying data acess (eg DODS), it seems simpler to add a metadata element. I admit that this is just an idea which has not been done yet. And you already have a server that does in fact modify the data access. But think of it from a client POV. Should she search through the services looking for a service of type DODS, subtype COARDS? Or search through the metadata looking for COARDS metadata, independent of service type? A more compelling example would be where the dataset is served up through FTP and DODS, and ADDE, etc. But then I wonder/doubt whether one URL is likely to be able to be used for all these services. > > I am also concerned about XYZT clients (4D world view) -- how can I protect > them against higher (and other) dimensional data (ensemble member count, > spectral, different kinds of time (forecast start, lead, target time)? I > could convert to multiple datasets, or spatial grids, but it would be nice to > advertise the service. As well as supporting various binary and ascii data > formats. Or the THREDDS dataset (as opposed to collection/catalog) > description... I am not clear of "protect", did you mean "project" ? It seems that you are trying to provide various services within this catalog framework. I see that you provide a lot of these through an HTML interface in INGRID. I think here we want catalogs and any associated services to be useable by client software, so they have to be very clearly defined to be useful, much more so than an HTML page that can assume human intelligence. Some concrete examples would be good. > > > > 2) The access for the dataset LEVITUS94 is again via THREDDS (the present > collection) or via DODS (the access statement). Adding another dataset inside > the collection called "Daily" is not the same meaning at all. Sorry, I should have had: <dataset name="LEVITUS94 dataset" urlPath="SOURCES/.LEVITUS94/dods"/> <catalogRef xlink:title="Drill down into dataset" xlink:href="http://iridl.ldeo.columbia.edu/SOURCES/LEVITUS94/thredds.xml"; /> In this case the dataset is presented to the user for immediate selection AND a link is presented for drilling further down. Now in your case the equivilent is: <access serviceID="IngridDataset" urlPATH="SOURCES/.LEVITUS94/"/> and because the "IngridDataset" service has a contained service of type "Catalog" the user should know that she can drill down further into this dataset? Should the rule be to present this catalog as a catalogRef ? > > 3) I thought multiple documents was more analagous to to multiple datasets > within a collection, leaving documentation as the unnamed tag within a > collection. I am also concerned about having names for datasets and titles for > documentation -- seems unnecessarily confusing to give different names to the > same concept in different contexts. But documentation tags work for me as > well as document tags. Yes, good point I started using "title" to follow XLink, maybe we should propagate that to dataset for consistency. Right now, documentation means "present this to the user during dataset selection". With xlink:show semantics, I thought that we could accomodate what you are doing with your "view" HTML pages. > > So can we go back to the suffix attribute? And multiple services? Datasets > as collections, or access allowed as an subelement of a collection? (After > all, why not be able to serve collection metadata in multiple ways?) Anyone else have opinions on this? > > Compound does not have to be the only service with sub services: perhaps you > should restructure DODS as a service with das,dds,dods,info,ascii subservices? > Likewise for OpenGIS? The main thing service does is to let you specify a type and factor out the common URL base. then this is passed to "protocol aware" code. Because the das,dds,dods,info,ascii subservice URLs are always regular in how they are formed, it seems unnecessary to actually specify them. In principle subservices are probably useful but some concrete examples are needed. > > While I have not given examples, different datasets will have different > services, which is why I kept specifying using the access tag. Some datasets > will be incompatible with certain representations, so the service lists will > vary. One could argue that the THREDDS standard collection is a dataset not > available via DODS -- certainly that is the case for me. I understand you want to compactly specify what services are available for datasets. Im not sure we have enough examples to make sure we are doing it right. I am also oriented towards incremental design, doing what we can get right and iterating.
thredds archives: