LISTSERV mailing list manager LISTSERV 16.5

Help for NDSA-INFRASTRUCTURE Archives


NDSA-INFRASTRUCTURE Archives

NDSA-INFRASTRUCTURE Archives


NDSA-INFRASTRUCTURE@LISTS.CLIR.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

NDSA-INFRASTRUCTURE Home

NDSA-INFRASTRUCTURE Home

NDSA-INFRASTRUCTURE  November 2013, Week 2

NDSA-INFRASTRUCTURE November 2013, Week 2

Subject:

Re: Infrastructure Call Today: 2PM EST on Fixity check project

From:

John Spencer <[log in to unmask]>

Reply-To:

John Spencer <[log in to unmask]>

Date:

Wed, 13 Nov 2013 11:21:13 -0600

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (147 lines)

Hello everyone,

I too missed the call - I'm not currently a member of the Infrastructure Committee, but Linda and Kara raise some great points. As some of you know, I come from the commercial side of the archival business.

Linda pointed out that "one size fits all" may not work. I concur, as in many cases, the release date of a project is more important to the asset owner than the archival process, so the data moves all over the place, hopefully to be put back in a "container" that contains all A/V files, including audio, liner notes, crediting, artwork, etc. That moving target appears over a 3-6 month period - so how does one properly address this without upsetting the apple cart of sales and marketing?

There was also the mention of constraints - we can script out a way to do a fixity check for LTOs and append that to the tape reviewed, but if most of them are laying fallow in a vault, what is the trigger to determine they need to be fixity checked? Record label vaults tend NOT to review data tape backups that have not recouped their recording costs - while I don't agree with the premise, it is reality, and there at some level needs to be some marketing (and I hate to use that word in the context of archiving) or other documentation from NDSA that we (I, or anybody else) can distribute around to the various IT departments.

Kara makes a good point about what data should be stored - I would say that any IT department worth it's salt would keep records of both good and bad - as comprehensive as possible - in my world, I'd be happy to report "only bad" as a worst-case scenario, but to me personally that's just a band-aid, but at least it's a good band-aid.

Can the 4 levels of digital preservation as Karen mentioned work for improving the knowledge of fixity?

Speak soon! 

John
[log in to unmask]

On Nov 11, 2013, at 10:48 AM, Kara Van Malssen <[log in to unmask]> wrote:

