Word Salad: Data Edition.
Over the past week, I have worked on multiple projects, all of which indirectly support my dissertation in one way or another. For the Unknown Ottawa project, I was trying to connect Omeka S to Borealis via API. This has been a struggle. To clarify, Omeka S is a platform to house and share data using personalized websites. It’s like a fancy online museum where you exhibit collections and perform Digital Public History.
In contrast, Borealis is a large data repository supported by numerous Canadian institutions, and it uses the Dataverse to link open data. We are using Borealis to store the collected data with all the metadata. The goal was to get Omeka to connect to the repository via an API key and pull data into the website. In essence, to make the data publicly available since not everyone can access Borealis.
The problem I am encountering is that the module used in Omeka to connect to Borealis appears to be doing what it should be doing. It finds Borealis, connects but then, nothing. It can not find the repository. Even with the API and a DOI, Omeka cannot access the repository. As of now, a possible solution is that we may need to move the data into its own Dataverse repository and not Carleton University’s repository. I have a meeting about this shortly and will post about its potential application in another post. If you would like to read about the above processes in more detail, go to my Open Access Notebook, click on 10-19 Research, and go to 16 Process Notes, where you will find notes 16.01 and 16.04, which describe what I’ve done.
I have also been testing out JupyterLab for my supervisor. He is using the Jupyter environment to teach his Digital Archaeology course. The notebook environment uses Python and he has set it up as a PKM (Personal Knowledge Management) repository where students can execute code, collaborate and create a PKM environment. For my part, I am the Guinea Pig for testing the initial setup using a Mac. Overall, it has been a smooth process. We aim to identify any possible glitches students may encounter when setting up the Jupyter environment. That is, are there dependencies needed, etc. The only issue I have come across was the installation of R (another programming language) and its kernels into Jupyterlab. I installed R on my main OS, but integrating it into the Jupyter environment took some tinkering, but we believe the problem is solved. Don’t ask me how; this is way out of my league. I am given the code to execute, I do so, report back, and then do some more testing. Again, Guinea Pig. But I am learning a lot. Experiential learning at its finest.
In the world of Obsidian, I started playing around with the beta release of a new core plugin, Bases. It's basically an internal database manager that uses a kind of linked data system to explore your vault. “Database, you say? Didn’t you call Obsidian a pseudo-database manager a while back?” Yes, yes, I did, and I was dunked on by many of the Obsidian faithful. See Theorizing the Vault. Oh, how the tables have turned. Anyway, the point is I need to rethink how I do my properties for my notes since Bases uses properties (the metadata) to extract whatever calls you put into it. In particular, I am concerned about tags. The reason is that I put tags in the main body of my notes. This allows users of the OAN to search connected notes via tags. However, if I place tags into properties, they can not be seen on the frontend of the OAN. Putting tags into properties and the note's main body doubles the vault's tag count. I am unsure if this is a concern, but I need to explore this in more detail, which is why I have not posted more micro-posts on creating a note. I need to sort this out.
lastly, I am developing my Crafting Digital History course for the fall 2025. It is an 3000 level asynchronous course. For the course, I will be using Obsidian as the primary digital tool for the students to do their research. I want the students to critically assess how they make notes, how they identify their notes and data, and how to analyze their notes to create a public-facing digital deliverable. The courses topic will focus on the East Roman world and how it is represented via digital platforms and the tools used to create these narratives. The course will be broken into three modules with three working weeks and one consolidation week (thank you, Shawn, for this idea). The course is going to be theory and methodologically heavy with a focus on generous thinking (Fitzpatrick 2019) and productive failure/failing gloriously (Graham 2019). Rethinking the impact the ‘digital’ has on perpetuating the ‘Byzantine’ narrative is different idea for a course, I think. Students will be encouraged to pick a topic in Roman history and focus on that topic for the semester, exploring different digital representations and creating, hopefully, a vast repository in obsidian. Thats it for now. The course development is only in its infancy.
