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

Fri Jul 8 16:41:55 EDT 2011

On Jul 8, 2011, at 4:32 PM, Hua, Hook (388C) wrote:

> Hi Chris,
> 
> Good points. It's great that you include the DAP version compliance in the rel link (e.g. http://xml.opendap.org/ns/DAP/3.3#) to accommodate variances in the different implementations of the protocol.
> 
> Related to this, we had said rel=http://esipfed.org/ns/discovery/1.1/service# covers service casting links.

Strictly speaking, this might make more sense if we use rel=http://esipfed.org/ns/discovery/1.1/scast#  for service casting links, return ...service# for the more generic service links.

> But did we intend for it to also cover more generic service links? If so, then there may be analogous subclasses of service types. I'm wonder if there is a generalized approach to all of this related to what you are doing with OPeNDAP rels.
> 
> Thanks,
> Hook
> 
> ________________________________________
> From: Lynnes, Christopher S. (GSFC-6102) [christopher.s.lynnes at nasa.gov]
> Sent: Friday, July 08, 2011 1:06 PM
> To: Hua, Hook (388C)
> Cc: esip-discovery at lists.esipfed.org
> Subject: Re: DCP-2 Review period closed, sort of
> 
> 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
> 
> 

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