[Esip-preserve] [FOO] Alice publishes a paper, and more data arrives

[Bruce Barkstrom]

A seemingly simple example that generates unexpected complexity
is good.  We'll learn something out of trying to deal with it.

I'll also note that when we were doing the design of both ERBE and
CERES we spent a LOT of time dealing with the logical namespace.
The DOI's are unreadable and would almost certaintly create a very
large number of production errors owing to that semantic difficulty.
Namespaces are complex.

Note also that because the file names are not usually replicated
inside the file, there is some difficulty in the long run in ensuring
that the names are attached to the file contents.  I'll grant that this
is an extension from unique identifiers into long-term traceability.
I expect we'll separate the problems as best we can - but they sort
of live in the same space.

Bruce b.
On Fri, Oct 8, 2010 at 11:18 AM, Curt Tilmes <Curt.Tilmes at nasa.gov> wrote:

>
> [I'm trying to keep this as simple as I can, but I realize it is
> getting complicated.  Please bear with me.  This will help drive our
> use cases and illustrate the issues.  We can experiment with this
> pretend system on paper much easier than we'll be able to experiment
> with our real-world cases.]
>
>
> Alice compares the FOO collection 1 Level 3 data to the collection 3
> data and publishes a paper.
>
> She cites the data, including two references, the two DOIs to the
> level 3 data:
>
> doi:10.9999/US/FOOL3.v1 and doi:10.9999/US/FOOL3.v2
>
> The publisher assigns her paper its own DOI:
> doi:10.8888/1
>
>
> After that, 2 more months of L0 data come in and get added to the
> database:
>
> FOOL0.13.76e9b680-2d06-4a55-ad2c-79b533ce86ca
> FOOL0.14.f6bf9378-4215-41b5-9d3e-96dc0c2e7eeb
>
> They also run the L1B and L2 data in collection 2 (they don't even
> bother extending collection 1, since it used the old, obsolete
> calibration.)
>
> They produce these 4 new granules:
>
> FOOL1B.v2.13.e36a5d4d-1687-4947-bca8-2312c5f6eb8f
> FOOL1B.v2.14.eefa4113-200c-4a97-b5c6-3bd4b695cbc5
>
> FOOL2.v2.13.f8f9564d-cc2a-4760-b1bc-13f1ef5cbdcb
> FOOL2.v2.14.4814ed46-0e41-4e3f-8f73-33d0cd2ef0bc
>
>
> Not only that, the team discovers that the L0 data from
> month 10 were corrupt and they obtain corrected data, replacing
>
> FOOL0.10.0b337185-82af-4662-89b0-419bfd3e5db7
>
> file with a corrected file:
>
> FOOL0.10.3adf6dea-06af-478f-8216-2bbcdb0caad2
>
> They also re-run that granule through L1B,L2, and L3,
> replacing these files:
>
> FOOL1B.v2.10.2f269e5e-cce7-41e4-8a83-baad1e087c8e
> FOOL2.v2.10.533b2a95-d57f-4f75-9b7d-914d3d220310
> FOOL3.v2.01.07aa9ae3-9c3e-4508-b027-890dae11b768
>
> with these new ones:
>
> FOOL1B.v2.10.b8f1e287-2d92-4340-9a71-5da5af191f3b
> FOOL2.v2.10.6e58a410-60e7-4956-aeaf-37f76a16b171
> FOOL3.v2.01.2a365058-fb52-4559-ab4b-085cb5ac0b73
>
>
> Now, the official archive is distributing the new files, but we've
> still got a paper out there that was developed using the old, bad
> data.  Note that using simply the DOI for the collection as a whole is
> not sufficient to indicate that fact.
>
> Curt
> _______________________________________________
> Esip-preserve mailing list
> Esip-preserve at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-preserve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-preserve/attachments/20101008/8d6f43aa/attachment-0001.html>