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

Mon Jul 11 11:26:05 EDT 2011

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