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

[Martina Stockhause]

  Hi Bryan,

Franks is going to answer the tool interaction part.

I prefer to use your qctool because then the CIM schema developers take 
care of the semantics.
Just a few questions for understanding the functionality of and 
interfaces to the qctool:
- The report parts describe the results for QC L1, L2, and L3 checks?
- nameOfMeasere and measureDescription of a report are equal for all 
results of the reported QC L2 check?
- results of a report can be log files or plots? There might be more 
than one result for a reported QC L2 check?
The QC L2 checker plots are at present concatenated to a single (rather 
large) PDF. So there are only one plotresult and one conformanceresult 
cerated for one QC L2 result.

The qctool:
- There already exists a quality document (QC L1 is already assigned)?
- Do I have to create a raw dq_domainconsistence instance (report) or is 
that present?
- The qctool can add a measure description part to the QC L2 instance or 
a result part?
   - How would this three parts look like? Are these XMLs for these 
parts of the quality document?

- Does the qctool call include the DRS of the realm/experiment in order 
to make the connection to the simulationRun document or how is this 
connection done?

Well, I will be out of office for a week. For me concrete examples are 
easier to discuss. I will create examples for the use of the qctool when 
I will be back.

Best wishes
Martina



On 09/27/2010 11:41 AM, Bryan Lawrence wrote:
> 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

-- 
----------- DKRZ / Data Management -----------

Martina Stockhause
Deutsches Klimarechenzentrum
Bundesstr. 45a
D-20146 Hamburg
Germany

phone:	+49-40-460094-122
FAX:	+49-40-460094-106
e-mail:	martina.stockhause at zmaw.de

----------------------------------------------