Fine by me.
Cheers, Roy.
________________________________
From: Bryan Lawrence [bryan at greenlip.org.uk]
Sent: 17 September 2012 10:34
To: cf-metadata at cgd.ucar.edu
Cc: Lowry, Roy K.; Robert Muetzelfeldt
Subject: Re: [CF-metadata] Another potentially useful extension to the standard_name table
Hi Roy
I'd vote for having the discussion about setting up a project to deliver this "on list" ...
Cheers
Bryan
>
> Hello Robert,
>
> To my mind, data modelling of standard names should be based on the type of approach you've been advocating.
>
> Good point concerning expressions of interest. If people want to keep the CF list traffic a bit lighter then contact me directly (rkl at bodc.ac.uk<mailto:rkl at bodc.ac.uk>).
>
> Cheers, Roy.
> ________________________________
> From: Robert Muetzelfeldt [r.muetzelfeldt at ed.ac.uk]
> Sent: 14 September 2012 10:18
> To: Lowry, Roy K.
> Cc: cf-metadata at cgd.ucar.edu; Brown, Juan
> Subject: Re: [CF-metadata] Another potentially useful extension to the standard_name table
>
> Hello Roy,
>
> On 14/09/12 08:23, Lowry, Roy K. wrote:
> Dear All,
>
> I am becoming concerned that a 'design by committee' data modelling process for Standard Names is unfolding on the list.
>
> The risk is that this will result in a series of disjoint extensions with significant semantic overlap hung off the standard name. I can already see this happening with Martin's 'compound' concept and Jonathan's 'species' concept.
> Well, that's a good reason for developing a semantic-grammar approach for representing standard names, something I've been arguing for for some time. It avoids these ad-hoc extensions, which are also much less expressive than a grammar. (Commenting on the XML design does not mean that I endorse the use of extensions...).
>
> Such a process is the inevitable result of the 'best efforts' culture that underpins CF. For example, Martin is driven to present an XML encoding rather than a use case because he knows that an encoding has more chance of being taken forward than a use case.
>
> This leads to ask the question whether there is any possibility of our doing the job properly. Who would be interested in getting involved? Is there any possibility of putting together a consortium to develop a proposal for funding to do the job? I know one golden opportunity for such a process has just passed by, but others will undoubtedly come along.
> This is a good idea, and I'd be happy to join in. What process do you want for eliciting members and taking things forward: this list, or do you want people to contact you off-list?
>
> Cheers,
> Robert
>
>
> Cheers, Roy.
> ________________________________
> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu<mailto:cf-metadata-bounces at cgd.ucar.edu>] On Behalf Of Robert Muetzelfeldt [r.muetzelfeldt at ed.ac.uk<mailto:r.muetzelfeldt at ed.ac.uk>]
> Sent: 13 September 2012 10:21
> To: cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>
> Subject: Re: [CF-metadata] Another potentially useful extension to the standard_name table
>
> Hi Martin,
>
> Is there some reason why the <entry> element must have a flat set of sub-elements, as in your example below? It seems to me that from an XML data-design point-of-view, a neater data model would be:
> <entry id="...">
> <compound_name>...</compound_name> See note [1] below
> <compound_codelist>...</compound_codelist>
> <canonical_units> ... see note [2] below ...</canonical_units>
> <description>...</description>
> <attribute_list>
> <attribute status="recommended" name="emission_sector"/>
> <attribute status="recommended" name="emission_sector_reference"/>
> <attribute status="recommended" name="compound_group_members"/>
> <attribute status="optional" name="comments"/>
> </attribute_list>
> </entry>
>
> This design is:
> - more in keeping with conventional XML designs;
> - allows for additional forms of 'status' without changing the DTD/Schema;
> - facilitates processing (you are parsing *only* XML; you don't need separate code to parse
> the text string for each of your 3 original elements).
>
> It is a matter of taste as to whether you prefer the above design of the <attribute> element (i.e. with two (XML) attributes), or whether you would prefer to have 'status' and 'name' as two sub-elements of <attribute>.
>
> The following notes are not directly relevant to your suggestion, but I might as well make the points now:
>
> Note [1]
> A similar argument as the above applies to the two <compound_...> elements, which would I think be better represented as:
> <compound name="..." codelist="..."/>
> or
> <compound>
> <name>...</name>
> <codelist>...</codelist>
> </compound>
> But it may be that this decision is already fixed in stone.
>
> Note [2]
> A similar argument applies to <canonical_units>, except here I think the principled approach would be to use the W3C Units in MathML ( http://www.w3.org/TR/mathml-units/) or UnitsML ( http://unitsml.nist.gov/), since both represent a concerted effort to develop a standard for representing units in a machine-processable format. I can think of several reasons why people might object vigourously to either solution: the current design is also already fixed in stone; it is harder to write my hand; it is harder for humans to read; it is much more verbose; and possibly quite simply that <entry> may have to have a flat list of sub-elements (as per the first sentence of this email). However, these standards exist for a good reason, and we should have a good reason for not adopting them.
>
> Cheers,
> Robert
>
>
>
> On 13/09/12 08:09, Schultz, Martin wrote:
> Dear all,
>
> during the recent discussion on ?compound_name? as additional tag in the standard_names.xml file and in relation to track ticket #90 it occurred to me that another useful addition could be to express the ?need? of certain variable attributes in this table as well. This refers to the attempt of creating a ?CF-1.6-strict? standard which would have more things mandatory in order to better support interoperable applications.
>
> One example (related to the new emission standard_names) could be:
>
>
> -<entry id=" tendency_of_atmosphere_mass_content_of_alcohols_due_to_emission_from_industrial_processes_and_combustion">
> <compound_name>Alcohols</compound_name>
> <compound_codelist>http://rdfdata.eionet.europa.eu/airquality/components/??</compound_codelist<http://rdfdata.eionet.europa.eu/airquality/components/??%3c/compound_codelist>> # ??
> <canonical_units>kg m-2 s-1</canonical_units>
> <description>"?? </description>
> <required_attributes>None</required_attributes>
> <recommended_attributes>emission_sector, emission_sector_reference, compound_group_members</recommended_attributes>
> <optional_attributes>comments</optional_attributes>
> </entry>
>
> The idea is that ?optional? refers to ?could? in the description, ?recommended? to ?should?, and ?required? to ?shall?.
>
> Best regards,
>
> Martin
>
>
> PD Dr. Martin G. Schultz
> IEK-8, Forschungszentrum J?lich
> D-52425 J?lich
> Ph: +49 2461 61 2831
>
>
>
> ------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------
> 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 at cgd.ucar.edu<mailto: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.
>
>
> --
> -----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120917/e2448ffc/attachment-0001.html>
Received on Mon Sep 17 2012 - 08:37:08 BST
