This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#95: Development of CF 1.5 Data Model -----------------------------+---------------------------------------------- Reporter: markh | Owner: [email protected] Type: task | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by bnl): Replying to [comment:82 rhattersley]: > Replying to [comment:81 bnl]: > > While I'm out of my comfort zone, I'm still not up for two semantic distinctions. What happens if I take variable "A" from file "afile" and variable B from file "bfile" and put them both in file "cfile". What then do I do with the global attributes from file "afile" and "bfile"? Do I leave them as semantically distinct global attributes of A and B? What if I do it again and put them in "dfile". What now has happened to all these (different) global attributes? > > Indeed. These are very good questions, and ones that have been nagging at me for quite some time. Having seen what happens when one takes the all-attributes-are-really-data-attributes approach (which is what we did with Iris), I'm now of the opinion that ''only the end-user knows''. All we should do is present the information (all of it!) and let them decide. > > > "file" attributes really only have useful meaning when variables all stay in the same containers ... and never get mixed and matched into differing output files. > > Just as CF doesn't attempt to describe what happens to data variable metadata when one processes a data variable, it shouldn't describe what happens to file metadata when one processess files. We agree on the problem :-). Not the solution :-). For me, there is no real concept of file metadata not withstanding the heading you referred to earlier. What there is is a concept of a convenience method of bundling variable metadata together for all variables in a file. The simplest solution would be to have the following BEHAVIOUR become conventional: when processing variables, take "file" metadata, and add tag it with the filename while assigning it to variables ... then when the variables travel, they at least have the provenance go with them ... but all such provenance are just variable attributes. One could then interpret something as taking precedence however one wanted. But, from a data model perspective, we just have variable attributes. What one does ones own workflow is your own convention ... sometimes we try and solve too many problems in CF itself. I think the act of trying to handle "file metadata" from a previous file in a future file as "file metadata" would be having us taking the wrong coloured pill ... -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:83> CF Metadata <http://cf-pcmdi.llnl.gov/> CF Metadata This message came from the CF Trac system. To unsubscribe, without unsubscribing to the regular cf-metadata list, send a message to "[email protected]" with "unsubscribe cf-metadata" in the body of your message.
