Talk:Provenance and Context Content Standard

From Earth Science Information Partners (ESIP)
Revision as of 15:19, March 8, 2011 by Ctilmes (talk | contribs) (→‎From SiriJodha -- ~~~~: new section)

-- Ctilmes 11:46, 3 March 2011 (MST)

Taken from Rama's email: http://rtpnet.org/pipermail/esip-preserve/2011/000428.html

-- Ctilmes 06:01, 7 March 2011 (MST)

Clynnes: I would suggest you add a column noting possible restrictions on later distribution of items. This would include source code release restrictions, as well as ITAR restrictions on most documents describing spacecraft details, for example.

From SiriJodha -- Ctilmes 14:19, 8 March 2011 (MST)

From email. Some questions and comments:

1. I didn't see a mention of the data and metadata itself. This archive package would be separate from the data? The division between documentation and metadata is blurred, of course, e.g. production history is included in the table, but is in some cases saved as metadata. Some QA is metadata, some is in the product files. The spec needs to address how data and metadata are preserved.

2. Normalization of the entries is needed - there's lots of duplication/overlap, and some similar or identical items appear under different categories

3. Some descriptions refer to "project artifacts" - the reference should be to specific items in the table. Likewise, what are "developer's design documents"?

4. There needs to be a separate column for "alternate" sources for an item, rather than using the rationale column, which should eventually be populated for each item.

5. Aren't items that refer to accessing the data, like NOAA item 36, irrelevant? The physical location of the data may change.

6. Error analysis under documentation belongs under Quality (and I think QA is too narrow of a term. Should be just quality or quality measures). Validation belongs under Quality also, don't you think?

7. Why source code only for higher-level products? Why not all source code involved in product generation?