Jon Blower writes:
> I agree with Stephen and Bryan here. I'm really worried about the
> current state of standard names for many reasons but one very
> practical reason in particular. If the standard name is meant to be
> exposed to the user (which presumably it is) then it must logically
> appear in user interfaces. Many of the current names are far too long
> for this to be sensible because more and more things have been pushed
> into the standard name.
Yes... the standard_name maybe human-readable, but it isn't
human-writable... it's doesn't resolve uniquely into a variable... I'm
having a hard time coming up with use cases for the standard_name... I'm
getting to feel like a stuck record here...
> Speaking as a tool developer, the only way to support this is to keep
> standard names short and sacrifice some precision. Standard names can
> then be linked trivially to a more wordy and precise definition via a
> simple URL as Stephen describes. Yes, this means an extra step of
> indirection but it's an easy one for tool developers to implement.
Short standard names are what I proposed earlier in #11, but I believe
common_concept to be able to play this role for tool developers much
more cleanly...
> If you really want a NetCDF file to stand alone and contain all
> relevant information then the precise definition of a term can still
> appear as a text field in the file.
>
> This proposition is entirely analogous to the OGC concept of having a
> Title for a thing (which is human-readable, reasonably short,
> imprecise but "good enough") and an Abstract for the same thing (which
> allows more space for a wordier and more precise description).
name and long_name seem to play this role in CF. But again I feel
standardizing the name itself may be overkill... it's enough to provide
a uniquely-resolving additional tag for a specific purpose that
expresses synonymity between two variables with different names. Many
current web technologies (esp the web2.0 stuff) rely almost entirely
on multiple overloaded tags for the same object.
>> I completely agree with Bryan's observation that self describing files
>> are a mirage.
> Agreed. Nothing is ever self-describing *and* standalone. Everything
> is described relative to some (implicit or explicit) external set of
> conventions or frames of reference.
Yup. When the external conventions are "soft" (implicit) it becomes a
fragile situation. Don't want to belabour the point, but common_concept
gives us a place holder for quickly inserting specific conventions for a
specific purpose without having to go through a lengthy standardization
process.
Thanks,
--
V. Balaji Office: +1-609-452-6516
Head, Modeling Systems Group, GFDL Home: +1-212-253-6662
Princeton University Email: v.balaji at noaa.gov
Received on Wed Apr 09 2008 - 09:37:37 BST
