Hello All,
This is heading directly towards where I was trying to steer
common_concept in particular (Trac Ticket #24), and where the
namespace discussion went more generally (Trac Ticket #27). There is
a need for a framework for using namespaces in netcdf, both with the
attributes (so attributes can be explicitly placed in different
conventions, not the issue here per se), and attribute values (so that
attributes can point to URI's identifying concepts). My short
version of this is that cf:standard_name is a property that points to
a single controlled vocabulary (i.e. a string chosen from a list),
while the proposed cf:common_concept is a property that points to
concepts identified with URI's (e.g. namespace plus value).
standard_name's could have URI's as well (Roy Lowry has assigned
opaque URI's to all the standard names, MMI has assigned more readable
URIs to many of the standard_names (e.g. cf:air_temperature), CF could
very well get a URN space of its own which will allow it to create
some definitive URIs, which lets us relate cf:standard_name's to other
vocabularies (Roy has done this as well), and would let us write down
relationships between standard_names (Roy is working on this).
The attribute namespace problem is easier, and we discussed a couple
of possible solutions which we hope to sort out by actually
implementing them. namespaces for values seems trickier at the
moment, because netcdf (unlike DAP) does not have a URI datatype, and
so even if one had a list of namespaces specified as id #24, one would
not be sure which string-valued properties have been
namespace-abbreviated without reading through some document that
describes each property in the convention, a level of sophistication
in the reading software we would like to avoid. Of course, one does
not need to abbreviate -- a URN in particular should be quite readable
in its entirety.
Benno
On Mon, Oct 20, 2008 at 3:22 PM, John Graybeal <graybeal at mbari.org> wrote:
> 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
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Dr. M. Benno Blumenthal benno at iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
Received on Tue Oct 21 2008 - 09:24:37 BST