> Hi all,
> 
> I also want to apologize for missing the call. I have a few thoughts to add:
> 
> I agree with the important points that Linda has made. On the final point, regarding metadata capture - this question in general should also be addressed. Options for how/where metadata related to fixity is stored, how it is updated, retained, etc. Should you retain outcome of all fixity checks, time/date, outcome regardless of whether good/bad? Only bad? Should this information be stored separately from your other preservation metadata? What are the options/trade offs?
> 
> Finally, is there a Google Doc where this info is being collected/edited? I only see the Word Doc, which is probably getting hard to manage with the inputs coming through via email.
> 
> Hope to join you on the next call, and looking forward to working on this project.
> 
> Thanks,
> Kara
> 
> 
> 
> Kara Van Malssen
> AudioVisual Preservation Solutions
> 350 7th Ave., Suite 1603
> New York, NY 10001
> 
> office: 917-475-9630 x 2
> mobile: 917-842-9586
> 
> http://www.avpreserve.com
> facebook.com/avpreserve
> twitter.com/avpreserve
> 
> 
> 
> 
> 
> On Nov 10, 2013, at 3:30 PM, Linda Tadic <[log in to unmask]> wrote:
> 
>> Hi all,
>> 
>> I'm very sorry that I missed this call. I suspect that my comments below were already mentioned during the call by others, but in case they weren't here goes.
>> 
>> What a great start to a useful document. I like that it will explain why there can't be a set overall standard for scheduling fixity checks other than it should be run when a file is moved -- timing depends so much on storage medium and infrastructure.
>> 
>> top of p.2: Constraints. Add more info on fixity checks of files on tape. Oracle/Sun/StorageTek drives (choose your name) can run checks while the tapes are in situ in the drives, so the files needn't be copied to servers and checked there. LTO drives can't do that (yet) so the files must be copied up to servers for checking, adding lots of work and strain on the infrastructure. However, I say "yet" because I corresponded with someone in IBM's LTO R&D department. They're working on a driver to check files in situ on LTO LTFS drives. She thought it'd be released Q2 2014.
>> 
>> p. 2: more on the trend to run frame-level checksums on very large video files (uncompressed, DPX) as a preservation act. If there are frame-level checksums, then the error can be immediately identified rather than knowing vaguely that the file is corrupt somewhere.
>> 
>> Add: metadata that should be captured, following PREMIS: algorithm type, value, creation software, date created, who created it, when checked, result.
>> 
>> Best,
>> Linda
>> 
>> 
>> ----- Original Message ----- From: "Owens, Trevor" <[log in to unmask]>
>> To: <[log in to unmask]>
>> Sent: Tuesday, October 29, 2013 5:39 AM
>> Subject: [NDSA-INFRASTRUCTURE] Infrastructure Call Today: 2PM EST on Fixity check project
>> 
>> 
>> Reminder, today we have our working group call. This time focused on discussing ways forward on the fixity check project. (See Karen's message below.)
>> 
>> As a way to try and kick off the conversation, I started sketching out what could be the basis of a short document on fixity checking. It's really just a straw man for us to use for the purposes of figuring out what we actually would like to produce.
>> 
>> I had a hard time making all of this fit into a neat grid but I think we could make something that just spells out different goals, approaches and constraints.
>> 
>> Time: 2:00 PM EST, Oct 29th
>> 
>> The call in number will always be:
>> Call-in number:  866-469-3239
>> Participant access code:  21408589
>> 
>> -----Original Message-----
>> From: The NDSA infrastructure working group list [mailto:[log in to unmask]] On Behalf Of Karen Cariani
>> Sent: Thursday, September 19, 2013 4:37 PM
>> To: [log in to unmask]
>> Subject: [NDSA-INFRASTRUCTURE] Fixity check project
>> 
>> Hi everyone,
>> 
>> I'm sorry for my delay in getting this going.  Since there were a number of you interested, I figured I'd just use the list serv for the project work. We can use regular phone calls too if there is nothing else going on during that month.
>> 
>> Lets start with the notes form the call:  Most of the participants on the call were interested in either or both of these issues.
>> 
>> 1.  Getting started with fixity practices. This could, for example, work through the each of the 4 fixity levels in the NDSA levels of digital preservation. The goal here would be to work through how to get started, different kinds of approaches and tools you can use to establish your workflows.
>> 2.  Fixity trade offs decision tool. Given different systems, different kinds of content, different scales of content etc. there should be different approaches to the frequency of fixity checking. There is interest in developing some kind of grid, or decision tree that could help orgs decide the best approach to how frequently to check the fixity of their content.
>> 
>> Anyone interested in number 1 specifically or number 2?  Should we start on both and see how it breaks out?
>> For number 2 were a number of ways we could break this out and look at it, or rather a number of parameters to frame it.  Here are the ones listed above:
>> 
>> System type
>> Type of content
>> Scale of content (not sure what this means) Frequency based on those factors Any others?
>> 
>> Karen
>> 
>> 
>> 
>> ############################
>> 
>> To unsubscribe from the NDSA-INFRASTRUCTURE list:
>> write to: mailto:[log in to unmask]
>> or click the following link:
>> http://list.digitalpreservation.gov/scripts/wa-DIGITAL.exe?SUBED1=NDSA-INFRASTRUCTURE&A=1
>> 
>> ############################
>> 
>> To unsubscribe from the NDSA-INFRASTRUCTURE list:
>> write to: mailto:[log in to unmask]
>> or click the following link:
>> http://list.digitalpreservation.gov/scripts/wa-DIGITAL.exe?SUBED1=NDSA-INFRASTRUCTURE&A=1
>> 
>> ############################
>> 
>> To unsubscribe from the NDSA-INFRASTRUCTURE list:
>> write to: mailto:[log in to unmask]
>> or click the following link:
>> http://list.digitalpreservation.gov/scripts/wa-DIGITAL.exe?SUBED1=NDSA-INFRASTRUCTURE&A=1
> 
> 
> ############################
> 
> To unsubscribe from the NDSA-INFRASTRUCTURE list:
> write to: mailto:[log in to unmask]
> or click the following link:
> http://list.digitalpreservation.gov/scripts/wa-DIGITAL.exe?SUBED1=NDSA-INFRASTRUCTURE&A=1

############################

To unsubscribe from the NDSA-INFRASTRUCTURE list:
write to: mailto:[log in to unmask]
or click the following link:
http://list.digitalpreservation.gov/scripts/wa-DIGITAL.exe?SUBED1=NDSA-INFRASTRUCTURE&A=1

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
November 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
November 2014
October 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014, Week 2
March 2014
February 2014, Week 4
February 2014, Week 3
February 2014, Week 2
February 2014, Week 1
January 2014, Week 5
January 2014, Week 4
January 2014, Week 1
December 2013, Week 2
November 2013, Week 4
November 2013, Week 2
October 2013, Week 5
October 2013, Week 3
October 2013, Week 1
September 2013, Week 3
August 2013, Week 5
August 2013, Week 4
August 2013, Week 1
July 2013, Week 5
June 2013, Week 4
June 2013, Week 3
June 2013, Week 2
May 2013, Week 3
April 2013, Week 5
April 2013, Week 4
April 2013, Week 3
March 2013, Week 4
March 2013, Week 3
March 2013, Week 2
March 2013, Week 1
February 2013, Week 4
February 2013, Week 3
February 2013, Week 2
February 2013, Week 1
January 2013, Week 5
January 2013, Week 4
January 2013, Week 3
January 2013, Week 2
December 2012, Week 2
November 2012, Week 4
November 2012, Week 3
November 2012, Week 2
November 2012, Week 1
October 2012, Week 5
October 2012, Week 3
October 2012, Week 2
October 2012, Week 1
September 2012, Week 4
September 2012, Week 3
August 2012, Week 5
August 2012, Week 4
August 2012, Week 3
August 2012, Week 2
August 2012, Week 1
July 2012, Week 5
July 2012, Week 2
June 2012, Week 4
June 2012, Week 3
May 2012, Week 5
May 2012, Week 3
May 2012, Week 2
May 2012, Week 1
April 2012, Week 5
April 2012, Week 4
April 2012, Week 3
April 2012, Week 2
March 2012, Week 5
March 2012, Week 4
March 2012, Week 2
March 2012, Week 1
February 2012, Week 4
February 2012, Week 3
February 2012, Week 2
February 2012, Week 1
January 2012, Week 5
January 2012, Week 4
January 2012, Week 3
January 2012, Week 1
December 2011, Week 3
December 2011, Week 2
December 2011, Week 1
November 2011, Week 4
November 2011, Week 3
November 2011, Week 2
November 2011, Week 1
October 2011, Week 3
September 2011, Week 4
September 2011, Week 3
September 2011, Week 1
August 2011, Week 5
August 2011, Week 4
August 2011, Week 3
August 2011, Week 1
July 2011, Week 5
July 2011, Week 4
July 2011, Week 1
June 2011, Week 3
June 2011, Week 2
June 2011, Week 1
May 2011, Week 4
May 2011, Week 2
May 2011, Week 1
April 2011, Week 3
April 2011, Week 2
April 2011, Week 1
March 2011, Week 5
March 2011, Week 4
March 2011, Week 3
March 2011, Week 2
February 2011, Week 4
February 2011, Week 3
February 2011, Week 2
February 2011, Week 1
January 2011, Week 4
January 2011, Week 3
January 2011, Week 1
December 2010, Week 3
December 2010, Week 2
October 2010, Week 2
September 2010, Week 3
September 2010, Week 2
September 2010, Week 1
August 2010, Week 5

ATOM RSS1 RSS2



LISTS.CLIR.ORG

CataList Email List Search Powered by the LISTSERV Email List Manager
https://lists.clir.org/cgi-bin/wa?A2=ind1311b&L=NDSA-INFRASTRUCTURE&D=0&O=D&P=1545
lists.clir.org
crawl=CC-MAIN-2021-25
68313
application/http; msgtype=response
sha1:CTS4XZGWFF45EOZDPCUNZKUHNMJ7MKYO
<urn:uuid:190447ee-79e0-4018-a62d-2dd3adce93a2>
2021-06-22T00:45:27Z
66.175.211.245
text/html
sha1:QUIQ36S2MQDDUK5YTWKI3B7WZMZKJVZE
<urn:uuid:33a57080-6a55-4cb5-9e4d-12ded00ab5f5>
https://lists.clir.org/cgi-bin/wa?A2=ind1311b&L=NDSA-INFRASTRUCTURE&D=0&O=D&P=1545
response
<urn:uuid:f81b34ae-b4ef-4b0b-9d9c-0c7d2e1c4ce5>
isPartOf: CC-MAIN-2021-25
publisher: Common Crawl
description: Wide crawl of the web for June 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-177.ec2.internal
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/