Let me just add that a URI datatype is useful not just for external
references, but it is also useful for local references as well, e.g.
instead of cf:grid_mapping being a string that is the name of a local
variable, it would be a URI that points to a local variable (i.e.
probably still that same variable name). Seemingly a minor
distinction, but it allows a clean mapping into an object-oriented
framework for information in netcdf files. LIke RDF, or Java Beans,
or ...
Benno
On Tue, Oct 21, 2008 at 11:24 AM, Benno Blumenthal
<benno at iri.columbia.edu> wrote:
> 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
>
--
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 - 16:51:07 BST
