[Moims-dai] FW: IPELTU actions

Thu May 2 16:14:27 UTC 2019

Mike,

I totally agree with what you are saying. I just think the text as
currently written might leave the Program Manager with the impression that
they have the final say over what gets preserved and what doesn't. While
the Program Manager is the expert on the immediate importance of the
data/information/records to be created, archivists have a better idea of
what records will be useful over the long term and what some of the
secondary uses of the data might be.

If the checklist gets the Program Manager thinking about preservation that
is a great thing. It just might be a good idea to suggest a few resources -
Legal Counsel, Records Management, etc - to help the PM make those
decisions.

Hope this clarifies things.

Mark
Mark Conrad
NARA Information Services
Systems Engineering Division (IT)
The National Archives and Records Administration
Erma Ora Byrd Conference and Learning Center
Building 494, Room 225
610 State Route 956
Rocket Center, WV  26726

Phone: 304-726-7820
Fax: 304-726-7802
Email: mark.conrad at nara.gov

On Thu, May 2, 2019 at 10:56 AM Mike Kearney <kearneysolutions at gmail.com>
wrote:

> Thanks, Mark, that’s good info!  But I don’t think the DTOPP approach
> contradicts or negates any of that.  As you say, the final decision is not
> one the program/project/mission manager can make on their own.  But he’s
> the starting point.  If there’s a data type that this checklist causes him
> to realize is important and it needs to be preserved, he’ll have to start
> the process of negotiating with his national archive agencies, NARA in the
> case of NASA.  But this checklist can be his starting point so he can make
> conscious decisions (instead of going with default tradition) about what is
> important in his mission and warrants preservation.  He knows his mission
> and the planned results better than the archivists do.
>
>
>
> Also, we should not take the lead of one agency (NASA/NARA) and limit the
> preservation checklist, because it’s an international recommendation.  And
> we can’t survey all to come up with the sub-set that will “get through” all
> other agencies’ processes.  And we shouldn’t… we want the superset of
> recommendations that they can uncheck if it’s not important, or if they
> don’t want to break with default tradition.
>
>
>
> But… maybe not the total superset, as I said before, because if it’s too
> long it won’t be utilized.  But the reason for eliminating some items
> should not be because some agency doesn’t have it on their agreements with
> their archivists.
>
>
>
> Doesn’t that make sense for this DTOPP Checklist product?
>
>
>
>    -=- Mike
>
>
>
> Mike Kearney
>
> Huntsville, Alabama, USA
>
>
>
> *From:* MOIMS-DAI [mailto:moims-dai-bounces at mailman.ccsds.org] *On Behalf
> Of *Mark Conrad
> *Sent:* Wednesday, May 1, 2019 4:25 PM
> *To:* MOIMS-Data Archive Interoperability <moims-dai at mailman.ccsds.org>
> *Subject:* Re: [Moims-dai] FW: IPELTU actions
>
>
>
> Hi Mike,
>
>
>
> Overall, I like the approach in the DTOPP. However, the decision as to
> what information will receive long term preservation and what won't is
> often not one the Program/Project/Mission Manager can make on their own.
> Most space agencies are government entities with applicable public records
> laws and regulations that must be obeyed.
>
>
>
> For example, NASA Program Managers can recommend what should receive long
> term retention to the agency's Records Management Office. If the
> information created by the Program is not covered by an existing records
> disposition schedule, the Records Management Office works with the Program
> Manager, NASA's Legal Counsel, and an appraisal archivist from NARA to
> establish a proposed new records disposition schedule. This proposed
> schedule along with an appraisal report works through an approval process
> at NARA. Ultimately the Archivist of the United States (NARA agency head)
> approves or disapproves the schedule. No records can be destroyed without
> an authorization from NARA.
>
>
> Mark Conrad
> NARA Information Services
>
> Systems Engineering Division (IT)
> The National Archives and Records Administration
> Erma Ora Byrd Conference and Learning Center
> Building 494, Room 225
> 610 State Route 956
> Rocket Center, WV  26726
>
> Phone: 304-726-7820
> Fax: 304-726-7802
> Email: mark.conrad at nara.gov
>
>
>
>
>
> On Wed, May 1, 2019 at 4:51 PM Mike Kearney <kearneysolutions at gmail.com>
> wrote:
>
> This note has two purposes:  (1) Remind actionees of their IPELTU actions
> coming into the meeting in Mountain View next week, and (2) to distribute a
> cut at an IPELTU annex for discussion at the meeting (or in this email
> thread).
>
>
>
> David recorded the IPELTU actions as:
>
> *Action:* DG update IPELTU main text to hook in planned annexes.
>
> *Action:* MK (Mike Kearney), MM2(Mario Merri) provide text for IPELTU
> operational data annex
>
> *Action:* SH ((John) Steven Hughes), CR (Costin Radulescu), ML (Rosemarie
> Leone) provide text for IPELTU science payload data annex
>
> *Action:* MLH (Matthias Hemmje), ML (Rosemarie Leone), provide text for
> IPELTU Digital Library data annex
>
>
>
> Meanwhile, Steve Hughes and I sort of took the second and third action in
> a different direction and integrated it for an annex which applies to an
> entire space mission.  My rationale in doing this was that we want the
> program manager at an early phase to decide (and budget for) the level of
> digital preservation at which his mission products are to be preserved (are
> valued?), so it has a point blank “are you or aren’t you?” choice that he
> has to make.  Meanwhile it is a very easy checklist for him to click little
> boxes and then issue it as a program directive.  Because it is somewhat
> like a PICS-Proforma, I used the term Proforma.  But it’s not a Protocol
> and it’s not a Conformance Statement.  So after some back-and-forth with
> the chairs we settled on Digital Target of Preservation Proforma (DTOPP)
> Checklist.  Comments on that are welcome, of course.
>
>
>
> I have started on the first five sections, but there is a long way to go.
> However, I think it is just as important with this to be brief as to be
> complete, because if it is a heavy task to fill out, it won’t get used.  It
> needs to be easy for a manager to run down the list saying “Sure, we want
> to preserve that post-mission” and check things off.  As you will see, I
> have two levels of detail possible, and the program manager can decide
> whether to progress from the one-page statement to the multi-page form.
>
>
>
> So, the discussion is whether this new concept is useful for space mission
> applications, and whether the format could be applied to other IPELTU
> annexes.
>
>
>
>    -=- Mike
>
>
>
> Mike Kearney
> <https://public.ccsds.org/about/ManagementCouncil/MikeKearney.aspx>
>
> Huntsville, Alabama, USA
>
> +1-256-361-5411 (mobile)
>
>
>
> Member of Technical Staff
>
> Space Infrastructure Foundation
> <http://sol.spacenvironment.net/sif/index.html>
>
>
>
> *From:* David Giaretta [mailto:david at giaretta.org]
> *Sent:* Tuesday, April 30, 2019 1:14 PM
> *To:* Mike Kearney <kearneysolutions at gmail.com>
> *Cc:* 'John Garrett' <garrett at his.com>
> *Subject:* IPELTU actiosn
>
>
>
> Hi Mike
>
>
>
> As requested, the IPELTU actions
>
>
>
> *Action:* DG update IPELTU main text to hook in planned annexes.
>
> *Action:* MK (Mike Kearney), MM2(Mario Merri) provide text for IPELTU
> operational data annex
>
> *Action:* SH ((John) Steven Hughes), CR (Costin Redalscu), ML (Rosemarie
> Leone) provide text for IPELTU science payload data annex
>
> *Action:* MLH (Matthias Hemmje), ML (Rosemarie Leone), provide text for
> IPELTU Digital Library data annex
>
>
>
> ..David
>
>
>
> _______________________________________________
> MOIMS-DAI mailing list
> MOIMS-DAI at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai
>
> _______________________________________________
> MOIMS-DAI mailing list
> MOIMS-DAI at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20190502/090ccbcc/attachment-0001.html>