[Esip-discovery] Standard metadata in collectioncasts

[Lynnes, Christopher S. (GSFC-6102)]

Yes, language bedevils us here:  "parameter" and "dataset" are both highly ambiguous in this context. Sometimes people use "parameter" to equal "variable". Likewise, "dataset" sometimes means "variable", other times means "granule" and other times "collection". I think we need to use examples as much as possible.

In my language, I am actually trying to avoid the word "parameter" as a synonym for "variable" in the netCDF sense.  So in that case, it's the variables that get the "standard_name" attribute.  

Start with an easy one:  Say we have a data collection "AIRS/Aqua Level 3 Daily standard physical retrieval (AIRS+AMSU)", with an OPeNDAP hierarchy starting at http://acdisc.gsfc.nasa.gov/opendap/ncml/Aqua_AIRS_Level3/AIRX3STD.005/.  This has individual time slices, or granules, for each day, all of which have hte same sets of variables.

For instance, take the variables:
RelHumid_AU46, which has CF standard name relative_humidity, and  RelHumid_DU162 which has the same standard name.

One is compiled from the ascending node of the satellite and the second is descending.  Similar variables are to be found in the daily product collection that does not use AMSU, as well as all of the monthly equivalents of these product collections.  Is that what you had in mind?

On Feb 19, 2013, at 3:42 PM, Ruth Duerr <rduerr at nsidc.org> wrote:

> Hi Eric,
> 
> I am not sure what your definition of dataset is but it sounds like the low level datasets within a file like HDF uses.  Not sure if that is true or not.  If so though, maybe we are using the term collection the same way as you are.  In that case, I should say that some NSIDC OpenSearch services already support what you are talking about (i.e., they return a list of parameters for the data set/collection). However I don't think we are using CF standard names, rather the GCMD parameter list, though I'd have to double check that.  I am also pretty sure that we actually aren't advertising these services as being publicly available (though they are).
> 
> I should also note that we want to keep the CollectionCast spec the same as the data set level OpenSearch spec for query results.
> 
> I guess all of this is to say that we would support such an optional list provided it was part of both the CollectionCast and OpenSearch results specs…
> 
> Ruth
> 
> On Feb 19, 2013, at 12:15 PM, Eric Rozell <rozele at rpi.edu> wrote:
> 
>> I'm currently working on a project  interested in harvesting the CF standard names in opendap metadata.
>> 
>> I thought this might be an interesting use case for collection casts.
>> 
>> I currently dont have a way of determining which opendap datasets belong to the same collection other than inspecting the URL paths.
>> 
>> What would be useful is an aggregate feed of the standard parameters provided in a particular collection.  Could we add an (optional) list of parameters from a standard vocabulary that are shared across all datasets from a collection?
>> 
>> Not sure if this has been previously discussed or not.
>> 
>> Cheers,
>> Eric
>> _______________________________________________
>> Esip-discovery mailing list
>> Esip-discovery at lists.esipfed.org
>> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
> 
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

--
Dr. Christopher Lynnes, NASA/GSFC, ph: 301-614-5185