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
Received on Sat Sep 22 2012 - 09:26:03 BST
