Hi Simon, et al.,
The question of semantic duplicates is something that CF has strongly tried to avoid. In a system where we control the grammar and vocabulary rather than the std_names, we would either need to design it so that semantic duplicates are impossible, or find a way to link equivalent terms.
Fortunately with my proposal this is not an issue because the primary control stays on the std_names. We should also learn whether semantic duplicates will be a problem before we make a final leap.
Best wishes,
Philip
-----------------------------------------------------------------------
Dr Philip Cameron-Smith, pjc at llnl.gov, Lawrence Livermore National Lab.
-----------------------------------------------------------------------
> -----Original Message-----
> From: Lowry, Roy K. [mailto:rkl at bodc.ac.uk]
> Sent: Monday, September 24, 2012 11:33 AM
> To: Simon.Cox at csiro.au; jgraybeal at ucsd.edu; Cameron-smith, Philip
> 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
>
> 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 - 13:11:01 BST
