[Moims-dai] Information or data lifecycle vs Project lifecycle - incomplete monograph
D or C Sawyer
Sawyer at acm.org
Tue Mar 15 12:10:06 UTC 2016
I agree with David’s concerns. I think the need and focus should be on what the ‘project’ needs to do to ensure its information is ready for long term preservation. To accomplish this would be a significant step forward and broadening it would be a distraction. This does not mean that concerns for the Designated Community are to be ignored as this must be of concern to the project as it prepares its information for presentation to an archive, but a full consideration of possible future Designated Communities would get into archival activities. I think a project should include a description, at the proposal stage, of the Designated Community it has in mind. This would provide a focus for the nature and amount of ‘additional information’ needed to accompany the primary data being submitted, and it would aid in the review by the project and others as to the adequacy of the total information to be preserved. That is how I see it.
I’m sorry but I’ll not be available for today’s telecon.
On Mar 15, 2016, at 5:36 AM, David Giaretta <david at giaretta.org> wrote:
> Hi Terry
> I would be concerned if you are proposing to extend the scope of the document to overlap with what OAIS and PAIS/PAIMAS do perfectly adequately.
> Besides somehow resolving that overlap this would mean that we would need to find a great deal more effort from somewhere to finish the document in a reasonable time.
> From: moims-dai-bounces at mailman.ccsds.org [mailto:moims-dai-bounces at mailman.ccsds.org] On Behalf Ofterry.longstreth
> Sent: 23 February 2016 16:06
> To: moims-dai at mailman.ccsds.org >> MOIMS-Data Archive Ingestion <moims-dai at mailman.ccsds.org>
> Subject: [Moims-dai] Information or data lifecycle vs Project lifecycle - incomplete monograph
> I've been searching for a way to articulate my concerns with the Lifecycle document, and still haven't found it; the way to articulate it, I mean.
> So, I'll just charge ahead. I don't think these ideas can be of much effect on the document itself, since I'm so late to the party, but perhaps by putting it in front of the group, others can make better use of them than I.
> I'm concerned that we are serving two masters without recognizing the driving and not necessarily congruent interests of those two:
> First, we've been told that the impetus for the 'lifecycle' document came from work items or expected tasking in contracts where the contracting agency wanted to ensure that they could, with confidence, be assured that all relevant data related to a funded activity would be available for them to review and reuse.
> Second, I've an internal (institutional) bias, which I believe I share with those on this list, toward supporting the goal of meeting the needs of the Designated Community, which may be but probably isn't the same as the contracting agency.
> Now, the purpose and body of the Lifecycle document is clearly slanted toward the first constituency. For example, the lifecycle elements are, as already noted by Don, John, and several others, more typical of a project lifecycle than a data or information lifecycle. I had accepted an action to review and offer suggestions to improve Chapter 5 and it's associated table. I propose that the table should be recast to more properly reflect a Generic Data Lifecycle that accommodates longterm, potentially unending, data generation environments as well as situations where data lifecycle management is associated with and punctuated by short-term project level goals. The generic data lifecycle emphasizes the data operations leading from initial or conceptual planning for data collection or generation, through to explicit freezing of a data package and final disposition.
> Generic Data Lifecycle
> Conceptualization->Origination->Availment->Processing->Packaging->Curation and Disposition
> Moims-dai mailing list
> Moims-dai at mailman.ccsds.org
More information about the MOIMS-DAI