Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Lowry, Roy K.]

Hello Philip/John,

As John might remember, I attempted this approach a while back (I think I 
started in 2004) on another parameter vocabulary (the BODC vocabulary 
subsequently adopted by SeaDataNet).  I have yet to succeed in implementing it 
operationally.  This was because of two issues:

1) I never managed to derive a single model that described all the parameters 
in the dictionary - things like 'Concentration of PCB118 per unit wet weight of 
Mytilus edulis flesh' were particularly troublesome.
2) I simply ran out of energy building some of the vocabularies and never 
completed them

Admittedly, the problem was on a different scale - the vocab I was working on 
is ten times the size of the Standard Names list with a lot of biology in it. 
Further there are now standard resources available - such as WoRMS for taxon 
names that weren't mature then.  This brings me to the point that any 
development of grammar element vocabularies in CF should not be done in 
isolation, but should be sure to incorporate resources such as WoRMS for taxa, 
EEA for atmospheric pollutants and CAS for organic molecules.

However, there are other grammar-related vocabularies in CF such as the words 
used to express the amount of something in a matrix that should be in 
vocabularies that are totally under CF governance.  I totally agree that 
establishing these based on Jonathan's grammar would be a valuable step forward 
and would be happy to help do this.  This would be even more valuable if done 
in a collaborative manner that allowed a Standards Name List to be built from 
distributed semantic elements - or even interoperable semantic elements (nudge 
nudge wink wink!!).

As Philip suggests, an ideal kick-off for this process would be for Jonathan to 
prepare a grammar for the recently published Version 20 of Standard Names list 
and this time let's see if those of us in CF interested in parameter semantics 
can give his work the development it deserves.

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of John Graybeal 
[jgrayb...@ucsd.edu]
Sent: 22 September 2012 00:09
To: Cameron-smith, Philip
Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory
Subject: Re: [CF-metadata] Another potentially useful extension to the  
standard_name table

I like this.

I may be a step behind, but given a grammar parser/generator, we will have 
identified the slots. But we will not have identified all the terms that can 
fill those slots.

I don't think this is a huge challenge.  We will have (a) a list of terms 
already filling those slots, (b) candidate vocabularies that we could mine -- 
or designate -- or create -- to supply additional terms.  I would be delighted 
to participate in construction the list of terms and vocabularies.  (Especially 
if you let me use MMI to store them. Wink wink nudge nudge. :->)

Anyway, please correct me if I'm missing the boat, or tell me if there's 
already a plan.

John

On Sep 21, 2012, at 15:52, Cameron-smith, Philip wrote:

> Hi All,
>
> I am just catching up on the backlog of CF emails.  My sense too is that this 
> discussion is trying to solve the problems caused by a lack of grammar with 
> alternatives and/or stopgaps.  My preference is to overcome the grammar/vocab 
> challenge, but I am well aware that an accepted solution has not yet occurred.
>
> In order to get us on the right track, I propose we take advantage of 
> Jonathan's suggestion in a way that doesn't require a full grammar/vocab 
> definition, and doesn't require any changes to the controlling CF documents.
>
> Specifically, I propose the following:
>
> 1) We leverage Jonathan's grammar program into (a) a program that checks a 
> proposed std_name by parsing it to see whether it fits existing grammar/vocab 
> rules, and/or (b) a std_name generation program.
>
> 2) Std_names are still proposed in the ordinary way, but if they have passed 
> the checker or been created through the generator then it will be easy for 
> people to accept them.  We might even move to a mode in which pre-approved 
> std_names are automatically accepted after a month, unless someone objects.
>
> This has several advantages:
>
> A) It will reduce time and effort by everyone to get std_names approved.
> B) Neither the parser nor the generator needs to be complete (ie, it is OK if 
> some existing names don't comply, or there are some valid new cases they 
> don't cover)
> C) Proposals that don't fit the standard construction can still be approved, 
> and will highlight ways to complete and extend the parser/generator.
> D) Any mistakes by the parser/generator should be caught by the email list.
>
> I see no disadvantages other than the need for someone to create the parser 
> and/or generator, which should be technically straightforward.
>
> Best wishes,
>
>   Philip

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Schultz, Martin]

Dear Philip, John and others,

  I take the point that indeed a grammar approach would be the solution to 
