Data Management Plan for the COVID Student Archive

Definition and Scope of Data

The data maintained by the COVID Student Archive team (the team) which falls under the scope of this Data Management Plan (DMP) consist of the following forms of information (collectively “the data”): 

  1. Digital content files submitted by content contributors, consisting of audio visual media, text, and graphic files.
  2. Metadata submitted by content contributors, consisting of digital text describing the digital content.
  3. Digital consent agreements agreed to by content contributors, agreements with other 3rd parties, and team collaboration agreements and plans (such as this DMP).
  4. The application level source code for the public facing website.

Out of scope of this DMP are intermediate digital content files and source code that can be regenerated by non-proprietary media and source code editing applications; data, files, messages, and notes related to project management and communications with the GC Digital Humanities program and course; and promotional materials and data associated with publicizing the project.

Roles and Responsibilities

The team will be solely responsible for implementing, monitoring, and adhering to the DMP.  One team member will be designated as the principal account administrator (archive administrator) of the data storage archival services repositories (archive backups), which will serve as the repositories of the “original” versions submitted by the content contributors.  A second team member will be designated as the backup administrator (backup  archive administrator) for the archive backups.  Team members who handle the data will be responsible for adding the data to and accessing the data from the archive backups.

This DMP will be maintained and periodically updated by the team. Standards for  documentation and the implementation of the DMP will be maintained by designating the DMP as a priority of the project; by establishing ongoing review tasks; by delegating review and reporting tasks to one or more team members. The responsibility for data management will be shared by the team as a whole and tasks associated with the DMP will be assigned to team members as they arise.

Data Collection

The data will be collected primarily by means of, but not limited to, online forms and digital content upload capabilities.  The data may also be collected via email and other file transfer protocols.  As part of the collection process, the team will be responsible for adding the data to and retrieving the data from the archive backups. 

Data Storage, Protection, Access, Sharing, and Archiving

Data storage of the data will be maintained through redundantly hosted file storage services such as Box.com, Amazon.com, Dropbox.com, and Google Drive.  Redundancy will be assured using backup strategies such as maintaining backup “archival” read-only and not-easily-deletable copies of each file and working copies of each file.  The account administrators will generally have access to the archive backups and team member accounts will generally have access to the working copies of the data.  Redundant copies of the the data will also be maintained on the public facing website together. Copies of the website code will be archived through waybackmachine.org and where ever possible in Internet hosted GIT repositories such as Github.com and/or Gitlab.com.  For audiovisual media files, should systems storing the archive backups fail, are destroyed, or are stolen, the data files will be regenerated from redundant copies of the files.

Data Format and Documentation

The media types covered by this DMP include text, video, audio, and graphics and are editable by software programs, including text viewing/editing and word processing software such as universal text viewers/editors; video/image/audio editing/viewing/displaying/playing software of various kinds including but not limited to non-proprietary applications such as Audacity, VLC, and proprietary applications such as Adobe Creative Suite and Microsoft Office.

Directory naming conventions will be established that map each directory to a content contributor; file naming conventions for the files and directories will conform to consistent naming conventions associated with identifiers of the project, based on such aspects as function, display location, edition, and version.  The project identifier will be a standardized abbreviation/acronym of the project name; data identifiers will consist of unique abbreviations of the content contributor alias; the alias will be either part of the content contributors name or a unique alias name given to the contributor.

An adjudication process for any concerns and/or non-compliance relating to the DMP is defined in the COVID Student Archive Collaborator Agreement.

Data Confidentiality

While there are no requirements to collect and maintain high-security data, the collection and maintenance of Personally Identifiable Information (PII) will conform to the consent agreement each content contributor will be asked to enter into.

Re-Use and Re-Distribution of Data

There are currently no data sharing requirements.  The audience for viewing the data is the general public. The general public may view the data as produced and according to the license agreement associated with the data. The data will be published for access by the public on an ongoing basis during and subsequent to the release date of the project sometime during the Spring of 2021. The general public may access the data using any computing device and software capable of rendering digital media.

Long-term Archiving and Preservation

