Hi All,
I agree too. The challenge is: how do we get there from here, and who will do
it, while maintaining backwards compatibility? That barrier has been too big.
Hence, my proposal is to leave what we have in place, and take a step which
will make our current lives easier, while gently refining the grammar over time
so that the next step will be easier.
One of the aspects of my proposal is that the parser/generator doesn't need to
be perfect, which will save a huge amount of effort. If we require that the
parser/generator for a new or existing std_name always correctly identifies
whether it conforms with grammar/vocab rules, I am sure a huge effort will be
needed to deal with a few difficult cases, such as those you have identified,
ie 90% of the effort will be to deal with 10% of the cases. By only requiring
that the parser/generator return whether a std_name is "probably valid" or
"can't be determined", those difficult cases are left to people on the email
list as normal. Thus, 10% effort will produce a 90% return, which is much more
likely to happen, and will put us on a better road for the future :-).
Best wishes,
Philip
-----------------------------------------------------------------------
Dr Philip Cameron-Smith, [email protected], Lawrence Livermore National Lab.
-----------------------------------------------------------------------
-----Original Message-----
From: CF-metadata [mailto:[email protected]] On Behalf Of
Schultz, Martin
Sent: Saturday, September 22, 2012 9:37 AM
To: Lowry, Roy K.; [email protected]
Subject: Re: [CF-metadata] Another potentially useful extension to the
standard_name table
Hi Roy,
exactly! Just how can we get there?
Cheers,
Martin
-----Ursprüngliche Nachricht-----
Von: Lowry, Roy K. [mailto:[email protected]]
Gesendet: Samstag, 22. September 2012 18:24
An: Schultz, Martin; [email protected]
Betreff: RE: [CF-metadata] Another potentially useful extension to the
standard_name table
Hello Martin,
I understand exactly what you want - or at least I thing I do. I think that
you would like to enter a URL representing the concept 'carbon monoxide' and
get back a document giving you all the Standard Names pertaining to carbon
monoxide. Am I right?
My vision - which I'm pretty sure John Graybeal shares - is of a grammar in
which each element is populated from a controlled vocabulary comprising
concepts that are included in a thesaurus or more likely a full-blown ontology.
Does that sound like what you need?
Cheers, Roy.
________________________________________
From: CF-metadata [[email protected]] On Behalf Of Schultz,
Martin [[email protected]]
Sent: 22 September 2012 16:26
To: [email protected]
Subject: Re: [CF-metadata] Another potentially useful extension to the
standard_name table
Dear Philip, John and others,
I take the point that indeed a grammar approach would be the solution to
my problem. However, the grammar as it once stood based on Jonathan's python
program (which indeed works quite nicely) unfortunately doesn't help with
respect to the problem that I intended to solve with the addition of
<attribute> tags (specifically <compound>). The problem is that the current
grammar, derived from parsing the standard_name table, does not take into
account semantic relations, but is strictly rule-based. Although I am not able
to prove this now, the experience I gathered with Jonathan's tool and the
associated lexicon suggests that it would require a major overhaul of the
standard_name table in order to make it "parseable" in a sense that the
relations among terms are not mere (computer) rule constructs, but make sense
for the human reader. In essence, this is why I opened track ticket #91.
Unfortunately, I haven't found the time yet to take this any further. ..
Personally, I am much less worried about the procedures for suggesting and
accepting standard_names. I fully agree that a grammar-based approach would
also help in this regard, but that is a different issue.
If I were in charge of creating a new standard_name table from scratch, I
would go for a rigorous grammar-based syntax, where (sorry to bring this up
again) the standard_name for "air_temperature" would be "temperature_of_air" in
order to identify the relation <propert<>of<medium>, etc. Indeed, in this
hypothetical standard_name table, one would define aliases and give them a more
prominent role than now, i.e. it would be fine to use "air_temperature"
(aliases should not be considered deprecated as is often the case in the
current table). The interoperable application could then look up the real
standard_name behind the alias and find something that can indeed be parsed -
eh voila: you get what you need, i.e. you will know that you have a property
and a medium, and that the property is "temperature" and the medium is "air".
Of course, I am not in charge if creating a new standard_name table (and I
am sure no one would like me to be in charge ;-), but I hope this illustrates
the problem we have with the current table. Sad as it seems, I really see only
two options: A) if most people agree that a grammar-based approach is the way
to go, then we need to start overhauling the standard_name table (track ticket
#91) and slowly transform it into something that "makes sense" (please don't
misunderstand this phrase!). Option B): we leave things as they are, but then
we would indeed have to further discuss the <attribute> idea, because this
would provide a way of interpreting standard_names without having to parse them
(which, as I hope to have made clear, is impossible at present).
I agree with the precautions that were raised in that the <attribute>s
pose some danger of becoming uncontrolled and simply too many. However, perhaps
it is not so bad, because the standard_names usually consist of no more than 6
lexical tokens, and if we could agree that there should be not more than one
<attribute> per lexical token (and these would anyhow be optional), then it
appears manageable and finite.
With somewhat Quichotte'sque feelings,
Martin
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
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
[email protected]
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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
