[Go-essp-tech] ESG CMIP5 notification and inquiry requirements

Wed Nov 10 06:44:06 MST 2010

Hi

The "Tracking ID" service, or rather "ID Resolution" service, is at the
initial development phase.  The use case is summed up by Mark Elkington in
the two rtf attachments.  The design is detailed up in the Metafor
deliverable D5.5 attached.

How groups update the "parent meta data" is unclear ... via the CIMP5
questionnaire?

Regards

Mark

> Hi Karl
>
> A quick response to 1). This is exactly why I want a tracking id
> service. (Which I'm not yet sure we've built. Hans, what's the status of
> that?)
>
> If you have a file, with a tracking id, you want to be able to cut and
> paste it into a "find my data" page, and go straight to the parent
> metadata, which should show it has been withdrawn, and what the current
> version is.
>
> Cheers
> Bryan
>
>> Dear all,
>>
>> I am concerned that we will be unable to help users learn when CMIP5
>> data they have downloaded has been withdrawn (presumably because it
>> is flawed).  Here are some common "use cases" that ESG should be
>> able to handle (but I don't think it currently does).
>>
>> 1.  A user downloads some files on December 12, 2010.  Three months
>> later he wants to know
>>     a) if any files he downloaded were withdrawn (i.e., found to be
>> flawed).
>>     b) if similar data from other models (or replacement data from
>> models he has already downloaded) has become available.
>>     c) the reasons for data being withdrawn or replaced.  (For
>> example, was the data in the file flawed?  Was the data mislabeled?
>>  Were some of the attributes incorrect?  If so, which ones?)
>>
>> 2.  A user wishes to be informed by email when files he has
>> downloaded have been withdrawn, and he wants to know the reasons for
>> their withdrawal.
>>
>> 3.  A user wishes to be informed by email when new files in his area
>> of interest become available.  (The user would define "area of
>> interest" in terms of a set of DRS identifiers, e.g., experiment,
>> variable name, MIP table).
>>
>> 4.  A reader of a journal article wants to know whether any of the
>> data used in a study has been withdrawn and the reasons for its
>> withdrawal. The DOI's for the dataset(s) are included in the
>> article, and the user knows what variables are used from that
>> dataset.  How does he learn whether the data were subsequently
>> withdrawn, and the reasons?
>>
>> It is my understanding that the assignment of versions in the present
>> system is based on "dataset", whereas most users will only be
>> interested in a tiny portion of the dataset (e.g., a single
>> variable, rather than the perhaps 100 variables that might be
>> included in the dataset).   It would be very little help if the user
>> could learn only about changes at the dataset level (which might
>> occur because a single  variable was added withdrawn or replaced).
>> Also the *reason* for any changes to a dataset should always be made
>> clear.  So, the challenges would seem to be:
>>
>> 1.  Making sure data providers recorded information about why changes
>> were made to their datasets.
>>
>> 2.  Being able to report changes applied only to the subset of files
>> in a dataset that are of interest to any particular user.  This is
>> especially important, since if a user only is interested in 1 out of
>> 100 variables, he doesn't want to be bothered with messages about
>> changes to the dataset that didn't affect the variable he is
>> interested in.
>>
>> Another thing we should plan on doing is making it easy for users to
>> report suspected errors in the data they are analyzing directly to
>> the responsible modeling group(s).  How are we going to handle all
>> the emails from users who think they've discovered problems?
>>
>> If we don't have some way of doing the above by the first month or
>> two of 2011, I think we're going to be in for lots of complaints.  I
>> therefore hope we can make this a very high priority.  Are there any
>> higher priorities? (I'm sure there are, just wondering what they
>> are.)
>>
>> Best regards,
>> Karl
>>
>> p.s. feel free to post or forward to whomever you think might be able
>> to help.
>
> --
> 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
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Tracking ID Service - 01.rtf
Type: text/rtf
Size: 1157 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20101110/f169ca9f/attachment-0002.rtf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Tracking ID Service - 02.rtf
Type: text/rtf
Size: 2238 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20101110/f169ca9f/attachment-0003.rtf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: METAFOR_D5_5.odt
Type: application/vnd.oasis.opendocument.text
Size: 165125 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20101110/f169ca9f/attachment-0001.odt 