my problem. However, the grammar as it once stood based on Jonathan's python 
program (which indeed works quite nicely) unfortunately doesn't help with 
respect to the problem that I intended to solve with the addition of 
 tags (specifically ). The problem is that the current 
grammar, derived from parsing the standard_name table, does not take into 
account semantic relations, but is strictly rule-based. Although I am not able 
to prove this now, the experience I gathered with Jonathan's tool and the 
associated lexicon suggests that it would require a major overhaul of the 
standard_name table in order to make it "parseable" in a sense that the 
relations among terms are not mere (computer) rule constructs, but make sense 
for the human reader. In essence, this is why I opened track ticket #91. 
Unfortunately, I haven't found the time yet to take this any further. ..

Personally, I am much less worried about the procedures for suggesting and 
accepting standard_names. I fully agree that a grammar-based approach would 
also help in this regard, but that is a different issue.

If I were in charge of creating a new standard_name table from scratch, I 
would go for a rigorous grammar-based syntax, where (sorry to bring this up 
again) the standard_name for "air_temperature" would be "temperature_of_air" in 
order to identify the relation of, etc. Indeed, in this 
hypothetical standard_name table, one would define aliases and give them a more 
prominent role than now, i.e. it would be fine to use "air_temperature" 
(aliases should not be considered deprecated as is often the case in the 
current table). The interoperable application could then look up the real 
standard_name behind the alias and find something that can indeed be parsed - 
eh voila: you get what you need, i.e. you will know that you have a property 
and a medium, and that the property is "temperature" and the medium is "air".

Of course, I am not in charge if creating a new standard_name table (and I 
am sure no one would like me to be in charge ;-), but I hope this illustrates 
the problem we have with the current table. Sad as it seems, I really see only 
two options: A) if most people agree that a grammar-based approach is the way 
to go, then we need to start overhauling the standard_name table (track ticket 
#91) and slowly transform it into something that "makes sense" (please don't 
misunderstand this phrase!). Option B): we leave things as they are, but then 
we would indeed have to further discuss the  idea, because this 
would provide a way of interpreting standard_names without having to parse them 
(which, as I hope to have made clear, is impossible at present).

  I agree with the precautions that were raised in that the s 
pose some danger of becoming uncontrolled and simply too many. However, perhaps 
it is not so bad, because the standard_names usually consist of no more than 6 
lexical tokens, and if we could agree that there should be not more than one 
 per lexical token (and these would anyhow be optional), then it 
appears manageable and finite.

With somewhat Quichotte'sque feelings,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Lowry, Roy K.]

Hello Martin,

I understand exactly what you want - or at least I thing I do.  I think that 
you would like to enter a URL representing the concept 'carbon monoxide' and 
get back a document giving you all the Standard Names pertaining to carbon 
monoxide.  Am I right?

My vision - which I'm pretty sure John Graybeal shares - is of a grammar in 
which each element is populated from a controlled vocabulary comprising 
concepts that are included in a thesaurus or more likely a full-blown ontology.

Does that sound like what you need?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 22 September 2012 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the 
standard_name table

Dear Philip, John and others,

  I take the point that indeed a grammar approach would be the solution to 
my problem. However, the grammar as it once stood based on Jonathan's python 
program (which indeed works quite nicely) unfortunately doesn't help with 
respect to the problem that I intended to solve with the addition of 
 tags (specifically ). The problem is that the current 
grammar, derived from parsing the standard_name table, does not take into 
account semantic relations, but is strictly rule-based. Although I am not able 
to prove this now, the experience I gathered with Jonathan's tool and the 
associated lexicon suggests that it would require a major overhaul of the 
standard_name table in order to make it "parseable" in a sense that the 
relations among terms are not mere (computer) rule constructs, but make sense 
for the human reader. In essence, this is why I opened track ticket #91. 
Unfortunately, I haven't found the time yet to take this any further. ..

Personally, I am much less worried about the procedures for suggesting and 
accepting standard_names. I fully agree that a grammar-based approach would 
also help in this regard, but that is a different issue.

If I were in charge of creating a new standard_name table from scratch, I 
would go for a rigorous grammar-based syntax, where (sorry to bring this up 
again) the standard_name for "air_temperature" would be "temperature_of_air" in 
order to identify the relation of, etc. Indeed, in this 
hypothetical standard_name table, one would define aliases and give them a more 
prominent role than now, i.e. it would be fine to use "air_temperature" 
(aliases should not be considered deprecated as is often the case in the 
current table). The interoperable application could then look up the real 
standard_name behind the alias and find something that can indeed be parsed - 
eh voila: you get what you need, i.e. you will know that you have a property 
and a medium, and that the property is "temperature" and the medium is "air".

