Seth,
That's an entertainingly close description of the semantic
interoperability framework [1] and workshop [2] that MMI is proposing
and offering for marine and related environmental sciences.
(apologies for the plug, but it sure seemed relevant) So you'll have
my full support for that concept.
The interesting and subtle distinction between MMI's approach, and
what I think you're implying is that there would be a single authority
(CF) tying together all those names (e.g., using the CF aliases to
bring the names from different namespaces together). There are two
ways to do that, but I don't think aliases or a 'single authority' (in
the way you imply it) is the right model.
I think a better model is to consider the CF standard names one of the
major namespaces, to which many other vocabularies can be mapped.
Then, modify the CF standard to allow the specification of a term from
any namespace (since many terms may not be appropriate to the CF
vocabulary; see my comment on CF scope in the last post); this is a
proposal I've been back-burnering for about 9 months now. Finally, CF
can accept any or all well-framed names that are in any of these
namespaces, or can even alias to them, through manual or semi-
automated processes.
Under this model, CF has a mind share on solving this problem with a
particular approach, but CF users can take advantage of other
approaches. CF doesn't have to take on the 'vocabulary publication and
mediation' task for the entire community, but can pick and choose its
own targets for inclusion in the CF vocabulary (and the targets will
be much more conspicuous and contextually defined).
There are multiple complexities that arise as you start trying to make
this concept (mine, yours, or CF's) work -- I like to think our MMI
plans know about 85% of the issues in a fully operational but basic
system -- and it isn't clear whether you'll want many organizations
serving the results, or relatively few. But the model can put a lot
more precise naming and mapping capability into action in a very short
period of time (we hope to go live in a matter of weeks), and should
make clear the difference in scope between what CF is currently
addressing, and what needs to be accommodated.
Having said all that, I would like CF's model of "meaningful,
coherent, well-structured names" to be a paradigm that is maintained.
If one group uses opaque codes, I would rather not see CF start
including those just because they are acceptable to some. One of CF's
big strengths is the "instant interoperability" you get from
recognizing and understanding the name.
John
[1]
http://marinemetadata.org/semanticframeworkconcept (many of the
planned concepts are not fully documented yet)
[2]
http://marinemetadata.org/events/oossi (sign up soon if you want
good hotel rates!)
On Oct 20, 2008, at 11:40 AM, Seth McGinnis wrote:
>> I don't know if this is supportive or not, but the "sheer number
>> of groups bringing new requirements" is an issue that I don't
>> think CF has realistically addressed.
>
>
> With regard to the standard names problem, here's a perhaps-mad idea
> from someone standing on the sidelines. I don't think this idea has
> been floated before, but I may have missed it.
>
> Where I'm coming from: I'm the data manager for a modeling project
> (NARCCAP, http://narccap.ucar.edu) that's using the CF standard. I
> don't generate or use any of the project's data, I'm just in charge
> of checking it to make sure it's properly formatted and trying to
> make things usable for the community that will use the data. From
> my perspective, the really important thing about standard names is
> that if two different files have a variable with the same standard
> name, it means (1) they're talking about the same thing, and (2) a
> user can go somewhere and look up the definition and the canonical
> units. The fact that the name has passed through an approval
> process is entirely incidental.
>
> So... why not just let any group that wants to define a set of
> standard names for their community do so, as long as they're willing
> to also take charge of publishing a Standard Name Table for it?
>
> Essentially, it would be creating namespaces. The only mechanism
> that would need to be added would be some way of noting which
> namespace the name comes from and the URL of the corresponding
> Standard Name Table. So, for example, maybe for chemical names, all
> the standard names would all start with "iupac:" and somewhere in
> the global attributes for the file you'd have "standard_namespaces =
> (default: cf-pcmdi.llnl.gov/cf-standard-name-table.xml, chem: www.iupac.org/cf/standard-names-3.0.xml)
> ". Or something like that.
>
> Each community can manage its own namespace. There's already a
> mechanism in place (aliases) that could be extended to handle cases
> where there are two different names for one thing. And if you end
> up with two names for the same thing with different dimensions or
> slightly different definitions, that's fine, because that situation
> already exists in the single table. (Rain, for example, can be
> defined as a mass flux per unit area (precipitation_flux) or as an
> accumulated depth (lwe_thickness_of_precipitation_amount). They're
> different ways of talking about the same physical thing. So this is
> not a new problem for the user.)
>
> Put some bounds on the representational domain that the default
> standard name table will handle, delegate everything else to whoever
> in that community wants to deal with it, and no matter how many
> groups come to CF with new standard names, the system can handle
> it. Right?
>
> Cheers,
>
> --Seth
>
> ----
> Seth McGinnis
> mcginnis at ucar.edu
> NARCCAP Data & User Community Manager
> Associate Scientist
> ISSE / NCAR
> ----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Mon Oct 20 2008 - 13:22:06 BST
