Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
To make sure I understand you, I am going to add some annotation. let me know if any of it is wrong. Also, I am going to use the following definitions for now: Dataset: the user can select and get a URL. Collection: group of Datasets. I will capitalize them to distinguish them from more general useage. ----- Original Message ----- Cc: <thredds@xxxxxxxxxxxxxxxx> Sent: Wednesday, June 05, 2002 2:56 PM > I think the word dataset is causing trouble. There are at least three > potential meanings for this word in the context of THREDDS: > > 1) an entity that is considered as a unit by human beings Part of a human mental model/ontology. > > 2) an entity that can be operated on as a unit by the THREDDS API An XML InvCatalog element, and compositions of such. > > 3) an entity that can be operated on as a unit by a data access protocol A software object accessed/returned/manipulated from the protocol-dependent handler. > > Right now, only the entities described by "access" tags meet all of 1, > 2, and 3. > > The tags "dataset" and "collection" both describe entities that only > meet 1 and 2. I wonder if my annotations are incorrect since I may not understand this. If I do have them correct, then I would say: Currently a Dataset XML element is supposed to meet 1, 2, and with help from an access element, 3. A Collection XML element meets 1, and 2, and the question is should we find a way to let it also map to 3) when appropriate. In the case where it is appropriate, ie a Collection has a URL, then its easy to take it one step further and just erase the distinction between a Collection and a Dataset. However there are 2 concerns to this approach: 1) When a Collection doesnt have a URL, it cannot meet definition 3). So now you dont have a word for something that always meets 1, 2, 3. 2) What is the relationship between the contents of a Collection element and the contents of the Collection's URL? If the relationship is not particularly well defined or meaningful, you might as well just encode the Collection's URL as a Dataset. If theres a clear and useful relationship then it could be a good idea to give the Collection an access element which makes it clear that that URL has the defined relationship with the rest of the contents. > Thus I agree with benno that there is not a very > meaningful distinction between them (and reconsider my listing of them > as orthogonal concepts in my previous message). > > I wonder if it would be a good idea to merge these concepts and use a > less loaded word, say "entry", to refer to an entity that has meaning to > THREDDS and to end users, but not to a data access protocol, i.e. > > <catalog> > <service name="X"/> > <service name="Y"/> > ... > > <entry name="my_dataset"> > > <metadata name="global-metadata" url="..."/> > <access name="global-X-access"/> > > <entry name="monthly-data"> > <metadata name="monthly-metadata" url="..."/> > <access name="X-with-COARDS" serviceType="X" url="..."/> > <access name="X-with-no-COARDS" serviceType="X" url="..."/> > <access name="X-flattened-to-2D" serviceType="X" url="http://..."/> > <access name="Y" serviceType="Y" url="..."/> > .... > </entry> > > > </entry> Ok so an "entry" meets meaning 1), while an "access" meets meaning 3) (we dont need to worry about meaning 2) here). Some questions: 1) Should we understand that all the access elements within an entry are different versions of the same dataset? Should we disallow: <entry name="monthly-data"> <metadata name="monthly-metadata" url="..."/> <access name="monthly-data from MARS" serviceType="X" url="..."/> <access name="monthly-data from VENUS" serviceType="X" url="..."/> </entry> 2) is there any relationship between peer elements, in your example <access name="global-X-access"/> <entry name="monthly-data">
thredds archives: