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] On Behalf Of
> Robert Muetzelfeldt [r.muetzelfeldt at ed.ac.uk]
> *Sent:* 13 September 2012 10:21
> *To:* 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
>> 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/20120914/1e5a87ca/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120914/1e5a87ca/attachment-0002.ksh>
Received on Fri Sep 14 2012 - 03:18:43 BST
