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 > (r...@bodc.ac.uk<mailto:r...@bodc.ac.uk>). > > Cheers, Roy. > ________________________________ > From: Robert Muetzelfeldt [r.muetzelfe...@ed.ac.uk] > Sent: 14 September 2012 10:18 > To: Lowry, Roy K. > Cc: cf-metadata@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-boun...@cgd.ucar.edu<mailto:cf-metadata-boun...@cgd.ucar.edu>] > On Behalf Of Robert Muetzelfeldt > [r.muetzelfe...@ed.ac.uk<mailto:r.muetzelfe...@ed.ac.uk>] > Sent: 13 September 2012 10:21 > To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@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@cgd.ucar.edu<mailto: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
