[Esip-discovery] proposed mods for collection-level responses
Gallagher James
jgallagher at opendap.org
Mon Feb 11 16:39:45 EST 2013
On Feb 12, 2013, at 2:09 AM, Lynnes, Christopher S. (GSFC-6102) wrote:
>
> On Feb 10, 2013, at 5:16 PM, Steve Richard <steve.richard at azgs.az.gov> wrote:
>
>> I like the idea of IANA registration as well.
>> The current RFC for media type specification and registration procedures is http://tools.ietf.org/html/rfc6838.
>>
>> Looks like the 'application/vnd.' tree makes sense. For the THREDDS, OpenDAP, NetCDF world, is Unidata the producer, or is the THREDDS server the producer?
>> application/vnd.unidata or application/vnd.thredds
>>
>> then it gets interesting. OpenDAP is a protocol,
>
> OPeNDAP is a bit ambiguous. Technically, it stands for Open Source Project for a Network Data Access Protocol, but colloquially is used to refer to the protocol. However, the protocol is often just called DAP. So we have some flexibility here here. Looking for a suggestion from the opendap.org and Unidata folks on these…
Correct, OPeNDAP is not a protocol (it's a non-profit corporation) but also correct that its name is used as the name of the protocol.
Since I think 'vnd' stands for vendor, I'd go with application/vnd.opendap.org.dap keeping in mind that we're working with Unidata on DAP4, so there will be vnd.opendap.org.dap4 (I don't think they'd mind the vnd.opendap there… ;-)
>
>> THREDDS is a server implementation,
THREDDS is also a protocol (and its often used as the name of a server although the server is actually called 'TDS'; THREDDS Data Server)
>> NetCDF is a file format. (well, sort of …) Which part of this is the media type? I copied the rfc6838 authors on this to see if they have any suggestions.
>>
>> From
>> http://docs.opendap.org/index.php/DAP4_Web_Services_v3
>> "The Data Service provides DAP4 data access to a dataset, and is the (primary) way that DAP4 returns data to a client. The Data service accepts a query string (constraint expression) which allows you to subset the data and invoke server side functions. When the service is invoked it returns the DAP4 data object. On the wire this is a binary document with MIME type application/vnd.opendap.org.dap4.data."
>
> This may point the way to our naming for OPeNDAP directories, perhaps application/vnd.opendap.org.dap4.directory.
>
> Kinda long to return for every link of that type…
Well, yes. But this stuff tends to be wordy. You could shorten 'directory' to 'dir'.
James
>
>>
>> application/x-netcdf has been used for NetCDF
>>
>> Neither of these seems to be registered.
>>
>> steve
>>
>>> -----Original Message-----
>>> From: esip-discovery-bounces at lists.esipfed.org [mailto:esip-discovery-
>>> bounces at lists.esipfed.org] On Behalf Of Lynnes, Christopher S. (GSFC-6102)
>>> Sent: Saturday, February 09, 2013 6:43 AM
>>> To: Mattmann, Chris A
>>> Cc: <esip-discovery at lists.esipfed.org>
>>> Subject: Re: [Esip-discovery] proposed mods for collection-level responses
>>>
>> … snip.
>>>
>>> According to this, we should be using a vnd.<producer>.subtype, so perhaps it
>>> would be:
>>> vnd.opendap.directory
>>>
>>> Also, RFC 3023 lays out a policy of using '+xml' suffix for XML-based mime-types,
>>> so we would have:
>>> vnd.unidata.thredds+xml
>>> Pending agreement with Unidata of course.
>>>
>>> We could actually submit these for registration to IANA:
>>> http://www.iana.org/cgi-bin/mediatypes.pl
>>>
>>>>
>>>> Or in general:
>>>>
>>>> <primary type [1 of 8]>/[extension denoted by x-]<sub
>>>> type>[-protocol][-ESIP Open Search type]
>>>>
>>>> Or did I guess it wrong?
>>>>
>>>> Cheers,
>>>> Chris
>>>>
>>>> On 2/8/13 2:24 PM, "Lynnes, Christopher S. (GSFC-6102)"
>>>> <christopher.s.lynnes at nasa.gov> wrote:
>>>>
>>>>> As I was working with Ruth on a collection casting example, we ran
>>>>> across an area that we have not fully specified, namely how to
>>>>> identify links that access data collections that are NOT simply URLs for
>>> OpenSearches.
>>>>> These access points may be single-file datasets, OPeNDAP, THREDDS,
>>>>> FTP directories, databases, order forms, dataset landing pages with
>>>>> links to access points...
>>>>>
>>>>> OTOH, we would like to keep the scheme congruent with a granule level
>>>>> response as much as possible. So I propose the following
>>>>> Collection Access Point rel type
>>>>> ======================= ===============
>>> ==================================
>>>>> ==
>>>>> FTP Directory tree archives application/x-ftp-directory
>>>>> OPeNDAP Directory Tree archives application/x-opendap-
>>> directory+html
>>>>> (would also include xlink:arcrole=#dir)
>>>>> THREDDS Catalog archives application/x-thredds-
>>> catalog+xml (would also
>>>>> include xlink:arcrole=#thredds)
>>>>> Single-file dataset enclosure <depends on data format>
>>>>> Order form archives text/html
>>>>> Dataset landing page archives text/html
>>>>>
>>>>> Comments?
>>>>> --
>>>>> Dr. Christopher Lynnes NASA/GSFC, Code 610.2 phone: 301-614-5185
>>>>> "Perfection is achieved, not when there is nothing left to add, but
>>>>> when there is nothing left to take away" -- A. de Saint-Exupery
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
--
James Gallagher
jgallagher at opendap.org
406.723.8663
More information about the Esip-discovery
mailing list