Of course, I am not in charge if creating a new standard_name table (and I 
am sure no one would like me to be in charge ;-), but I hope this illustrates 
the problem we have with the current table. Sad as it seems, I really see only 
two options: A) if most people agree that a grammar-based approach is the way 
to go, then we need to start overhauling the standard_name table (track ticket 
#91) and slowly transform it into something that "makes sense" (please don't 
misunderstand this phrase!). Option B): we leave things as they are, but then 
we would indeed have to further discuss the  idea, because this 
would provide a way of interpreting standard_names without having to parse them 
(which, as I hope to have made clear, is impossible at present).

  I agree with the precautions that were raised in that the s 
pose some danger of becoming uncontrolled and simply too many. However, perhaps 
it is not so bad, because the standard_names usually consist of no more than 6 
lexical tokens, and if we could agree that there should be not more than one 
 per lexical token (and these would anyhow be optional), then it 
appears manageable and finite.

With somewhat Quichotte'sque feelings,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app
___
CF-metadata maili

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Schultz, Martin]

Hi Roy,

 exactly!Just how can we get there?

Cheers,

Martin

-Ursprüngliche Nachricht-
Von: Lowry, Roy K. [mailto:r...@bodc.ac.uk] 
Gesendet: Samstag, 22. September 2012 18:24
An: Schultz, Martin; cf-metadata@cgd.ucar.edu
Betreff: RE: [CF-metadata] Another potentially useful extension to the 
standard_name table

Hello Martin,

I understand exactly what you want - or at least I thing I do.  I think that 
you would like to enter a URL representing the concept 'carbon monoxide' and 
get back a document giving you all the Standard Names pertaining to carbon 
monoxide.  Am I right?

My vision - which I'm pretty sure John Graybeal shares - is of a grammar in 
which each element is populated from a controlled vocabulary comprising 
concepts that are included in a thesaurus or more likely a full-blown ontology.

Does that sound like what you need?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 22 September 2012 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the 
standard_name table

Dear Philip, John and others,

  I take the point that indeed a grammar approach would be the solution to 
my problem. However, the grammar as it once stood based on Jonathan's python 
program (which indeed works quite nicely) unfortunately doesn't help with 
respect to the problem that I intended to solve with the addition of 
 tags (specifically ). The problem is that the current 
grammar, derived from parsing the standard_name table, does not take into 
account semantic relations, but is strictly rule-based. Although I am not able 
to prove this now, the experience I gathered with Jonathan's tool and the 
associated lexicon suggests that it would require a major overhaul of the 
standard_name table in order to make it "parseable" in a sense that the 
relations among terms are not mere (computer) rule constructs, but make sense 
for the human reader. In essence, this is why I opened track ticket #91. 
Unfortunately, I haven't found the time yet to take this any further. ..

Personally, I am much less worried about the procedures for suggesting and 
accepting standard_names. I fully agree that a grammar-based approach would 
also help in this regard, but that is a different issue.

If I were in charge of creating a new standard_name table from scratch, I 
would go for a rigorous grammar-based syntax, where (sorry to bring this up 
again) the standard_name for "air_temperature" would be "temperature_of_air" in 
order to identify the relation of, etc. Indeed, in this 
hypothetical standard_name table, one would define aliases and give them a more 
prominent role than now, i.e. it would be fine to use "air_temperature" 
(aliases should not be considered deprecated as is often the case in the 
current table). The interoperable application could then look up the real 
standard_name behind the alias and find something that can indeed be parsed - 
eh voila: you get what you need, i.e. you will know that you have a property 
and a medium, and that the property is "temperature" and the medium is "air".

Of course, I am not in charge if creating a new standard_name table (and I 
am sure no one would like me to be in charge ;-), but I hope this illustrates 
the problem we have with the current table. Sad as it seems, I really see only 
two options: A) if most people agree that a grammar-based approach is the way 
to go, then we need to start overhauling the standard_name table (track ticket 
#91) and slowly transform it into something that "makes sense" (please don't 
misunderstand this phrase!). Option B): we leave things as they are, but then 
we would indeed have to further discuss the  idea, because this 
would provide a way of interpreting standard_names without having to parse them 
(which, as I hope to have made clear, is impossible at present).


  I agree with the precautions that were raised in that the s 