The data will be retained for as long as the project is maintained.  When the project is no longer being maintained, the data will be either destroyed or maintained in accordance with agreements with 3rd parties associated with the project.  For the archive backups, the team will generally follow the guidelines of the CUNY Graduate Center Guide for Data Management and non-proprietary file formats maintained by the University of Maryland (https://lib.guides.umbc.edu/c.php?g=728911&p=5872066).  The active members of the team will maintain the data for the long-term.

NYC Community Fridges Archive’s Data Management Plan

∎Data Description (Nature, Scope, and Scale)
The Methods of Data Collection

  1. Data will be provided to us by community fridge organizers.
  2. Gleaned from online resources: collected on social media profiles, from thefreedge.org website, and from the fridges’ websites.
  3. Crowdsourced from the local communities through the contributions to our NYCCFA website as part of our outreach plan.

→ We will also produce Project Management data and documentation as part of our work.

The Scope and Scale of the Data

We will produce the spreadsheets of text and numerical data related to the NYC community fridges in the beginning of the project, as we will need them to create the structure of the Archive. We will update the data regularly to account for new fridges and their new information. When the crowdsourcing campaign starts, we will collect texts, documents, images, and audios from the archives collaborators. We expect to have a surge of contributions as a result of the crowdsourcing campaign; after the launch of the archive, the rate of contributions will probably plateau.

∎Processing of the Data

The Processing (Identifying, Cleaning, & Remediating) of the Data

The data tables with identifying information about NYC community fridges are being created and cleaned on Google Spreadsheets and Excel; they will be used to create the Archive structure, as each data point will become the page dedicated to one of the Fridges in Omeka. These data tables will also be displayed as an interactive map using the Geolocation plugin on Omeka Classic. The data table with identifying information about outside collaborators is created, edited, and kept on Google Spreadsheet for ease of use and to facilitate collaboration; it will be kept for our internal use and not shared in the public-facing site – apart from our list of acknowledgments on the website. The audiovisual, text, and document data that is collected as part of the crowdsourcing campaign will be stored on our server and shared in our public-facing archival collections. Plugins available for Omeka Classic will be used to collect the aforementioned data and store it for future access.

∎ Storage and Backup

The Method of Storing the data

Once we are done with the data cleaning process for the identifying data for NYC Community Fridges, we will convert the data to a .csv format and store it on our personal computers, on a USB flash drive, and in a Dropbox folder; all these options will be password protected, as they might contain people’s contact information. The collaborators’ identifying data table will be converted to a .csv format after the project launch and kept in password-protected folders on our personal computers, a USB flash drive, and a Dropbox folder. Crowdsourced materials will be converted to preservation formats and backed up to a hard drive. Members of the team will regularly perform maintenance and update the stored data with incoming data.

The Regeneration of the Data

It is possible to regenerate the data tables about NYC Fridges by following the Data documentation and Data dictionary documents. We are taking steps to ensure the survival and usability of the data with multiple data storage options and regular back-ups and maintenance. However, in the case of unprecedented and irreparable data loss, the archive will be damaged or lost.

∎ Documentation

The Documentation of Data Collection Procedures

For identifying information about the fridges and our collaborators, we will document our data collection and cleaning procedures in a Data Abstract document. Omeka will enable and constitute documentation of data provided through contributions. We will also write a Data Abstract to document the process of contribution in a narrative form.

The Strategies of Ensuring Good Project Documentation

We will ensure good project documentation through our work plan and timeline, our meeting minutes, and a summary of our group tasks from Trello. We will ensure good data documentation through the Data Abstract and Data Dictionary documents, which we will save as a PDF file in the same folder as our .csv data tables.

∎ Data Identification and Format

Directory and Conventions of Naming the Files

Our directories will be organized in a flat hierarchical structure as is appropriate for our data which come in distinct categories. File naming will align with this structural organization that aligns with our Omeka database to assure seamless interoperability.

Identifiers of Project and Data

At the top level, directories will be organized and named including our Project Title and Borough (Geographical Location); followed by Fridge Title; followed by Item Type; followed by Contributor and Date of Submission.

Standards for Data Formatting, Description, Interoperability, or Sharing

We will be using DublinCore Metadata Standard as it is integrated into Omeka; to provide structure to our data and to make it searchable and discoverable.

∎ Intellectual Property Rights, Ethics, and Privacy

 Controlling of the Data (By Whom?)

The project team controls the data.

Special Privacy or Security Requirements

The data tables that contain information about our collaborators will be password-protected, as they contain contact information. For the data contributed to our database of the Website, the contributors will be given the option to keep their personal information private as they register as users to the website. For further requirements including consent, we will consult with the IRB Office at CUNY GC to comply with any required IRB procedures.

Embargo Periods to Uphold?

We do not have any embargo periods to uphold.

∎ Reusability of Data (Access and Sharing)  

The Purpose of Sharing the Data 

We are sharing the data we collect online because the purpose of the project is to publicly document the fridges.

The Audience of the Data

The community that revolves around the fridges (they can use the data to preserve their memories and to access information); NYC residents who would like to gather more information about the fridges and how to contribute to them; archivists and historians.

The Publication of the Data (When?)

We will publish the data in Spring 2021 on the NYCCFA website.

The Tools/Softwares of Accessing the Data

The data tables we store:  .csv files will be accessible with any spreadsheet software (Excel, Google Spreadsheets), but also with Python, R, SQL, and other programming languages that support .csv.

Accessibility of Crowdsourcing Input   

As far as the crowdsourced materials are concerned, they require a web browser and an internet connection to be visualized on Omeka. All kinds of preservation files will be kept on a hard drive, which will be accessible for any computer with a USB port. A copy of the preservation files will be kept on Dropbox, accessible from devices with an internet connection, with a password.

∎ Data Retention, Format, and Archiving & Preservation

Data Retention

The data will be retained permanently as part of the NYC Community Fridge Archive mission to preserve the historical memory of NYC Community Fridges..

Format of data and its sustainable accessibility

The textual and numerical data will be preserved in csv tables; images will be kept in jpeg format;  text submissions in txt or pdf format; sound files MPEG-4 or mp3 format. These formats are accessible for the foreseeable future as per GC Library, as noted by Stephen Zweibel, Digital Librarian at Mina Rees Library.

The Long-Term Responsibility of Data Maintenance

The project manager will maintain data for the long-term on her hard-drive and Dropbox.

The characteristics of the Data Archive (Subject-Data Archive? Institutional Data Archive?)

We will create a subject-based Omeka Classic archive for our data. The NYC Community Fridge Archive is a subject-based archive created to collect and preserve the memory of community fridges in NYC. It is created and maintained by digital humanists.

 

Mapping Cemeteries: Data Management Plan

1. What are the types of data that may be produced as part of this project?

Our project will generate data specific to five cemeteries, as well as data for the timeline visuals which will combine all five cemeteries data into one. We expect to have both primary (generated by team members) and secondary data (found by team members).

  • How will data be collected (e.g., instrumentation, observation, survey, etc.)?
      • We are gathering data between February and Mid-April, 2021, based primarily on research from digital archives, journal articles, and digital sources we have access to (either through our CUNY affiliations or are freely available to the public).
  • Is it possible to regenerate the data? What are the implications for your research if the data are lost or became unusable later?
      • Yes, our data (e.g., dates and locations) will be reproducible, though we may come to slightly different conclusions about it if our supporting text is also lost.
  • What types of data will be produced?
      • images: historical images (based on licensing availability) and present-day images taken by our team members at the selected locations
      • videos: taken by our team members at the selected locations
      • audio: to increase accessibility to our text, interviews with funerary experts, and accompanying podcast documenting our process of building this project
      • text: descriptions and narratives produced by our research
      • location data: longitude and latitude of cemeteries to produce map pins
      • code: to build our website
      • metadata: for each page of our site, as well as each media item that appears on it to ensure searchability and accessibility
  • What are the tools or software you will be using to create/process/analyze/visualize the data?
      • Google sheets, Google docs, Mapbox, timeline tools like TimeLineJS or Vuetify
  • What are your access, storage, and backup strategies?
    • All primary digital assets (images, videos, and audio) will be stored on Wikimedia commons. Our main tool for storing data will be a spreadsheet. Each sheet will be filled out by all team members as they do their research.The spreadsheet will include multiple sheets:  
      • general/map
      • horizontal timeline
      • vertical timeline
      • historical cemetery
      • cemetery repurposed as park
      • cemetery war memorial
      • cemetery rediscovered
      • established/other cemetery

2. What standards will you be using for data collection, documentation, description, and metadata?

The spreadsheet will reside on Bri’s google drive, GitHub repository (in a csv format, as well as a link to the google drive in the Read.me file), team members’ local machines. Version control is built into the Google spreadsheet so we can see how/when the data is updated, and changes to our website code will also be versioned and saved within GitHub. And we are documenting our weekly contributions to the project via individual diary-like updates in our Mapping Cemeteries Commons group.

  • How do you document data collection procedures?
      • We are noting all of our data collection via our shared Google sheet. Each sheet will include the following list of columns that is subject to expand:
        • name
        • custodian
        • caption
        • description
        • data type
        • purpose
        • tag
        • source link
        • citation
        • Institution
  • How will you ensure good project and data documentation? Who is responsible for implementing this data management plan?
      • All team members are responsible for implementing this data management plan; our names will be next to all data we enter onto the sheet.
  • What directory and file naming conventions will you be using?
      • We will follow Tidy data and other best practices. All file names will use underscores (_) instead of spaces, and they will include dates to aid in version control. Information about our files will be included in a Read.me file with a data abstract, as well as a data dictionary as needed.
  • What project and data identifiers will be assigned?
      • Data will be organized via cemetery/memorial location. Historical data we include in our vertical timeline will be organized separately.
  • Will you use disciplinary or community standards for data formatting, description, interoperability, or sharing for any of the data you collect?
    • We will follow all disciplinary standards, and customize to our project needs as necessary.

3. What steps will you take to protect your or your participant’s security, privacy/confidentiality, intellectual property, or other rights? (Check current university policies for requirements.)

  • Who controls the data (e.g., PI, student, lab, University, funder), and at what level?
      • Team members control the data.
      • Google docs reside under Bri’s account as she may be using this for future phases/capstone project.
  • Any special privacy or security requirements (e.g., personal data, high-security data)?
      • We will make sure to use up-to-date software and upgrade as necessary to avoid any vulnerabilities. Additionally, no personal information will be stored on our site.
  • Do you have any embargo periods to uphold?
    • No

4. If you allow others to reuse your data, how will the data be accessed and shared? What are the data sharing requirements your work is subject to (e.g., funder, journal)?

  • Who is your possible audience? Who may use the data now, or later?
      • We are planning an initial “soft launch,” so our initial primary audiences are our classmates and attendees at the GC Digital Showcase.
      • Going forward we expect our audience to include:
        • New York City historians, especially those interested in the macabre, necropolitics, and lesser-known or “forgotten” histories
        • Scholars and members of the public studying cemeteries and memory studies
        • People offering and interested in taking walking tours and practicing alternative forms of tourism
      • Bri may expand on this project for future phases and/or for her capstone project.
  • When will you publish the data and where?
      • We will share all of our data on GitHub, and media we create will be shared on Wikimedia. We will publish our data on our website, and we will also share our findings in Clio as a potential walking tour, with links back to our website.
  • What tools/software are required to access your data?
    • Users will access our data via our public-facing website, social media posts, and Clio.

5. How will the data be archived for preservation and long-term access?

  • How long should the data be retained (e.g., 3-5 years, 10-20 years, permanently)?
      • Our data will be retained for 3-5 years, at which point this DMP will be re-reviewed to determine whether longer-term access is required.
  • What file formats will you be using, or converting to? Are they sustainably accessible?
      • Our data spreadsheet will be saved in csv format, and a link to the Google docs will be included in the Read.me file stored on GitHub. Text will live in Word and Google docs, and be backed up in rich text non-proprietary formats. Images, video, and audio files will be saved as JGP or PNG, MP4, and FLAC files (or other non-proprietary format), respectively. The non-proprietary formats will live in GitHub, and both proprietary and non-proprietary formats will be stored in our Mapping Cemeteries Common group library.
  • Who will maintain my data for the long-term?
      • Bri
  • Which data archives are your data appropriate for (subject-based? institutional)?
    • Our data archives can be appropriate for New York City history, New York–related migration studies, and Digital Humanities archives

*Posted by Nadia, Lisa, Asma, lane, and Bri*

ReadingRebus DMP

ReadingRebus DATA MANAGEMENT PROPOSAL

  1. What are the types of data that may be produced as part of this project?
    • How will data be collected (e.g., instrumentation, observation, survey, etc.)?
        • High-resolution rebus images from cultural and scholarly institutions (libraries, galleries, archives, and special collections)
        • Bibliography collected from scholarly and library databases, booklist
    • Is it possible to regenerate the data? What are the implications for your research if the data are lost or became unusable later?
        • Regeneration of research conclusions through textual citations and image credits
        • The website has its own files in its repository
    • What types of data will be produced, how much, and at what rate? Are the data types or the creation rate of data expected to change over time?
        • Website metadata created by us
        • Descriptions and metadata of individual rebuses (between 20-30)
        • Content (essays) and analyses created by us
        • Code for website development
    • What are the tools or software you will be using to create/process/analyze/visualize the data?
        • Microsoft Word, Google Docs, Google Sheets for word processing
        • NET and Adobe Photoshop for graphic design and in case a rebus image needs to be cropped, resized, or restored
        • Discord for group analysis and communication
        • WordPress website with plugins
    • What are your access, storage, and backup strategies?
        • Monthly local and cloud backups of the WordPress website, images, database, and code from the web server
        • Casual local backups (informal)
  1. What standards will you be using for data collection, documentation, description, and metadata?
    • How do you document data collection procedures?
        • Audit log – (shared) document where, when data is collected, the collector or project manager will enter the date of data collection and a brief appraisal or summary of the data.
    • How will you ensure good project and data documentation? Who is responsible for implementing this data management plan?
        • Patricia responsible for data management regarding website and code
        • Bianca responsible for data management regarding documents and process materials
    • What directory and file naming conventions will you be using?
        • Naming will emerge from a combination of disciplinary conventions (i.e. puzzle identifying keywords; institutional cataloguing of visual and print ephemera; etc) and the categories that derive from our corpus as we amass it.
    • What project and data identifiers will be assigned?
        • Identifiers will be assigned according to main categories/tags of rebuses that constitute our data set. These may include time period, geo location, type of rebus, theme, image/word-based, genre, medium, publisher location, language, etc.
    • Will you use disciplinary or community standards for data formatting, description, interoperability, or sharing for any of the data you collect?
        • We expect to use disciplinary standards; at the same time, we may well develop and implement our own terms that further the understanding of rebuses as a corpus across location and time (any such terms will be shared in a data key or dictionary).
  1. What steps will you take to protect your or your participant’s security, privacy/confidentiality, intellectual property, or other rights? (Check current university policies for requirements.)
    • Who controls the data (e.g., PI, student, lab, University, funder), and at what level?
        • Project team controls data
        • Reproduction permissions will be granted by institutions
    • Any special privacy or security requirements (e.g., personal data, high-security data)?
        • Website will have standard security measures (ssl, anti-spam, malware monitoring)
        • Personal data will not be stored on the website
    • Do you have any embargo periods to uphold?
        • No
  1. If you allow others to reuse your data, how will the data be accessed and shared?
    • What are the data sharing requirements your work is subject to (e.g., funder, journal)?
        • Class data sharing requirements
    • Who is your possible audience? Who may use the data now, or later?
        • Audiences may include:
            • Etymologists and linguistic analysts.
            • Historians, anthropologists, and those interested in those fields.
            • Puzzle and rebus enthusiasts.
            • Word and Image scholars, scholars of visual culture
            • Digital Humanities students, colleagues, and the NYC DH community.
            • Wordsmiths and semioticians.
    • When will you publish the data and where?
        • Publishing the data via the website starting march 2021
        • Also publishing data on social media starting march 2021
        • Course blog will also contain data
    • What tools/software are required to access your data?
        • Access via Public-facing wordpress website and social media accounts
  1. How will the data be archived for preservation and long-term access?
    • How long should the data be retained (e.g., 3-5 years, 10-20 years, permanently)?
        • Website will be maintained for 3-5 years.
    • What file formats will you be using, or converting to? Are they sustainably accessible?
        • Image file formats (jpgs, tiffs, gifs) provided by institutions
        • Website pages in html, php, and javascript
    • Who will maintain the data for the long-term?
        • Patricia for now will maintain data
    • Which data archives are your data appropriate for (subject-based? institutional)?
        • Subject-based data archives could include: word/image archives; 18th-19th century European and American visual/print culture; Communication studies; Digital Humanities archives.

 

Bio

Greetings,

Asma (ahs-ma) N. is a Brooklyn native, Digital Humanist, Black feminist, and a graduate student at The Graduate Center, CUNY. She uses audio/technology to discourse her broader philosophical research interests in gender, social ontology, and digital humanities to develop original content in public scholarship. Asma cares about creatively transposing what’s meta about experience into accessible language and technology alike. Her other central topics include beauty politics, digital space and identity, and sound studies — all in relationship to Black women and individuals who are the priority in her work. 

Asma has a strong background in research and advocacy, having maintained a handful of fellowships across reproductive health, leadership, and diplomacy during and post undergrad at the University of Maryland, College Park. She’s also held appointments as a coordinator of education and training for diversity initiatives, and educational data management in the sites of D.C./Maryland and New York City.

Asma is 1/5th of the team, Mapping Cemeteries, which is a digital humanist timeline project that explores the relationship between identity and death across four distinct cemeteries in New York City. She contributes her research skills in language, methodology, and analysis, as well as project design, strategy, and audiovisual modulation.  

Most of the above says more about her professional abilities and less about who is Asma. Somewhere at the core are the matters of the head and the heart that speak to love, wellness, and Halloween (her favorite time of year).

a.

Bio note

Ostap Kin is an editor of New York Elegies: Ukrainian Poem on the City (Academic Studies Press, 2019), and the co-translator (with John Hennessy) of Serhiy Zhadan’s A New Orthography (Lost Horse Press, 2020) and (with Vitaly Chernetsky) of Yuri Andrukhovych’s Songs for a Dead Rooster (Lost Horse Press, 2018). He holds an M.S. in library and information science from Long Island University and is presently working on an M.A. in digital humanities from the Graduate Center of the City University of New York. Kin works as Archivist/Librarian/Research Center Coordinator at the Zimmerli Art Museum, Rutgers University

Eva’s bio & contributions

Eva Sibinga is in her final semester of the Grad Center’s Data Analysis & Visualization program. Her research interests include data ethics, the intersection of race and technology, and the application of feminist theory to contemporary data questions. With a background in English Literature and Visual Art, her approach to data analysis and visualization is motivated by a desire to expand the way we tell stories and understand the world through our own eyes and others’.

Eva is one half of Freedom of Speech*’s core data and developer team. She will also support the project’s outreach effort, and hopes to improve her understanding and skills in UX/UI design by applying some time and effort there as well.

A Report on the NYCDH demonstration “Reclaim Your Academic Cyberinfrastructure”

On Friday, February 12th, I attended a Zoom presentation entitled “Reclaim Your Academic Cyberinfrastructure”. The demonstration, which took place on the last day of the New York City Digital Humanities (NYCDH) conference, was facilitated by Jim Groom, a co-founder of the web hosting company Reclaim Hosting and the cloud services company Reclaim Cloud. As the sponsors of NYCDH, Reclaim Hosting and Reclaim Cloud provide internet services tailored to the higher education community, making web hosting and cloud services affordable and user-friendly to much of the NYCDH community. The company’s donation to NYCDH will go to the next round of NYCDH Graduate Student Awards.

In the two-hour demonstration, Jim provided a detailed evaluation of and deep-dives into traditional web hosting and the more recently adopted technologies of cloud services known as Platform as a Service (PAAS). The overall takeaways are: all else being equal, traditional web hosting (Reclaim Hosting) is still a cost-effective option when the needs of a project conform to the standard (PHP-based) web hosting applications for small to moderate web traffic. If the needs of the project require technologies not easily supported through tradition web hosting or a high level of usage and traffic, cloud services (Reclaim Cloud) offer a potentially cost-effective and technologically superior alternative.

Shared/Managed Hosting (Reclaim Hosting)

The first hour of the presentation covered the pros and cons and primary features of web hosting.  Among the advantages of web hosting are cost-effectiveness, familiarity, one-click installers, user friendly management suite of internet services including applications, email, and domain management (DNS). The drawbacks include software limitations (limited or no support for Java, Python, or Ruby applications), scaling problems, administration complexity, potential  security issues, potential  performance issues, and a lack of group collaboration features and user management utilities. The primary user interface for web hosting is the administration tool “Cpanel”.

Cpanel

A screenshot of the main screen of Cpanel.

Web hosting through Cpanel commonly runs on the LAMP software stack, consisting of Linux, Apache, MySQL, and PHP.  Cpanel includes a one-click installer through extensions such as Fanastico, Installatron, and Softaculous, which enable the installation of dozens of applications, including archive management platforms such as Omeka, Scalar, and content management systems such as WordPress, Droopal, and Joomla.

Cpanel-One-Click-Apps

A screenshot of the one-click installable applications in Cpanel.

In addition to one-click installers, Cpanel includes a web-based file manager, which provides access to all the files under the users home directory. Plugins such as those for Omeka can be uploaded; users have the capability of adding and editing files in the root web directory under public_html. Cpanel includes gateways to database administration tools such as phpMyAdmin for administering MySQL databases that maintain the data behind data driven applications. Administration tools are also available for adding and configuring either sub domains (e.g. dhpraxis.reclaimhosting.com) or add on domains (e.g. dhpraxis.com).

Cloud Services (Reclaim Cloud)

Cloud services provide control over the entire software environment starting at the operating system level, in which users create and administer one or more containers of operating systems, server processes, and applications. The advantages of cloud services include horizontal scaling (number of servers) and vertical scaling (amount of RAM and CPU horsepower), team administration, and built-in support for security and performance. The drawbacks to cloud services include potentially higher costs depending on the use case, and a higher learning curve in configuring and administering the containers, operating systems, and servers, and applications.

Container based approaches to segmenting Internet computing resources allows for a wide range of scripting languages, web servers, databases, and operating systems.  While cloud services provide for support for most Linux distributions, a notable exception is the lack of support for Microsoft Windows. As a result many applications built on Linux based technologies other than PHP are available through cloud services, including Discourse, Geoserver, Mattermost, Mastadon, Jitsi Meet, Manifold, R Shiny Apps, and Jupyter Notebooks. 

Jim provided a tour of the Jelastic container administration environment including the Reclaim Cloud Marketplace, which serves as a one-click installation repository for the most popular applications, such as Omeka Servier, R Studio, Voyant Tools, HAXcms, Adapt Learning Authoring Tool, Azuracast, and Cantaloupe Image Server.

Jelastic PAAS Environment

A screenshot of the Jelastic Interface.

Cloud services have become standardized through Docker container technology, which facilitates the creation of configuration files known as Docker files and the copying of OS images called Docker images that represent snapshots of a given operating system and any installed servers and applications. As an example of the process of creating a container, Jim stepped through the creation and configuration screens of a WordPress installation and PeerTube. 

One of major differences between cloud services and web hosting is the pricing and payment model. While web hosting charges flat monthly and annual fees, cloud services have generally followed Amazon’s approach in charging for compute time by the hour. A summary of Reclaim Cloud pricing can be found at https://reclaim.cloud/pricing/.

In addition to container services, Reclaim Cloud sponsors a community hub for information centered around technologies of interest to educators and digital humanists. Given the wide range of options and configurations, the Reclaim Cloud community provides a important space for battle-tested advice, tricks, and tips for navigating the powerful and complex environment of container based computing.

Bianca’s bio/contributor’s statement

 

(Bianca)  F.-C. Calabresi is an early modern scholar and teacher, specializing in book history and the cultural production of women in Europe.  She has written on rubrication as simulated blood, alternative female literacies in sewn samplers, and pseudo-Italians on the English stage among other topics.  Her current academic project explores the dubious legacy of the Battle of Lepanto and its continued weaponization in the 21-st century.  She brings her skills as an editor and proofreader to Reading Rebus, as well as her experience in group management, in the roles of Project Manager and Fact-checker/Copy Editor.