For my last CHI blog pre-project launch post for April, I want to include a short discussion of the thought process and decision making that goes into creating a title for a digital project. It has been the part of my project that I’ve been sitting on for the longest time, deliberating between different titles that would best capture the attention of a wider audience and reflect the overall premise of my project. In the end, I decided to go for both catchiness (at least, in my perspective) and connection to the overall basis of the project and the narrative of the website design, both of which are based upon my use of and exploration of Norwegian literature for national identity markers. Therefore, borrowing from the sometimes-wordy, yet descriptive and fun, titles of Norwegian folktales, I decided upon a title that reflects my personal quests for exploring Norwegian literature while also explaining (in a subtitle) the purpose of the project. Stay tuned for next week for the project launch and you’ll see what it is!
The semester is winding down, and my project is beginning to take on its final form. I’ve been finalizing text, references, and glossary terms, and basically making sure the content is what I want prior to playing with the formatting. As I’ve been finishing with the text, I’ve made a few observations I think are worth sharing. Read More
As my website is coming together, I thought it was a good time to reflect on the things came to be. When I first thought of working on Norris, I had grandiose plans about how the website would come together. Beginning to work on the website however, quickly brought these plans down to Earth. One of the first stumbling blocks was thinking of the home page. Originally, I had planned on georeferencing the plan of Norris in order to create a layered effect and a constant comparison between plan and reality as well as past and present. However, when I began georeferencing, I realized that that site plan that I had digitized, was, first, not the final one and second, that parts of the original plan were not built, which made said georeferencing challenging at best, and borderline impossible at worst. So, while I went back to the drawing board (so to speak) in trying to find an updated site plan for the town of Norris, I began piecing together other parts of the website.
This past week I attended the Society for American Archaeology conference in Vancouver, British Columbia, Canada. This international conference highlights the newest archaeological research, and is always the highlight of my year. Visiting a new city, trying new food (this time it was oysters from off the coastline in BC), and seeing new sites are always fun, but what I find most useful is being around so many like-minded people and hearing new and exciting ideas.
I have now created a database of tables about the production and consumption of hydroelectricity in the final decade of colonial rule in Uganda and Kenya, i.e. the years after the construction of the Owen Falls Dam for which I have been able to digitize data (I am also trying to get comparable information from the postcolonial era). The use of phpMyAdmin in WampServer made this a straightforward process, with only the minor hiccough that, at first, I misunderstood how to save work within it. With that obstacle out of the way, it really does make generating SQL easy by using PHP shortcuts to do so.
I think I saw one exception to this, however, and found it easier just to write the SQL manually: in instances where I was generating multiple tables with the same series of keys. These instances included a set of tables that changes in the values of certain variables over time, and a set of tables that compare the same information across multiple townships in Uganda. In these instances, it was faster to cut-and-paste those tables into a new SQL script and change select values for each key than to use phpMyAdmin’s UI to create new keys and values.
Moving on to making PHP script with which to access this database, I learned another thing that the phpMyAdmin UI does exceptionally quickly: generate PHP arrays from SQL tables. I have saved these arrays in Brackets, because they will make it easier to make the form with which visitors to the site will query the database. I have revisited the education in PHP that offered in the O’Reilly “Head First” series, and on CodeAcademy. I need to write PHP script that can pull substrings from within each table (so that users can query specific data points) and that can adjoin tables (so that users can compare information across the narrow range of shared keys that I made the database around).
My last blog post addressed the criteria of inclusion I am using for the Directory of Oneota Scholars. As I was collecting names of scholars, I had to eventually stop and begin working through this corpus to gather information on their current research interests, position, the institution (or entity they are at), and a website for contacting the individual. To track down this information, I have mainly used Google to search for individual’s names on their own and then with ‘archaeology’ in the search bar. It has been a bit difficult to track down current information on multiple scholars: out of 110 scholars, I have no current information on 14 individuals. I will continue to try and gather information on these individuals and begin filling my website with the content. Thankfully, I have already created my website and a coding template for each scholar, and the site is ready to be populated. I hope to finish populating the site with content in the next month. Please comment below if you have any questions about the project!
I have not updated the blog about my project in a while. Its scope has been pared down significantly – as Ethan has said from the start that it would. The main change is that in order to make the creation of a database manageable within the time parameters of the program, given my total lack of experience with SQL, I have had to identify one highly uni-variant form of data within the corpus of economic and environmental statistics that exist in relation to the Lake Victoria basin. I selected tables relating to the production and consumption of electricity in East Africa, for historiographical and methodological reasons. The generation of hydropower at Owen Falls is an emerging point of emphasis in the historiography of East Africa, and will likely have considerable significance within the context of my dissertation. Therefore, I think that data from Owen Falls and other sites in East Africa offers a useful point of focus for this exercise.
It also offers a relatively accessible point of entry into writing SQL, because the information consists mostly of simple X-Y tables with recurring categories, e.g. Power (Horsepower) produced, Light (Kilowatts) consumed. Still, I have had to do some data cleaning, because these observations were not necessarily made to be compared with one another and were not produced in a standard form like Blue Books (at least, I haven’t digitized any relevant Blue Books). This data includes some tables that are pre-grouped. The largest bodies of information among these groups are a time-series that charts power and light production at sites across Kenya and Uganda across a decade, and a set of revised projections for the demand for electricity based on a revised estimate for the cost of power generation. These groups of tables seem to offer the most low-hanging fruit for the linking of tables through SQL – and the most historically-sound use of the language in this context, given the fact that the creators of these tables intended to group them.
The tables in these groups have also categories in common with other tables outside their own groupings, and so through the use of SQL these data can reveal an integrated picture of electricity production and consumption. This can give researchers increased access to the history of the region, but can also impose an ahistorical image onto the hydropower industry in East Africa, because historical actors did not necessarily see the industry in the ways that a database might present it. Then again, this tension can also be valuable in trying to understand the historical trajectory of hydropower.
I attended the event described in the article above. The general purpose of this series of events is to preserve scientific environmental knowledge that is supported by the US federal government and is therefore at risk of loss under the Trump administration. The last sentence of the article best captures the specific purpose of the Toronto event: to create a “prototype” for a process that its organizers neologized as an “archivathon” (a Google websearch of the word doesn’t return any uses outside of the context of this project; a Google ngram doesn’t plot any uses). Around 80-100 people volunteered at the event, which occupied the entire floor of the School of Information’s information library. The volunteers included a core group of organizers including faculty from the University of Toronto and the University of Pennsylvania, and people like myself, i.e. those responding to the organizers’ call for volunteers. Many of the volunteers were vocally uncomfortable with the presence of communications media, both conventional and social, but also said that their presence was necessary (the media being what got us there, anyway).
The organizers asked us to split into three working groups: 1) a group of people doing the heavy lifting of going through the EPA website in advance of a webcrawler program, once the program had been written; 2) a group called “hacker’s corner,” which was geared towards writing the webcrawler and split off into its own separate room; and 3) a group oriented towards overseeing the logistics and structure of the data processing that was occurring in the information library that day. Additionally, the organizers also asked that a small number of people create two ‘floating’ teams of volunteers to go between the three working groups in order to document their work – one team via social media, and one via ethnography. I decided to take ethnographic notes, documenting volunteers’ experiences with the archivathon. I spent most of my time listening to people in the third group.
The third group divided into three subgroups. One included some of the lead organizers, each managing specific logistical tasks; this end of the table was fairly quiet. The other two groups included those who were creating a schema for an inventory of the EPA website. The first was tasked with creating an inventory of the EPA website, and the second with creating a rubric for libraries and other organizations to use in order to identify and prioritize materials for digital preservation in case federal support is cut. The inventory group worked mostly in pairs, each taking a specific section of the EPA website to map out conceptually (again, the character of the Toronto event was preliminary). The rubric group worked as a whole. Its members were heritage institution workers and/or digital humanities specialists, and seemed familiar with the interests and limitations of the people who would be using the rubric. Balancing ease and efficacy in the use of the rubric was an overarching theme here. Listening to each group offered different, albeit brief views into the practice of cultural heritage informatics in a sharply political context.
The past few months have been incredibly frustrating as I made little headway in creating my clickable SVG of a juvenile skeleton using Raphaël.js. By clicking on a certain bone, the user would be taken to another page corresponding to age estimation methods for that bone and use the features specified to come up with an estimated age. Since clickable SVGs are created as paths that have beginnings and endings, each path corresponds to either a single bone or a closed path on a bone. As a result, this means that each bone would have its own link, so to simplify the process, entire regions of bones will be selected at once no matter which bone you click on. The skeletal regions have been split up according to standard anatomical regions: skull, thorax (ribs, vertebrae, sternum), upper limbs (hands, forearms, arms, clavicles, scapulae), pelvic girdle (pelvis and sacrum), and lower limbs.
Although I appeared to have the correct links and format for Raphaël.js, nothing would work and nothing showed up on my webpage. Fortunately, I think I have found a way around that. Instead of linking raphaël.js and my skeletal SVG data paths from separate files, I was able to successfully link embed the SVG data directly into the body of my html page without even using raphaël.js. Downside is that this makes the code on my html page much longer and look less clean. However, it correctly links and works and so I’m happy to have slightly less concise code if it means that one of the main functions will work!
As an example, I’ve copied and pasted my example here (https://jabiggs13.github.io/skull-test/). For right now, the outlines of the skeleton are linked to another website so when you click on a feature, it takes you to eskeletons.org – a website created by the Department of Anthropology at the University of Texas at Austin dedicated to teaching basic human skeletal anatomy as well as focusing on other primate skeletal morphology. (This was honestly the first site that popped in my head when testing to see if the linking feature of my SVG worked).
As it stands right now, there is a major problem that I had not anticipated. The only portion of the skeleton that is truly clickable is the outline of each bone, not the actual bone itself. This was not a problem I had thought about until I finally got everything working. My solution to this problem is basically messing with the original paths and outlines of the SVG so that the space between the outline is filled in and is the actual clickable content. With this process, there are now exponentially more paths, meaning that there are way more individual closed loops that would require their own separate links as the program (Inkscape – free!) is no longer recognizing my grouped regions (i.e. it is not recognizing the ‘ribcage’ but each individual rib or piece of rib that is its own separate loop). Though less than ideal, this may just be the nature of the beast so that each individual path would then have to have its own link, making my skeletal regions less useful as an overarching theme.
Despite this newest hiccup, I am incredibly relieved to be past this one major hurdle do I can now focus on each of the individual ageing methods that will link up to specific bones.