Hello Simon,
If you're referring to syntactic duplicates then providing the controlled vocabularies covering the grammar elements are well managed the issue is addressed.
If you're referring to semantic duplicates (i.e. multiple Standard Names built from synonyms) then no, but there are opinions that have me 75% convinced that these are of little consequence in a linked data environment.
Cheers, Roy.
________________________________________
From: Simon.Cox at csiro.au [Simon.Cox at csiro.au]
Sent: 24 September 2012 04:33
To: Lowry, Roy K.; jgraybeal at ucsd.edu; cameronsmith1 at llnl.gov
Cc: cf-metadata at cgd.ucar.edu; j.m.gregory at reading.ac.uk
Subject: RE: [CF-metadata] Another potentially useful extension to the standard_name table
Sorry if this is an ignorant/newbie question, but can I ask if the grammar for CF std_names implicitly provides a check on duplicates?
Simon
-----Original Message-----
From: Lowry, Roy K. [mailto:rkl at bodc.ac.uk]
Sent: Saturday, 22 September 2012 4:27 PM
To: John Graybeal; Cameron-smith, Philip
Cc: cf-metadata at cgd.ucar.edu; Jonathan Gregory; Cox, Simon (CESRE, Kensington)
Subject: RE: [CF-metadata] Another potentially useful extension to the standard_name table
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-bounces at cgd.ucar.edu] On Behalf Of John Graybeal [jgraybeal at ucsd.edu]
Sent: 22 September 2012 00:09
To: Cameron-smith, Philip
Cc: cf-metadata at 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 at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata--
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
Received on Mon Sep 24 2012 - 12:33:18 BST
