[Esip-discovery] DCP-2 Review period closed, sort of

Lynnes, Christopher S. (GSFC-6102) christopher.s.lynnes at nasa.gov
Fri Jul 8 16:06:18 EDT 2011

On Jul 8, 2011, at 3:25 PM, Hua, Hook (388C) wrote:

> Hi Chris,
> Before you close it, I have a few comments:
> (1) It's interesting to see that the baseline rel links are categorical:
> http://esipfed.org/ns/discovery/1.1/data# 	Default data link. Data Casting Granules. OpenSearch Granules response.
> http://esipfed.org/ns/discovery/1.1/browse# 	Appropriate for smaller browse images. See following for alternate browse links.
> http://esipfed.org/ns/discovery/1.1/documentation# 	Default documentation. See following for alternate documentation links.
> http://esipfed.org/ns/discovery/1.1/metadata# 	Data, collection, and service metadata.
> http://esipfed.org/ns/discovery/1.1/collection# 	Data Casting Collection. Not for OpenSearch Collection response which uses OSDD instead.
> http://esipfed.org/ns/discovery/1.1/service# 	Service Casting.
> http://esipfed.org/ns/discovery/1.1/event# 	Micro-articles of natural phenomenon.
> http://esipfed.org/ns/discovery/1.1/feed#  Feed of various feeds. Enables hierarchy of feeds.
> But the OPeNDAP rel can be considered an "instance" of rel=http://esipfed.org/ns/discovery/1.1/data#.

It's not exactly an instance.  It is really a subclass.  I say subclass because in fact there are several different possible OPeNDAP URLs that could be specified, one for each response type.  Alternatively, there are several different OPeNDAP implementations.  Although they theoretically follow the same protocol, their capabilities are different, so that a client might find some use in subdividing the different OPeNDAPs.  For now, though, I thought the one URL was sufficient.

Also, the OPeNDAP URL in the Atom response is not the *actual* URL you would use to interact with the data, just the root.  Or file-specific service endpoint if you prefer.  See answer to #3 below.
> (2) Should we specify that the OPeNDAP rel links are optional?

Yes, I will add that to the spec.

> That way clients conforming to the spec that do not support OPeNDAP URLs can safely ignore it.
> (3) In the baseline spec, we had included a attributes "rel" link and "type" for mime-types. Should we specify corresponding mime-types for these OPeNDAP URLs?

Um, we can't really do that. When you get an OPeNDAP URL, you actually get a whole group of related URLs.  The root URL, if acquired, sends back the original data file with corresponding mime type.  If it is HDF, it comes back as application/hdf.  Add on a .nc suffix and you get a netcdf file of type 'application/octet-stream', though it should really be 'application/x-netcdf'.  Add on a .das suffix, and you get text/plain. A .ddx suffix gets you 'text/xml'.  And so on.
> --Hook
> ________________________________________
> From: esip-discovery-bounces at lists.esipfed.org [esip-discovery-bounces at lists.esipfed.org] On Behalf Of Lynnes, Christopher S. (GSFC-6102) [christopher.s.lynnes at nasa.gov]
> Sent: Friday, July 08, 2011 11:47 AM
> To: esip-discovery at lists.esipfed.org
> Subject: [Esip-discovery] DCP-2 Review period closed, sort of
> Hey folks, review period for DCP-2, Canonicalizing OPeNDAP URLs, closed yesterday, with no comments.  However, if anyone has any serious heartburn with it, I'll extend the review period to COB Monday, July 11.
> The proposal is here: http://wiki.esipfed.org/index.php/Discovery_Change_Proposal-2
> --
> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185

More information about the Esip-discovery mailing list