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
[EMAIL PROTECTED]
NARCCAP Data & User Community Manager
Associate Scientist
ISSE / NCAR
----
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:[EMAIL PROTECTED]> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project: http://marinemetadata.org
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
