[Go-essp-tech] qc-data-level2 output and qc-tool
Bryan Lawrence
bryan.lawrence at stfc.ac.uk
Mon Sep 27 03:41:59 MDT 2010
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
More information about the GO-ESSP-TECH
mailing list