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 spascoe): Replying to [comment:68 mgschultz]: > Dear all, > > so, if I understand correctly, then the issue is essentially whether or not to have a concept like "global attributes" in the CF data model. I would argue in favor of this, and generally in favor of supporting some sort of hierarchy in the data model. IMO Martin's argument is about encoding of the model. We need to define this encoding but it needs to be separated from the model. > There are reasons why HDF5 or netCDF4 allow for groups, and why global attributes were allowed in the first place. Also, any kind of XML metadata are hierarchical. Don't namespaces offer a solution here? > If we allow for a hierarchy of field constructs and attributes, then the rule "local overwrites global" can be implemented quite naturally, one can move attributes up or down the hierarchy level (up will require some rules), and thus the "encoding" of the data in a specific file format should create little problems. Without recognition of hierarchy levels there will be many more problems, I believe. > Naturally if our model is very close to the encoding it will make writing the data easier. However, it doesn't make reading it easier and it doesn't help describing the underlying concepts independent of the format. See below for my explanation. > Perhaps it is also useful to discuss this with an example: assume you have N models generating M data sets each from X experiments. Clearly there are metadata which are specific to a variable from the output of one experiment, metadata describing an experiment, others which are specific for a model, and finally some generic metadata describing the project, data center, etc. All of this can be reflected in a hierarchical model, but I fear that things (in particular changes) would easily get lost if all attributes are maintained at the variable level only. I think you are worrying too much about duplication of information when stored. This is an encoding issue; the model doesn't need to worry about the difference between 2 references to a piece of data and 2 identical copies of that data. From a data writer perspective your statement makes sense but from a data consumer less so. A user could access 2 CF field constructs from 2 separate files (or 2 separate services). Since they are encoded separately they cannot be physically part of the same hierarchy. How do you tell whether they were created by the same model? -- you have to compare the relevant field metadata for equality. That metadata may have been encoded in global attributes, variable attributes or generated dynamically from a service. The point is that the user doesn't need to know how it's encoded to interact with the model. Also, if we model a hierarchy we end up with multiple ways of representing a field construct in the model because many attributes could be defined at the global or variable level. You would then need a meta-model to define when 2 constructs are formally different but semantically the same. IMO the point of the data model is that it shouldn't need further abstraction. -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:69> 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.
