Yesterday I read an article that I want to celebrate here:
“From Notes to Networks: Using Obsidian to Teach Metadata and Linked Data” by by Kara Long and Erin Yunes, code4lib Journal, Issue 61, 2025-10-21.
This is its abstract:
In this article, we describe a novel use of the note-taking software Obsidian as a method for users without formal training in metadata creation to develop culturally relevant data literacies across two digital archiving projects. We explain how Obsidian’s built-in use of linked data provides an open-source, flexible, and potentially scalable way for users to creatively interact with digitized materials, navigate and create metadata, and model relationships between digital objects. Furthermore, we demonstrate how Obsidian’s local and offline hosting features can be leveraged to include team members with low or unreliable internet access.
You should read the article in its entirety to learn what the authors have done and are now sharing.
This is why I particularly enjoyed the article: think the authors are suggesting that the strength of Obsidian is not inherent in the technology, but in its affordances that allows for everyone involved to see the back-end of a database, to contribute language to the work, and to experience the consequences of not using controlled language. Some of the qualities of Obsidian that allow for these affordance is that the software is free to use, it works offline, it can be synchronized with other instances, it works in plain-text, it is not controlled by venture capital, and it can extended with a myriad of plug-ins, among other features.
But what I particularly is especially worth celebrating is that the authors used the software for “making with” their community, instead of buying and “making for”.
Yes, Obsidian is just a wiki but hear me out: because it is a wiki, the system requires that each person that contributes to it must commit to a controlled vocabulary. Otherwise, if there are two variations of a person’s name (for example one with a middle name and one without), the collection will express them as two different people.
It is worth noting that much more structured digital collection systems like Omeka allow for items to be manually placed in item-sets and other structures without such required discipline. These systems could require that items had to be described using Dublin core, but they do not demand that a shared authority file or controlled vocabulary must be used to describe persons or place-names. As such, many of these digital collections have a wealth of tags that are specialized and suit each individual collection, but hold little consistency across and between other digital collections. This practice discouraged the work of integrating these digital collections into the shared library catalogue and to treat these collections as separate digital work performed outside of the library’s existing technical services department: a symptom of Digital Disease in Academic Libraries.
About ten years ago — when academic libraries were creating so many of these digital collections — we missed an opportunity to create or contribute to a shared local authority file for our community that we could continue to build upon. (If you want to know more why I think controlled vocabulary is a core function of academic libraries, please read Libraries and Large Language Models as Cultural Technologies and Two Kinds of Power).
Of course, using Obsidian does not resolve these larger issues. I’m just suggesting, as the authors do, that Obsidian might be an appropriate development space for community database creation that can later be staged in production in a more robust linked data environment, like Wikibase.
The Dangerous Harbors project has several aims, including the development of lesson plans and educational resources for teachers and community groups, and the publication of the dataset and corresponding records in formats that are accessible and reusable. Working with Obsidian has provided a more inclusive environment to discuss linked data with stakeholders and team members who may be new to these methods of knowledge organization. And, it allowed us to explore different ways of representing the relationships in the data before transferring the data to a Wikibase.cloud instance. [12] The Wikibase software offers more in terms of data publication, querying, and integrating data from external sources; however, we plan to continue to use Obsidian as a staging area and jumping-off point to engage new and returning team members in data modeling discussions. At this stage, the team continues to use a shared spreadsheet to export data to Obsidian and Wikibase; however, viewing the data in Obsidian has revealed errors and inconsistencies that were difficult to detect when working in a spreadsheet alone.
As an aside, if a future database is to host traditional bibliographic data, Zotero and OpenRefine are other sites where work can be staged and prepared before being added to a Wikibase instance.
I’ve been writing quite a few posts as of late about how more libraries and librarians should take on the work of developing their own databases and indexes for their community. There are several reasons why I am advocating this development: the collapse of local journalism, the ascendancy of centralized large language models which may be usurping services like reference desk assistance and the use of Wikipedia, and to remind librarians that we have roles to play other than that of a discerning consumer engaged in collection management.