pose some danger of becoming uncontrolled and simply too many. However, perhaps 
it is not so bad, because the standard_names usually consist of no more than 6 
lexical tokens, and if we could agree that there should be not more than one 
 per lexical token (and these would anyhow be optional), then it 
appears manageable and finite.

With somewhat Quichotte'sque feelings,

Martin






Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke 
(stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Seb

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[Cameron-smith, Philip]

Hi All,

I agree too.  The challenge is: how do we get there from here, and who will do 
it, while maintaining backwards compatibility?  That barrier has been too big.  

Hence, my proposal is to leave what we have in place, and take a step which 
will make our current lives easier, while gently refining the grammar over time 
so that the next step will be easier. 

One of the aspects of my proposal is that the parser/generator doesn't need to 
be perfect, which will save a huge amount of effort.  If we require that the 
parser/generator for a new or existing std_name always correctly identifies 
whether it conforms with grammar/vocab rules, I am sure a huge effort will be 
needed to deal with a few difficult cases, such as those you have identified, 
ie 90% of the effort will be to deal with 10% of the cases.  By only requiring 
that the parser/generator return whether a std_name is "probably valid" or 
"can't be determined", those difficult cases are left to people on the email 
list as normal.  Thus, 10% effort will produce a 90% return, which is much more 
likely to happen, and will put us on a better road for the future :-).

Best wishes,

   Philip

---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
---

-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
Schultz, Martin
Sent: Saturday, September 22, 2012 9:37 AM
To: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the 
standard_name table

Hi Roy,

 exactly!Just how can we get there?

Cheers,

Martin

-Ursprüngliche Nachricht-
Von: Lowry, Roy K. [mailto:r...@bodc.ac.uk] 
Gesendet: Samstag, 22. September 2012 18:24
An: Schultz, Martin; cf-metadata@cgd.ucar.edu
Betreff: RE: [CF-metadata] Another potentially useful extension to the 
standard_name table

Hello Martin,

I understand exactly what you want - or at least I thing I do.  I think that 
you would like to enter a URL representing the concept 'carbon monoxide' and 
get back a document giving you all the Standard Names pertaining to carbon 
monoxide.  Am I right?

My vision - which I'm pretty sure John Graybeal shares - is of a grammar in 
which each element is populated from a controlled vocabulary comprising 
concepts that are included in a thesaurus or more likely a full-blown ontology.

Does that sound like what you need?

Cheers, Roy.


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 22 September 2012 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the 
standard_name table

Dear Philip, John and others,

  I take the point that indeed a grammar approach would be the solution to 
my problem. However, the grammar as it once stood based on Jonathan's python 
program (which indeed works quite nicely) unfortunately doesn't help with 
respect to the problem that I intended to solve with the addition of 
 tags (specifically ). The problem is that the current 
grammar, derived from parsing the standard_name table, does not take into 
account semantic relations, but is strictly rule-based. Although I am not able 
to prove this now, the experience I gathered with Jonathan's tool and the 
associated lexicon suggests that it would require a major overhaul of the 
standard_name table in order to make it "parseable" in a sense that the 
relations among terms are not mere (computer) rule constructs, but make sense 
for the human reader. In essence, this is why I opened track ticket #91. 
Unfortunately, I haven't found the time yet to take this any further. ..

Personally, I am much less worried about the procedures for suggesting and 
accepting standard_names. I fully agree that a grammar-based approach would 
also help in this regard, but that is a different issue.

If I were in charge of creating a new standard_name table from scratch, I 
would go for a rigorous grammar-based syntax, where (sorry to bring this up 
again) the standard_name for "air_temperature" would be "temperature_of_air" in 
order to identify the relation of, etc. Indeed, in this 
hypothetical standard_name table, one would define aliases and give them a more 
prominent role than now, i.e. it would be fine to use "air_temperature" 
(aliases should not be considered deprecated as is often the case in the 
current table). The interoperable application could then look up the real 
standard_name behind the alias and find something that can indeed be parsed - 
eh voila: you get what you need, i.e. you will know that you have a property 
and a medium, and that the property is "temperature" and the medium is "air".

