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

[Bryan Lawrence]

Hi Martina

> - 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?

I would expect a different DomainConsistency report for each of QC L1 to 
L3 ...

> - results of a report can be log files or plots? There might be more
> than one result for a reported QC L2 check?

:-) Early today I modified CIM_PlotResult, but I see I failed to check it 
in. I allowed for sets of plots, but I didn't allow for sets of log 
files. Do you think we should add support for those as well (easy enough 
to do ...)

> 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.

OK, for the moment that's easy enough to push through the existing 
machinery, so we only need to add log file support in case you want to 
unravel this pdf file.

> 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?

As in the diagram, I would expect you to upload a dq_domainconsistency 
fragment as a report (which could include a piece of xml you had 
downloaded, so I could concieve of your workflow simply reading that 
piece from a file alongside the qc level 2 code). However, if you wanted, 
we could simply allow you to pick the qc level 2 from a menu, add the 
author, and upload the file ... which could be even easier. I'm planning 
on adding this piece of functionality while on a transtlantic flight 
tomorrow, so by the time you get back, you can choose your option :-)

> - 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?

There will be by the end of the week (I hope, depending on how Dom can 
fit it in while being on a course).

> - 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?

Currently, to make it generic, the tool expects a uri, and shortly, 
it'lll allow a url as well. We could specialise it for CMIP5, so it can 
have a DRS string .... I'll think about that/

> 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.

Should definitely have something to work with next week!

Best wishes,
Bryan

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