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 markh):

 Replying to [comment:89 taylor13]:
 > Hi all,
 >
 > Just to note one use case (CMIP5 specifications) where, perhaps
 mistakenly, it was assumed that attributes appearing both as global and
 (with different text) as variable would be concatenated to provide more
 complete information.  The assumption wasn't that if the variable
 attribute was present it would supersede/override the global one.  Note
 that the description below distinguishes between types of information that
 might appear in comment and history attributes which would be common among
 variables vs. different from one variable to the next.

 For what it is worth, I took a similar interpretation to the CMIP5
 guidance.

 I interpreted

  'takes
 [http://dictionary.cambridge.org/dictionary/british/precedence?q=precedence
 precedence]'

 to mean that the data variable attribute was to be treated as having
 primacy, having more import than the global variable attribute.  This is
 different from saying that the global attribute in this case: has no
 meaning / is overridden / is ignored, if a data variable has an variable
 attribute with the same name.

 I think it is useful to work with CF data variables as independent
 entities, so I think we should look to apply file global attributes to
 data variables.

 I think there is some semantic content is the information encoding
 approach in numerous cases so I think there is value in having two
 attribute containers, perhaps 'data_attrs' and 'inherited_attrs' so that
 we can preserve the source of these attributes and provide a mechanism for
 controlling how NetCDF files are written from Field instances.

 They are all attributes on the Field, in this view, there just happen to
 be two types  This doesn't have to impact on most uses, at the top level
 the Field has attributes.  I would add that this applies to all
 attributes, ones recognised by CF and ones outside of the CF conventions.

 This meets the use case of reproducing files, which I think is a valuable
 capability that many user expect and enables precedence to be applied
 without deleting potentially informative metadata.

-- 
Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/95#comment:90>
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.

Reply via email to