Of course, I am not in charge if creating a new standard_name table (an

Re: [CF-metadata] Another potentially useful extension to the standard_name table

[John Graybeal]

I think Roy's subsequent emails have correctly seized the essence of my first 
comment.

MMI is a colloquial term (sorry) for the vocabulary service run by the Marine 
Metadata Interoperability project, at mmisw.org.  Its services are accessed 
from anywhere, the vocabularies are stored at the server. Vocabularies 
modifications are limited to the author, at the moment anyway.

Complete integration of the resulting vocabularies (wherever they live -- MMI 
was simply one example) into CF tools could call for additional development, 
but the integrated services would provide a nicely unified capability.

John


On Sep 21, 2012, at 16:24, Cameron-smith, Philip wrote:

> Hi John,
> 
> Jonathan's program already generated the vocab from the existing names 
> (hopefully we can prevail on Jonathan to run it on the latest CF version).  
> That should seed the program(s).  Vocab could then be added as desired.   
> 
> For the program to have staying power, it will be necessary that the grammar 
> also be easy to amend and extend.
> 
> What is MMI?
> Would it be run locally, or via the web, or both?
> 
> Best wishes,
> 
> Philip
> 
> 
> ---
> Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
> ---
> 
> 
> 
>> -Original Message-
>> From: John Graybeal [mailto:jgrayb...@ucsd.edu]
>> Sent: Friday, September 21, 2012 4:10 PM
>> To: Cameron-smith, Philip
>> Cc: Jonathan Gregory; cf-metadata@cgd.ucar.edu
>> Subject: Re: [CF-metadata] Another potentially useful extension to the
>> standard_name table
>> 
>> I like this.
>> 
>> I may be a step behind, but given a grammar parser/generator, we will have
>> identified the slots. But we will not have identified all the terms that can 
>> fill
>> those slots.
>> 
>> I don't think this is a huge challenge.  We will have (a) a list of terms 
>> already
>> filling those slots, (b) candidate vocabularies that we could mine -- or 
>> designate -
>> - or create -- to supply additional terms.  I would be delighted to 
>> participate in
>> construction the list of terms and vocabularies.  (Especially if you let me 
>> use
>> MMI to store them. Wink wink nudge nudge. :->)
>> 
>> Anyway, please correct me if I'm missing the boat, or tell me if there's 
>> already a
>> plan.
>> 
>> John
>> 
>> On Sep 21, 2012, at 15:52, Cameron-smith, Philip wrote:
>> 
>>> Hi All,
>>> 
>>> I am just catching up on the backlog of CF emails.  My sense too is that 
>>> this
>> discussion is trying to solve the problems caused by a lack of grammar with
>> alternatives and/or stopgaps.  My preference is to overcome the
>> grammar/vocab challenge, but I am well aware that an accepted solution has
>> not yet occurred.
>>> 
>>> In order to get us on the right track, I propose we take advantage of
>> Jonathan's suggestion in a way that doesn't require a full grammar/vocab
>> definition, and doesn't require any changes to the controlling CF documents.
>>> 
>>> Specifically, I propose the following:
>>> 
>>> 1) We leverage Jonathan's grammar program into (a) a program that checks a
>> proposed std_name by parsing it to see whether it fits existing grammar/vocab
>> rules, and/or (b) a std_name generation program.
>>> 
>>> 2) Std_names are still proposed in the ordinary way, but if they have passed
>> the checker or been created through the generator then it will be easy for
>> people to accept them.  We might even move to a mode in which pre-approved
>> std_names are automatically accepted after a month, unless someone objects.
>>> 
>>> This has several advantages:
>>> 
>>> A) It will reduce time and effort by everyone to get std_names approved.
>>> B) Neither the parser nor the generator needs to be complete (ie, it is OK 
>>> if
>> some existing names don't comply, or there are some valid new cases they 
>> don't
>> cover)
>>> C) Proposals that don't fit the standard construction can still be 
>>> approved, and
>> will highlight ways to complete and extend the parser/generator.
>>> D) Any mistakes by the parser/generator should be caught by the email list.
>>> 
>>> I see no disadvantages other than the need for someone to create the parser
>> and/or generator, which should be technically straightforward.
>>> 
>>> Best wishes,
>>> 
>>>  Philip
> 



John Graybeal phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project: 
http://ci.oceanobservatories.org
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