NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Once the application that is looking at the file see it is netCDF, it can just look in the file to see what the convention is. (And if it doesn't know how to do that, knowing the convention isn't likely to be helpful at all.) John On Oct 12, 2011, at 17:13, John Caron wrote: > we just use "application/x-netcdf" in the TDS, following the "keep it simple" > principle. im not sure if encoding the convention in the mime type is all > that helpful (?) > > On 10/12/2011 7:38 AM, Lorenzo Bigagli wrote: >> >> Dear colleagues, >> >> At the last OGC TC Meeting in Boulder, we discussed the issue of registering >> a MIME type for netCDF. >> As I remember, someone (at Unidata?) may be drafting a proposal, possibly >> following what's in use for xml. >> >> I've given this an extra thought, while working on UncertWeb and the >> Uncertainty Conventions, that I'm sharing here. >> >> First, as a temporary solution, we are using the "application/x-netcdf" MIME >> subtype. >> The biggest issue is with netCDF conventions, since a single netCDF file may >> comply with multiple conventions. >> This gets in the way with a possible hierarchical structure of MIME >> sub-typing, like e.g.: >> x-netcdf-<convention1>-<convention2>... >> >> We may take the xml approach of a "+netcdf" suffix, but this wouldn't >> solve/address the problem. >> So I would suggest an optional "conventions" parameters with the same syntax >> and semantics as the global "Conventions" attribute in netCDF. >> The content-type of a netCDF-U dataset may look like: >> application/x-netcdf; conventions="UW-1.0 CF-1.5" >> >> We may take the same approach with the version, although I'd probably go for >> an "application/x-netcdf-4" subtype, in that case. >> I would be interested in comments on this, also to align with what is being >> drafted. >> >> Best regards, >> Lorenzo >> >> >> Il giorno 30/set/2011, alle ore 23:18, Ben Domenico ha scritto: >> >>> Hi all, >>> >>> The CF-netCDF SWG session was held Thursday morning September 22, 2011 at >>> UCAR in Boulder. A summary is given below. If anyone who attended the SWG >>> has additions or corrections, please let us know. >>> >>> -- Ben >>> >>> ========================================== >>> >>> CF-netCDF SWG Session at the September 2011 OGC TC Meetings in Boulder >>> >>> Agenda >>> >>> The agenda consisted of: >>> CF extension to the netCDF core standard (Stefano Nativi) >>> CF-netCDF extension to the WCS core standard (Stefano Nativi) >>> Enhanced Data Model extension to the netCDF core standard (Ben Domenico) >>> Uncertainty model for netCDF-CF (Lorenzo Bigagli and Stefano Nativi) >>> Determine how to deal with errors in existing netCDF binary standard noted >>> by Simon Cox (see next slide) >>> Item 5 was taken care of in brief discussions with Carl Reed and Simon Cox >>> outside the SWG session. They both agree that the changes are not >>> substantive, so the typos can be corrected in the existing spec and a >>> phrase can be inserted clarifying that Requirement 1 is a special type of >>> requirement, namely, a dependency. >>> >>> The presentations and draft documents are available at: >>> >>> https://portal.opengeospatial.org/index.php?m=projects&a=view&project_id=82&tab=2&artifact_id=45016 >>> >>> Issues >>> >>> A couple additional issues came up during the discussion >>> There is a need to register a mime type for netCDF with IANA. The question >>> is whether to try to come up with all the modifiers (e.g. netCDF-3, >>> netCDF-4, netCDF-CF,…) before submitting request. The sense of the group >>> is that a base mime type necdf should be registered with modifiers for >>> netCDF-, netCDF-4, CF-netCDF, etc. >>> With the new modular approach to specifications, OGC is creating a bit of a >>> Humpty Dumpty Problem of having too many modules in specs, too many >>> conformance classes within modules, etc. As a consequence, potential new >>> users can be overwhelmed. It isn't always clear how to assemble fragments >>> into a coherent, working whole. Primers with an overall overview are a >>> help by not a solution. One new possibility is to emphasize the need for >>> overview information in Profile specs where the application to a particular >>> community is documented. >>> Action Items (all internal to the SWG) >>> Make non-substantive edits to existing netCDF binary encoding spec. See >>> note in Agenda above. (Ben Domenico) >>> In the CF Extension to netCDF core, some items that are optional for CF are >>> mandatory in the proposed OGC specification. A list of these items will be >>> circulated with the call for comments. (Stefano Nativi) >>> The CF-netCDF overview and planning documents should indicate that >>> XML-encoding is addressed in CF-netCDF extension to WCS. (Ben Domenico) >>> Discussion paper for netCDF uncertainty conventions will be captured in a >>> discussion paper for next TC. Will include netCDF3 and netCDF4 options and >>> will pursue with CF conventions community in parallel (Lorenzo Bigagli) >>> Motions >>> >>> There were no motions at this SWG >>> _______________________________________________ >>> galeon mailing list >>> galeon@xxxxxxxxxxxxxxxx >>> For list information, to unsubscribe, visit: >>> http://www.unidata.ucar.edu/mailing_lists/ >> >> >> >> _______________________________________________ >> galeon mailing list >> galeon@xxxxxxxxxxxxxxxx >> For list information, to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ > > _______________________________________________ > galeon mailing list > galeon@xxxxxxxxxxxxxxxx > For list information, to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ John Graybeal <mailto:jgraybeal@xxxxxxxx> phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org
galeon archives: