[Go-essp-tech] qc-data-level2 output and qc-tool

[Bryan Lawrence]

Hi Martina

I owe you yet another apology. I should have looked at this document 
before ... sorry ... it must have been frustrating to keep sending it 
out and get no feedback.  

It's pretty close to what I would have expected though, so at least 
we're not on divergent paths :-) ... 

I have a couple of minor comments to make about what you've done, and 
then some comments about how we might expect to use it - it might be 
that you need to generate rather less of this than you had expected to 
have to do.

So, going through your document first, and then getting to sequencing 
who/what does what and when?

1) Scope: level and leveldescription.

The scope level description is supposed to describe the level of the 
data not the level of the qc passed ... so I would argue that the text 
in this box ought to be about the simulation not the qc level.

(Think about the fact that a quality document might have lots of reports 
about different measures and lots of issues, so a leveldescription which 
applies to a specific measure is inappropriate ... see also the note in 
the xsd about it's expected use.)

NB: note also the modification to have a CIM_Scope extension so we can 
point at the target.

2) Report

(Don't worry about the DQ_DomainConsistency specialisation, it would 
change nothing in what you have done ... it's simply a way of ensuring 
that we don't try and use an abstract class where we need a real class 
and it would allow *optionally* an addiitonal report type ... of which 
more below)

Looking down:

nameofMeasure: this is where I would say it's CMIP5 QC level 2 rather 
than in the levelDescription. you could put the text you have here in 
the lead part of the measureDescription (which is pretty much there 
anyway).

measureDescription: good.

(note that these two will not change from one instance to another)

dateTime:ok

and then we get to the dq_conformance_result instance.

which is good.

Forgetting the class structure for a moment, the content of this element 
which is going to change from one instance to another would be the 
status (and that might be the only thing that changes if, for example, 
we start with a record that says it fails, and then eventually we update 
it) and who did it.

3) Then you have the document attributes ... which as you surmise, could  
be done by another piece of code.

And now about the usage.

I've attached a diagram which I think summarises the expected usage.

I think the good news is that the report that your sofware produces can 
be even simpler than the example you sent: it simply needs to be the 
dq_domainconsistence instance (report) which can import a measure 
description chunk of xml (which can be produced by the qctool) and 
simply create one or two DQ_result instances (ie the conformanceresult 
and a plotresult ... nb: the latter probably needs to be tweaked to 
allow more than one plot ...)

And you can use the qctool to ellaborate your measure descriptoins as 
you like - or you can carry on as you've done and generate it yourself.

If you did want to use the qctool to create pieces of the report to 
compose in, we would need to allow the export of some of the pieces as 
well as the atom feed. That ought to be straight forward. Let us know.

Cheers
Bryan



Bryan Lawrence
Director of Environmental Archival and Associated Research
(NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
STFC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848; 
Web: home.badc.rl.ac.uk/lawrence
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QC tool interaction.png
Type: image/png
Size: 86549 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20100927/a109f6ec/attachment-0001.png