Projects as a Scholarly Genre: Readings 1-3 for 2/24

What exactly is a project? By most business standards today, it could be seen as any sort of plan or operation enacted to achieve a specific aim. For scholars, however, the answer becomes much more involved.

For example, the authors of Digital_Humanities outline how the field of Digital Humanities fits within the broader scholarly work of people in the humanities. The excerpt works through various sets of questions aimed at dispelling typical misconceptions about digital humanities. This spans from fundamental questions about the field, to questions about digital humanities projects, institutions, the evaluation of Digital Humanities work, methodology, outcomes, advocacy, and much more. Ultimately, this piece works to fit the work of academics in Digital Humanities within the more traditional scholarly field, going so far as to argue for the ways that Digital Humanities work builds upon the goals of most academics as a more successful option, for example, the use of post print tools in digital projects.

The other two primary readings work through a structured process that follows the creation and execution of a project, rather than answering questions. Daniel Brown’s Communicating Design focuses primarily on documentation, or specifically, deliverables, “a document created during the course of a web design project to facilitate communications, capture decisions, and stimulate innovation.”(1) In outlining the different types of necessary documentation that often remain an integral part of project creation and execution, Brown gives readers direct insight into the best practices for working on a web-based project. The book is exceptionally practical, carefully organized, and clearly written, making it easy to understand even for readers with little experience in the field of web design and/or web project creation.

By contrast, the IDEO’s “The Field Guide to Human Centered Design” offers some similar advice for project research, conception, and creation. However, it’s primary offering is more rooted in their self-defined philosophy of human centered design. By their definition, human centered design is “believing that all problems, even the seemingly intractable ones like poverty, gender equality, and clean water, are solvable. Moreover, it means believing that the people who face those problems every day are the ones who hold the key to their answer.” (09) Furthermore, those who call themselves human-centered designers are “optimists and makers” who work by 7 mindsets: Empathy, Optimism, Iteration, Creative Confidence, Making, Embracing Ambiguity, and Learning from Failure (10).

The IDEO field guide offers a clear and well organized guide for project processes, from initial inspiration and research, to ideation, iteration, and implementation. In some places, their philosophy seems very centered in the suggested practices (see: the importance of interviewing and immersion to the inspiration process, emphasis on iteration and fast prototyping to allow many rounds of feedback ). However, in others I personally cannot help but feel the advice feels more like your typical workplace project policies than something specifically “human centered” (see: synthesis of ideas through insight statements/how might we statements, integration of feedback, road mapping for implementation of a project).

Ultimately, the contrast of Brown’s book and the IDEO guide had me questioning: how important is it that we, as public historians or those involved in digital history, root our work in a broader philosophy or outlook? Brown and the Digitial_Humanities authors offer us a set of protocols for project creation that offer professionals a guide to prove their work as thorough and legitimate. The act of thorough research, peer review, etc. is what qualifies one’s work to be defined as a successful project based on the concepts laid out in their books. However, for IDEO, it also seems essential that members on their team ascribe to their philosophy to be part of a human-centered design process.

In the future, do you think it would be valuable, or even necessary, to have your team decide on a communal philosophy for project goals, actions, and execution? Or rather, do members only need to agree on a standard of work, as set in Brown’s book? Looking forward to your thoughts on this question and many others below and in class this week!


During the course of this week’s readings, I kept coming back to the fourth axiom in the intro to our text – “Nothing has been preserved. There are only things being preserved.” (p. 5) The title to our text is Theory and Craft of Digital Preservation, and in Chapter 4, Owens fleshes out more what he means by “craft.” Digital preservation is an ongoing process. The frameworks in our readings can be used as tools in directing this approach, but there isn’t a manual per se that explains what to do. It’s about asking the right questions to develop something that is sustainable for your situation. The word “craft” is evocative of an artisan, a glass blower for example – the end products might look similar but each piece is unique.

Image from Wikimedia Commons; CC BY-SA

In “The Emperor’s New Repository,” Chudnov suggests not stressing too much at the beginning about doing everything just right. You can start small and build, change tools, change how you think about the content, and draw on user feedback to guide your changes. My sense was that he didn’t want people to be paralyzed by the possibility of having to scrap or redo the work because they didn’t make the right decision at the beginning. In fairness, when you’re spending someone else’s money, it’s a difficult prospect to have to explain that this is all part of the process. As we discussed last week, we can can’t assume that everyone understands what’s involved in archiving or digital preservation.

Trying and learning from mistakes is still better than nothing though. Our readings last week presented an urgency to this. Setting aside how well you feel professional archivists have this in hand, there’s a lot out there and archivists can’t preserve it all or even anticipate everything that is worth preserving; so if you think something important is slipping through the cracks, you might be the last recourse.


