DH Dev Report 9: Documenting the DH Process—Notes

Home Page

 "Managing 100 Digital Humanities Projects: Digital Scholarship & Archiving in King's Digital Lab"

  • DH is most prominent in EU and NA, less prominent in AS and AU, and even less prominent in AF and SA. This characterization reminds me of our discussions/readings about race and how whiteness is the predominant viewpoint propagated in DH.
  • There are no technological standards when it comes to preserving/archiving in DH.
  • Many legacy DH projects are security risks and have little funding
    • Raise awareness of issue
    • Evolve management of DH infrastructure
    • Attention to full lifecycle of projects
    • Inventive funding
    • Sharing costs across agencies/institutions
  • Any solution must address the DH scholarship itself, funding/operational issues, and the entropy of technology
  • King’s Digital Lab dedicated to research software engineering
  • Design and engineering of software and its supporting infrastructures is a problem that needs to be conceived as at once technical, political, economic, and human
  • Of the 100 projects inherited by the lab, about half are either of exceptionally high quality or seminal in other ways
  • Protecting/securing these DH projects is difficult, as it faces
    • Technical/financial realities
    • Critics
    • Corporatization of higher ed
    • Gaps in national policy
  • Many projects were kept running but not maintained (i.e. outdated tech)
  • Pressures shouldn’t be hidden, they should be explored
  • This paper is written in a bad font. PIs looks like Pls (please)
  • Open-source tools lower the risk (increase security). Why is that?
  • The funding for projects described in this paper only supported development and not post-launch maintenance
    • The future of many projects was not discussed
  • Defunding of Arts and Humanities Data Service and the AHRC ICT Methods Network undermined future of projects
  • DH needs to be grounded in the nature of computing technology and capable of guiding technical development as well as critical and historical analysis
  • The tech industry is biased towards newness at the cost of maintenance
  • DH needs to assess its own tech requirements and not just blindly adopt infrastructures that are used elsewhere
  • View DH as a human and community asset that needs maintenance rather than a purely tech asset that needs management
  • There is a dearth of permanent DH teams/jobs, which is a failure of the field at the human level
  • High quality research requires sustainability
  • King’s Digital Lab kinda stacked with infrastructure tho
  • Maintenance requires consistency in tech
  • Some projects should be archived online but don’t require constant, hands-on maintenance
  • Assess digital material by considered
    • The heterogeneity of projects
    • Mismatch between scholarly value and metrics such as web traffic
    • Uneven access to funding
  • Assess in terms of
    • Scholarly value
    • Technical complexity
    • Security risk
    • Maintenance cost
    • Infrastructure cost
    • PI engagement
    • Institutional support
    • Value to KDL
    • Value to King’s College London
  • Assessment made in prose form, not according to a matrix (i.e. a rubric) to articulate the nuances of quantitative and qualitative issues
  • PI – principal investigator
  • Have to consider the ‘brand’ value to the university
    • This seems to have no relation to the actual scholarly or cultural value of a product. Fucking management amirite
  • KDL accounts for the human, technical, financial, and political perspectives in DH
  • People should experiment with new tech, but not at a cost to the maintenance of old tech. sustainability should be accounted for in the beginning stages of a project’s lifecycle

 

The Internet Archive Software Collection

From a pure gaming standpoint, I don’t think the vast majority of these games should be archived; they’re shite. The controls are clunky and frustrating, and the gameplay isn’t smooth at all. However, from a historical perspective, I believe that these games should be archived because they are evidence of the progress the video game industry, and technology has a whole, has made. I think the advancement of technology is made apparent by video games perhaps more than anything else by nature of them as a visual medium. The difference between television 50 years ago and television today is pronounced, but nowhere near the disparity between games 50 years ago and games now. Comparing a game like Pac-Man or ET to games like Witcher 3 or Valorant is like comparing a horse-drawn carriage to a Ferrari.

 

The Future of Your Data

  • One failure of DH is how they age: people who worked on projects initially might not work on them now, the technology used to make the project might be outdated
  • Consider how you might save/preserve your digital content, whatever that content may be, so it is easier to use/access in the future
  • Digital formats require updates
  • Physical limitations: losing a flash drive, dropping your phone, component failure, bit rot
    • Physical mediums constantly degrade
    • Files stored on physical mediums can degrade
    • Everything has a lifespan
  • Physical mitigations: backups, organize/migrate files every few years, check sums, controlled storage (cold, low humidity)
    • Checksum – every time you make a checksum, it should be the same, if the checksum changes, the file has changed
  • Software limitations
    • Software is constantly changing
    • Common limitations: can’t open a file format, unable to run a script, website broken
  • Software mitigations
    • Complete redo in new technology
    • Upgrade
    • Combination of the above
    • What was the original like? Do you have any ways of getting it running (e.g. emulator)? What were the important parts, and can you salvage them?
  • Provider Limitations
    • Provider – a third party providing a service to your project (e.g. cloud services, hosting site)
    • Unexpected expenses
    • Company goes out of busines
    • Changes to laws, regulations, or policies
    • Malicious actors (e.g. DDOS attack)
    • Retiring products or services
  • Provider Mitigations
    • Make a plan for the worst casef
    • Be aware of emails, correspondence from provider
    • Keep a copy of your data
  • Human limitations
    • The original developer is gone
    • No instructions
    • Not enough knowledge to fix or redo
  • Human mitigations
    • Write everything down and put it in a place you can find it
    • Choose commonly used tech
    • Make a plan for the future
  • The more pieces in a project, the more complex it is, the more susceptible it is to failure
  • Before you start:
    • What’s the minimum viable product? What do you need and what don’t you need?
    • Choose or create standards; metadata, file naming conventions, where you put stuff
  • Collaborate
    • Identify collaborators
    • Who is responsible for what?
    • How will you communicate?
    • How do you credit everyone?
  • Set up documentation and issue tracking
    • Find location for documentation
    • Think about technology for documentation
    • How will you keep track of ‘todo’ items?
    • Who can access all of this stuff?
  • Choose tech carefully
    • What do you need it to do?
    • Is it widely used and supported?
    • How much maintenance will it need?
    • Can you easily train someone to use it?
    • Will your data be stored within the system or outside of it?
    • Plain text and non-proprietary formats? Proprietary format – specific to a specific piece of software/technology/company
  • Think about money
    • Figure expenses now and in the future: website and file hosting, staff/consultant wages, software purchases
  • Make plans
    • Will the project ever ‘end’? how will you add new things? What if you find mistakes?
    • What if you are asked to take part down?
    • What if part of the site stops working?
    • How might you gracefully retire it?

 

Voyant

  • I pasted in some of my notes for a paper I’m working on for another class, and the results weren’t accurate; they missed/failed to account for one of the words that I used most, ‘K’, in their standard report. I think that this feature is generally good, as it omits words like ‘a’ and ‘the’, but in this specific instance the omission was significant, as ‘K’ is the name of the protagonist in the film I’m analyzing, Blade Runner 2049.
  • You can export the results of analyses on Voyant, but I’m not sure if exporting produces static assets or assets linked to the webservices provided by Voyant. If it’s the former, the assets would be more future-proof.

Comments

Popular posts from this blog

Let's Explore!

DH Dev Report 5: The Message is in the Medium—"A Comparative Analysis of Digital Tools Part 2: StoryMap, GeoJSON, and Analog Technologies"

DH Dev Report 1: UNL Campus in a Post-COVID World