Changes between Version 14 and Version 15 of MolesDiscussion


Ignore:
Timestamp:
28/07/06 15:24:05 (13 years ago)
Author:
ko23
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MolesDiscussion

    v14 v15  
    55 * Modified by Siva, Dom and Kevin with explicit inline comments. 
    66 * Modified BNL, 25 July, based on followup discussion between BNL and KON on the 24th ... 
     7 * Modified RKL, KDO, 28 July with inline comments. 
    78 
    89==== Issues on the Table ==== 
     
    9899      * BNL: So I think the height of the data parameter is something that belongs in CSML ... and so this should be out, and replaced (for BODC) with something that covers the BODC use case (but exactly what use case supports hiding a parameter from discovery? 
    99100 
     101            * KDO - height? Is this visibility? Anyway, this isn't the point of the flag (new name needed?), the concept behind which has been useful in other areas. 
     102 
    100103''Roy:'' ''Seems to be a misunderstanding here.  I was using IsOutput to hide co-ordinate channels (date/time, depth, CTD pressure) as I thought that was how MOLES was to be used.  Kicking them out altogether is just as good for me.'' 
     104 
     105    * KDO - Good, if understand you aright, then Siva's point now makes sense to me. I'd rather use the word "mark" rather than "hide", but the point is that you might want this parameter there, but you don't want it mistaken for a measured value. Hence I say it stays. However, if Bryan still feels strongly, it could be made optional. This would then require consistent usage within a DP, and if it isn't there then "co-ordinate variables" should be left out. 
    101106 
    102107 * The next thing is a choice of four items, only one of which should appear for any parameter. Either the value, or the range of values, or an enumeration list of the  value types, or a compound group should appear. ''Yes/No? If so, ticket needed: It needs to be a choice as to whether this thing exists and it needs a name.'' ''Also another ticket: Roy to give us a few practical examples of how the parameter group is intended to work '' 
    103108 
    104109''Roy:'' ''The primary reason for this is the way we handle date/time in BODC, which is to carry two parameters (days elapsed since the start of the Gregorian Calendar and time within day), BUT we have now decided that the inclusion of this was down to a misunderstanding (see above) about what was to be done with co-ordinate data channels in MOLES.  The other thing that was in the back of my mind was how we handle data quality information (parameter + flag) but I now see this is more of a CSML issue than a MOLES issue. So, I think parameter groups are dropping off our radar'' 
     110 
     111 * KDO - It was also a way to link the GCMD valids to BODC variables in a controlled way, without putting the GCMD terms  into structured keywords. 
    105112 
    106113   * ''Siva: Yes,at BODC we are using the following Strategy.Go for dgRangeDataParameter and check if HighValue=LowValue, in which case we use dgValueDataParameter.The way we get the HighValue and LowValue is,  by opening each Series data file (QXF file) and the min and max value for the required data channel is obtained.Once the limits for each Series have been obtained, the extremes may be determined to give the limits for the dataset.We cannot envisage using dgEnumerationParameter.'' 
     
    113120 
    114121''Roy:''''This worried me a little at first, but the more I think about it, the more I think it might help as exposes the two items of information needed to map CF to a BODC PUV term side by side making them a much easier target!'' 
     122 
     123 * KDO - so you'll explain to me why this isn't a parameter group Bryan? 
     124 
    115125 * I suppose we imagine a granule of consisting of multiple phenomena with multiple feature types, but we would expect that any one phenomenon in one granule to have one feature type (''Andrew/Dominic?''). In which case the feature type name and the feature type catalogue from which it is governed should also be encoded per parameter. However, one might argue that the assumption might be violated, and in any case, at this point the user might be pointed to the WFS level. ''It would certainly be simpler, and possibly more useful to generate a list of feature types present in the granule (along with their FTC antecedents).'' ''Yes/No? Ticket Needed?!'' 
    116126   * Dominic:''I think that assumption (one phenomenon -- one feature type (for a given granule)) is correct.'' 
     
    127137It is a moot question as to how much of this needs to be replicated from the granule content. ''Tickets needed on some of the following'' 
    128138 * BNL would argue that the spatio-temporal coverage should be the *union* of the granule coverages (''need a tool to produce this''). 
     139 * KDO - would other data providers like to comment on what they want to do for their data?  
     140 
    129141 * The parameter coverage is a bit more complicated, because now we think we could have, for example, temperature monthly means and temperature annual means in the granules. I think the only thing that makes sense is to aggregate the granule parameter summaries. ''In which case why bother? We can parse the granule content. Remove?'' 
    130142 * ''There ought however to be a consolidated lists of feature types present ... as well. Add?'' 
     
    147159(BNL I'm still convinced that dgDataObjectType is covered by the dgGranule content (with feature type added), so it should go). 
    148160 
     161(KDO - I'm not, but if no one comes forward to provide the relevant attributes, then it should go... for the moment ;-) 
     162 
    149163==== ISO19139 ==== 
    150164 
     
    157171 
    158172It's quite clear that the MOLES data model needs to be in UML. Ideally we'd want to be able to autogenerate the schema via ShapeChange, but that's a ''long'' way away, meanwhile, the docs should make as much as possible clear with UML fragments. 
     173 
     174(KDO - 19115 was in UML: 19139 was then necessary. 'nuff said!) 
    159175 
    160176 
     
    177193 
    178194 
     195