Practitioners don’t have to start from scratch

We can make informed decisions based on traditional archival and preservation practices. People are sharing their experiences and putting their heads together to try to make this attainable even if you don’t do this for a living. Reading, sharing, and talking it out is how we develop the craft.

Oh and another area where archivists can help – documenting decisions. What you did, why you did it, what worked, what didn’t. Owens writes, “Preservation happens because of institutions.…individuals alone can’t do digital preservation.” (p. 78) If an individual tries to preserve a collection alone and doesn’t pass it on to anyone, then it’s not being preserved anymore. When those responsibilities get passed on, either to or within an organization, documentation gives us a context and affects future decision-making. The most frustrating aspects of jobs I’ve had in the past all point to a lack of context to make informed decisions. It means taking the time to ask something I could have figured out myself, or trying something that someone else has already determined doesn’t work, or following the wrong path based on a misunderstanding.


Digital preservation frameworks

This week’s readings focused on two frameworks – Levels of Digital Preservation (LoDP) and the Open Archival Information System (OAIS). LoDP was developed by the National Digital Stewardship Alliance. It takes five concerns of digital preservation (storage and geographic location, file fixity and data integrity, information security, metadata, file formats) and provides recommendations for the types of activities at each level. Level 1 pertains to what are considered the most urgent activities and serves as a prerequisite to the later levels.

In keeping with the idea of digital preservation as a craft, LoDP is a work in progress. An update is underway. LoDP is conceptual. The authors discourage thinking of a preservation program as being at one level. The different concerns listed above can fall at different levels or only partially meet the recommendations at a particular level.

OAIS is more specific than LoDP and deals with repository design from submission to dissemination. Despite the fact that OAIS is now an ISO standard, the report written by the Digital Preservation Coalition still describes it more as a concept than a standard (pp. 3, 31). This means that there’s no official way to tell if a repository is “OAIS-compliant.” (Side note: I didn’t go directly to the source for this because the ISO standard costs $200.)


Theory versus practice

The fact that these frameworks are conceptual didn’t stop me from wanting to harness this theory to something a little more concrete – to think about what Level 3 might look like or how realistic Level 4 is. I work on a digitization program so I have some idea of what goes into the repository, but I don’t work on ingest or design user interfaces. As a student I’ve accessed digital repositories so I understand what I might want, at least right now, from a repository as a user. In this way, I could think about my own experiences to put some shape to the theory. I suppose there’s a danger of oversimplifying when doing that and we’ve seen examples of this in our readings.

Chudnov warns not to “fetishize” software because what works for one situation won’t necessarily work for another, but examples help. One of our optional readings described  DSpace. Even though “[a] repository is not a piece of software” (Owens, p. 4), the author describes it as a digital repository built from open-source software. Still I appreciated the example because it presented specific scenarios for how you could use the software. The article doesn’t mention OAIS, but the description seemed similar to that model. In googling “DSPACE” and “OAIS-compliant” however, I came across this quote from a white paper:

“Digital  preservation is a  process,  not a  technology.  I’m not  quite  sure where  claims  that DSpace  is  ‘OAIS compliant’ came  from, but since OAIS talks about processes, communities and responsibilities,  DSpace itself  can  no more  be  ‘OAIS compliant’  than a set of pliers can be a certified electrician.” (p. 18)



This week’s readings opened us up to the idea that we have a lot of choices in our digital preservation activities, but I wondered if the theoretical basis for some of this would be off-putting for those who have no previous experience. I found LoDP understandable, but still question if readers would shut down at the mention of “fixity” or “metadata.” One thing I like about LoDP is that it uses the language that you need to know to make those decisions.

I know we come from different backgrounds and that we all have different levels of experience with digital preservation. I’m curious to read your impressions and what you responded to.


Why is who saving what, and how?

It seems that when it comes to preserving born digital works, certain questions need to be raised.  In fact, a lot of questions need to be raised since there is no established consensus on which formal framework to use.  There’s the question of “who,” involving the roles different people play in the lifetime of a work.  This includes the artist, the curator, the preservationist, and the consumer/audience. Next there’s the “why”: what makes this work worth saving, and why did we choose certain components of the work to save? Next comes the “what” part: what exactly do these groups decide to save, and what is it that we are actually saving about this work? And finally there’s the “how”—putting a preservation plan into action.

The “who”: Creators, Curators, Conservators, and Consumers

