Hi Robert,
very good points! I like this idea of hierarchical <attribute>...</attribute> and <compound>...</compound> structures. I just don't speak XML well enough myself yet ;-) Only for the canonical_units things are set in stone already, all other things are just beginning to be defined.
Just one question/comment, though: if we plan on further extending this concept beyond <compound>, wouldn't it then make sense to generalize this further? Example:
<controlled_item id="compound">
<name>trimethylbenzene</name>
<codelist>...</codelist>
</controlled_item>
etc. ? Or would this make it again more difficult to parse?
Cheers,
Martin
Von: Robert Muetzelfeldt [mailto:r.muetzelfeldt at ed.ac.uk]
Gesendet: Donnerstag, 13. September 2012 21:50
An: Schultz, Martin
Betreff: Fwd: Re: [CF-metadata] Another potentially useful extension to the standard_name table: OFFLINE RESPONSE
Hi Martin,
I sent the following response to your email to the list this morning, but it has not yet appeared (being moderated? - but I've posted OK before). So I thought I would send you the reply directly, so you can be thinking about it. If it's wrong/irrelevant/unworkable (given existing constraints in the XML Schema or tools for handling these documents), then do feel free to say so when my email eventually appears on the list. I won't be upset.
Cheers,
Robert
-------- Original Message --------
Subject:
Re: [CF-metadata] Another potentially useful extension to the standard_name table
Date:
Thu, 13 Sep 2012 10:21:13 +0100
From:
Robert Muetzelfeldt <r.muetzelfeldt at ed.ac.uk><mailto:r.muetzelfeldt at ed.ac.uk>
To:
cf-metadata at cgd.ucar.edu<mailto:cf-metadata at cgd.ucar.edu>
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
--
-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120914/10f1e11e/attachment-0001.html>
Received on Fri Sep 14 2012 - 01:07:51 BST
