Dear All, Just a reminder that I've been down this path with the parameter descriptions in http://vocab.ndg.nerc.ac.uk/list/P012/current (and the much bigger P011) that are built from between 10 and 25 semantic elements.
The approach I took was to make each element a controlled vocabulary and hold valid element combinations in a registry (to avoid Jonathan's nonsense known in oceanographic data management circles as the 'green dog issue'). The text strings in the name field are automatically built from the registry by concatenation, including 'joining words' to make something that reads sensibly. This approach could be used in CF, with the automatically generated strings being used to populate the Standard Name field. The system I have is based on a simple procedural language (PL/SQL) and took a couple of days to code. So a CF equivalent could feasably be built to create Standard Names from Karl's model. The main thing I have learnt from this is that the registry is essential. Without it we'd have had an unmanageable mess, particularly in the grey areas where opinions differ on what constitutes a valid combination. Cheers, Roy. >>> John Caron <[EMAIL PROTECTED]> 11/3/2008 3:33:02 pm >>> I would propose that we dont replace the current standard_name attribute, but explore alternative representations of their semantics. The goal would be to clarify the relationships of the various semantic components of a standard quantity, and to explore possible grammers for generating the name. While the end product of CF Conventions is to create specific metadata to be placed in data files, I think we often limit our thinking to the rather small set of representational forms that can be encoded into the netCDF-3 (aka classic) data model. To be specific, standard names are limited to being represented as char attributes, and so our dialogue about them sometimes seems limited to sequential "flat space" concepts. Of course actually we have an extremely rich associative semantic linkage in our minds. The idea, for me, would be to look for some richer representations of the associations and relationships between standard quantities, which could accelerate the process of constructing them. We can then decide if we want to encode these in a netcdf file using a single standard_name attribute and/or multiple "standard_name_component" attributes, auxiliary coordinates, common concepts, or even (god forbid) rdf triples. So I think we should start trying out different representations, and not make any big decisions, until/unless we have something that we like. Ok, I lied about the rfd triples inside of netcdf, that's not ok. ;^) _______________________________________________ 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