First comes the artist, who creates the work.  The artist makes the initial creative decisions that make his/her work unique, whether intentionally or incidentally. Next comes the curator, who decides that the work is worth collecting and exhibiting and defends the work’s significance.  After that is the preservationist or conservator, who determines what to preserve and how.  Finally there is the audience/consumer and their role in supporting the work.

What makes born digital works so complex is that the roles of these various groups are often bleeding into each other: the artist creates an interactive work that allows the consumer to feel a sense of authorship in making unique decisions that affect the work; the conservators are now asking for statements of intent from the artists to hear their feedback on what’s significant about the work; and fans of a work can prove crucial in providing the emulation software necessary for preserving that work.

Furthermore, as Dappert and Farquhar insist, different stakeholders place their own constraints on a work.  For instance, Chelcie Rowell discusses how Australian artist Norie Neumark used a specific software called Macromedia Director for her 1997 work Shock in the Ear. The audience who experienced it originally had to load a CD-ROM into their computer, which could have been a Mac or Windows.  The preservationists chose emulation as the best method to save works like this one, and these emulators were created by nostalgic enthusiasts.  So each of these people involved placed constraints on the original work, in terms of hardware, software, and usage.  And these constraints changed from its creation to preservation. Dianne Dietrich concludes with this in regards to digital preservation:

“As more people get involved in this space, there’s a greater awareness of not only the technical, but social and historical implications for this kind of work. Ultimately, there’s so much potential for synergy here. It’s a really great time to be working in this space.”

For this reason, it is becoming more important than ever to document who is doing what with the work, increasing accountability and responsibility. Which leads to…

The “why”: Preservation Intent Statements

As Webb, Pearson, and Koerbin express, before we make any attempt to preserve a work we need to answer the “why”.  Their decision to write Preservation Intent Statements is a means of accomplishing this. For, as Webb et all say, “[w]ithout it, we are left floundering between assumptions that every characteristic of every digital item has to be maintained forever.”

And nobody has the time or resources to save every characteristic of every digital item.  At least I don’t.  To try and do this would be impossible and even undesirable for certain works, where the original hardware and software become too costly to maintain.

This leads to a discussion of authenticity. Like Espenshied points out in regards to preserving GeoCities, with increased authenticity comes a lower level of access, but with a low barrier to access comes a low level of authenticity and higher percentage of lossy-ness. In the case of GeoCities, Espenshied says,

“While restoration work must be done on the right end of the scale to provide a very authentic re-creation of the web’s past, it is just as important to work on every point of the scale in between to allow the broadest possible audience to experience the most authentic re-enactment of Geocities that is comfortable for consumption on many levels of expertise and interest.”

And that gets at the heart of why we should bother to create Preservation Intent Statements before implementing any actual preservation actions.  We need to establish the “bigger picture,” the long-term vision of a particular work’s value.  Rowell also points out that there are different kinds of authenticity: forensic, archival, and cultural.  Forensic and archival authenticity deal with ensuring the object preserved is what it claims to be (if you’ve read Matt Kirschenbaum’s book Mechanisms, you know that this can be harder than you think to achieve).  Cultural authenticity, however, becomes a much more complex issue, and explores how to give respect to the original context of the work while still ensuring a wide level of access.

And once we have decided on the best strategy, we then get into…

The “what” and the “how”: Significant Properties Characteristics

Now that we’ve established the “bigger picture,” we get into the details of exactly how to capture the work for preservation.  This is where Dappert and Farquhar come back in.  Dappert and Farquhar really get technical about the differences between “significant properties” and “significant characteristics.”  Their definition of significant characteristics goes like this:

“Requirements in a specific context, represented as constraints, expressing a combination of characteristics of preservation objects or environments that must be preserved or attained in order to ensure the continued accessibility, usability, and meaning of preservation objects, and their capacity to be accepted as evidence of what they purport to record.”

Sounds confusing, right? The way I understood it was that properties can be thought of like HTML properties for coding.  In coding, properties are simply a means of using a logical system language to define certain attributes of the website/game/whatever we are coding.  Similarly, for a digital work, the property itself is abstract, like “fileSize” or “isVirusScanned.”  We aren’t trying to preserve those properties; rather, it is the pair of the property with its value (like “fileSize=1MB”) that we want to capture, and this is what a characteristic of the work is.  You wouldn’t save a property without its value, nor would you save the value without attaching it to a property.  And significant characteristics go beyond the basic forensic/archival description of the object by capturing the context surrounding the object.  Thus, significant characteristics can evolve and change beyond the original work as the preservation environment changes and as different courses of action are taken.  And all of these changes should be documented along the way through these significant characteristics, prioritized and listed by order of importance.

The last question that remains is… is anyone else’s mind boggled by all this?