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....@csiro.au [simon....@csiro.au] Sent: 24 September 2012 04:33 To: Lowry, Roy K.; jgrayb...@ucsd.edu; cameronsmi...@llnl.gov Cc: cf-metadata@cgd.ucar.edu; j.m.greg...@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:r...@bodc.ac.uk] Sent: Saturday, 22 September 2012 4:27 PM To: John Graybeal; Cameron-smith, Philip Cc: cf-metadata@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-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.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. _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
