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

Mon Jul 11 14:58:06 EDT 2011

Hi Matthew,

I like where you are headed below.  However, I note that the collection# value has exactly the same problem as the data#attribute.  The link could either point to a landing or catalog page about the data set, or to the FTP site where all the data is stored, or any number of other things (or for that matter it might be good to have links for all of those things).

Ruth

On Jul 11, 2011, at 9:26 AM, Cechini, Matthew F. (GSFC-423.0)[RAYTHEON COMPANY] wrote:

> Chris et. al.,
>   I like adding the "scast#" rel attribute value for service casts.  Does
> that call into question our attribute values for collection and granule
> casts?  For example, can the "data#"  attribute alone sufficiently help a
> client determine whether the URL is pointing to downloadable data or a
> granule search endpoint?  The "collection#" value doesn¹t seem to suffer
> from the same potential confusion, but it's guilty by association in this
> case.  Is it worth introducing sub-types for the cast types (samples
> included below) or introducing values of "scast#", "gcast#", and "ccast#"
> (I'm not sold on the naming) for our casting URL types?
> 
>  + ..../discovery/1.1/feed/collection
>  + ..../discovery/1.1/feed/granule
> 
>  + ..../discovery/1.1/feed/service
>  + ..../discovery/1.1/feed  (same use as current?)
> 
> I don't want to complicate the value listing unnecessarily, but want to
> avoid ambiguity in our response values.
> 
> Thanks,
> Matt
> 
> Matthew F Cechini
> ECHO Systems Engineer
> Office: (301) 851-8049
> Cell  : (202) 251-8013
> Fax   : (301) 851-8283
> E-Mail: Matthew.F.Cechini at nasa.gov
> 
> 
> 
> 
> 
> On 7/8/11 4:41 PM, "Lynnes, Christopher S. (GSFC-6102)"
> <christopher.s.lynnes at nasa.gov> wrote:
> 
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> 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