OK, this is 'too much information' perhaps, but I'm going to give my
thorough response to this thread.
I agree with Roy's principle... and yet: If the 'redefinition' is a
matter of better explaining the original concept -- that is, the
concept hasn't *really* changed but we are describing it in a more
clear way -- then many ontologists/semantic web people would say it is
the same concept, and should still have the same unique identifier.
(The unique identifier is the standard name string, in CF's case.)
Personally, I don't agree with those ontologists, I'm more of an
accountant like Roy -- every change is a change and should be tracked
as such. But CF has 'allocated' terms that are not tied to versions --
that is, the string "land_ice" is not versioned, and will remain the
same unique identifier through history -- and those unique identifiers
have been assigned definitions.
In this situation, if you follow the principal that the definition for
a given unique identifier should not change, then in the case of CF,
every definition is essentially locked in to the existing terms --
none of the definitions can ever be improved, unless you rename the
term. I think this is not the right answer for CF (maybe because I
think a lot of the definitions need to be improved, sooner or later).
So in the end, if CF is going to consider the terms as 'permanently
allocated' in some sense, then I conclude they are really
representations of a fundamental/invariant concept. If you accept this
premise, CF should treat the terms the same way the ontologists do,
unless the intended concept fundamentally changes. (This is
unsatisfying too, I realize. Look, it's a conundrum, there is no good
or absolutely right answer, given the current CF naming and definition
practice. In fact, there is arguably no absolutely right answer in the
world of computation.)
MMI is following a third way, actually. [1] It's the best (or worst :-
>) of both worlds. First, every time you change the definition,
create a URI (unique identifier) that can be used to refer to that
particular version. (In CF's case, this could be the standard name
plus a date code.) Second, declare that the unique identifier without
the version (in CF's case, this is the standard name) represents the
concept currently referenced by that label. In other words, the
definitions can evolve, and the unique identifier simply references
whatever we use for the current definition (which can change). This
even allows definitions to evolve significantly, going further than
most ontologists. I think of it as the 'dictionary model', hopefully
for obvious reasons.
Under that dictionary model, if tomorrow you decide that (unversioned)
land_ice should mean something totally different, you *will* break the
uses of everyone that had used land_ice in the original sense. But if
you just are adjusting the land_ice definition to be 'a little more in
line with what everyone meant', you are likely to improve existing
uses as much as harm them.
People who want to use terms guaranteed not to change can then use the
dated versions of the standard names. People who want to allow for
change to happen -- even with the possible breakage that can create --
use the undated versions. Relationships can be created, even
automatically, that relate the dated and undated versions. And all of
that will be compatible with the semantic web (which will be important
before too very long), and reverse compatible with existing CF usage.
John
[1] More gory details on the MMI approach, as implemented in our
tools, can be found at
http://marinemetadata.org/apguides/ontprovidersguide/ontguideconstructinguris
On Sep 29, 2009, at 9:25 AM, Lowry, Roy K wrote:
> I think Bryan has a very valid point. A basic principle of sound
> vocabulary content governance is that if it's published don't change
> it. If it's wrong, deprecate it and replace it by something else.
> One can never assume that something published has never been used.
>
> Cheers, Roy.
>
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu
> ] On Behalf Of Jonathan Gregory
> Sent: 29 September 2009 10:26
> To: Bryan Lawrence
> Cc: Ed Bueler; Andy Aschwanden; cf-metadata at cgd.ucar.edu; Magnus.Hagdorn at ed.ac.uk
> Subject: [CF-metadata] Standard names for Glaciology and ice-sheet
> modeling: land_ice, sea_ice, floating_ice, ice shelves...
>
> Dear Bryan
>
>>> I see that the existing standard names of land_ice say that it
>>> means resting
>>> on bedrock. They were introduced before the floating_ice, which
>>> was intended
>>> from an atmospheric or oceanic point of view, when sea-ice and ice-
>>> shelves may
>>> have to be treated similarly. I propose that we redefine land_ice
>>> to mean
>>> glaciers, ice-sheets and ice-shelves; floating_ice can continue to
>>> mean sea-ice
>>> or ice-shelves, and we can introduce ice_shelf or
>>> grounded_land_ice if we
>>> need them.
>>
>> Without knowing the details I don't like the sound of "redefining".
>> Would there
>> be cases of existing data marked up with land_ice which would fall
>> foul of
>> such a change?
>
> Good question. I should have said, looking at those names, that I
> suspect not.
> I don't think CF is currently widely used for land ice (Glimmer
> supports it)
> and I think this issue would have come up before if someone wanted
> to deal with
> ice-shelves specifically. But if anyone knows of a case where making
> this
> redefinition would be a problem, they should speak up. I was
> responsible for
> the land_ice names, with Magnus Hagdorn, some years ago, and I guess
> that the
> intention of saying "resting on bedrock" was to make doubly clear we
> meant
> land-ice, not sea-ice, rather than to exclude ice-shelves. Magnus
> may have a
> view.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> --
> This message (and any attachments) is for the recipient only. NERC
> is subject to the Freedom of Information Act 2000 and the contents
> of this email and any reply you make may be disclosed by NERC unless
> it is exempt from release under the Act. Any material supplied to
> NERC may be stored in an electronic records management system.
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--------------
I have my new work email address: jgraybeal at ucsd.edu
--------------
John Graybeal <mailto:jgraybeal at ucsd.edu>
Ocean Observatories Initiative Cyberinfrastructure Project:
http://oceanobservatories.org
Marine Metadata Interoperability Project:
http://marinemetadata.org
---------------
John Graybeal
Marine Metadata Interoperability Project:
http://marinemetadata.org
graybeal at marinemetadata.org
Received on Wed Sep 30 2009 - 00:15:48 BST
