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

 Hi Folks

 We now have two threads running on the global/variable attribute dilemma:
 (1) do such things have any semantic difference? and (2) what to do with
 data where both global and variable attributes with the same name exist
 (the precedence argument).

 Taking the second first: I think the consensus of the argument thus far is
 that we *may* have data where Jonathan's interpretation of precedence (aka
 replace) might give the wrong results, and that in any case, we need to
 build up provenance as we manipulate data, which means we want to keep
 adding information to attributes as we process data.

 What then should be the best practice to do the latter? Multiple
 attributes with the same name, or add/aggregate information into the same
 attribute? Effectively we can't have multiple attributes with the same
 name, so "best practice" is to add provenance to "the" history comment as
 software processes data.

 Note that in the previous paragraph I didn't mention whether the
 attributes were "file" or "variable". The same argument applies to both.

 So now we can think of file/variable attribute conflict as just being a
 special case of having to deal with aggregating information as software
 processes data (and that will now go past history, we might be adding
 authors sources etc). There are three possible conflict cases to deal
 with:
  1. Global attribute and variable attribute of the same name exists, and
 they are complementary, that is, the right answer is to join them together
 in some sense.
  1. Global attribute and variable attribute of the same name exists, but
 the intent was that the global attribute has been overridden by the
 variable attribute.
  1.  Global attribute and variable attribute of the same name exists, but
 the intent was that the global attribute overides the variable attribute.

 The third we can discard. If such data exists, the file is not CF
 compliant. The first two are clearly at least consistent with some
 interpretations of CF, but frankly, we can't know what was intended. We
 can fix that in a future version, but we are where we are.

 Returning to my very first enumeration, then we have the semantic
 difference issue. I believe that my previous interventions, plus the
 argument above about workflow, suggest that there is no semantic
 difference between global and variable attributes, we simply have to deal
 with the problem above: two possible interpretations of how to process the
 attributes.

 I suggest for existing CF data (up to 1.7 I suppose), we recommend
 software simply aggregate them, but tag the global one as "inherited
 global %s %s"%(filename,timestamp). A human will have to disambiguate any
 problems that arise from the correct behaviour having been replace not
 aggregate. This does not affect the data model!

 For future version of CF, we choose which of the above interpretations we
 want, and make it unambiguous. Either way, we simply treat global and
 variable attributes as having no different semantics.

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