Week 4

This week, our reading focused on building digital collections. Some of the popular platforms for building these collections are Omeka and Scalar. Although they accomplish similar goals, Omeka and Scalar have very different capabilities. 

Omeka is primarily designed for creating and managing digital collections, archives, and exhibits. It is often used by cultural heritage institutions, libraries, and museums to showcase and organize digital assets, such as images, documents, and metadata. It also seems more focused on the curation and visual presentation of digital assets, making it well-suited for showcasing historical documents, photographs, and other archival materials. However, it’s pretty static in its delivery. It has a more straightforward and catalog-esque interface that makes it easy to organize and present digital collections. While Omeka has a lot of structured, clear digital collections options, it definitely has some restrictions when it comes to creating very complex narratives or interactive content.

Scalar is very different. It allows users to integrate more media content in a more narrative structure. It would be really great for projects that want to provide a more interactive and visually interesting reading experience. It offers a more flexible and dynamic interface that results in more storytelling as well as a blend of media elements within the text. Although Scalar’s visual capabilities are more visually interesting, I found that Omeka was easier to work with. Certainly if I had more time to dedicate to learning Scalar, I would have chosen to use it for my project. But, for a week-long project, I found the back end of Omeka to be a little more user friendly. Callie helped me quite a bit though (thank you!). I think this is ultimately a fair trade off though. More work on the back end results in a friendlier user interface on the front and vice versa.  

Idea.org’s article, “Mapping the world of cultural metadata standards”, talks about the way that Metadata and language are connected. Metadata is necessary for making information useful and searchable. It is the data about other data, like titles, locations, or descriptions of things, and it allows for better organization and searchability. To make sure metadata is universal, rather than specific to a person or institution, a variety of standards have been established to make sure that a common language is used. This practice makes it easier to share, manage, and search through the site’s information.

Jenn Riley created a map of 105 prominent metadata standards that are used in the cultural heritage/humanities fields. These standards help codify the way that data is labeled and structured. A common tongue prevents confusion when different systems are used, basically creating a universal way to categorize and classify information. Search engines can quickly find documents based on keywords, but taxonomies (the specific jargon/organizational language of a specific field) can offer a more nuanced, structured approach, which provides alternative pathways and associated ideas.

In libraries, cultural heritage, and the humanities sectors, clear metadata and taxonomies are crucial. But, the vastness and extensiveness of the metadata standards can be overwhelming. For this reason, Jenn Riley’s map is such a gift for people like myself who are just getting started in this field. Like buying a translation dictionary when you start learning a language, the map is a helpful jumping off point for people that aren’t familiar with industry practices. It sheds light on these standards and how they relate to one another, ultimately helping to make sense of the complex landscape of metadata in the digital age.

Metadata is a crucial part of creating a user-friendly site, but it’s a small part of the overall creation. Paige Morgan’s blogpost, “How To Get A Digital Humanities Project Off the Ground”, details her two DH projects that she finished while she was working on her PhD. (Phew!) I think she does a really fantastic job of laying out the issues she encountered, while not sugarcoating things or making the reader think, “why would I ever do a project like this?”. I understand that it can be difficult to convince academics to include DH as part of their research or in lieu of a book or article. In the world of “Publish or Perish”, I think that Morgan makes a compelling argument for why upcoming academics can view DH as an alternative way to present your research. Her article isn’t instructional, but I can imagine that anyone starting on a DH project would read it and get good information and some encouragement. It seems like this is a cool trend in the DH space. Lots of articles and projects we’ve looked at have included a little (or a large) retrospective piece about the troubles they encountered and how they solved them. It seems like despite the competitive nature of DH (based on the short lifespans of digital projects because technology moves so fast), many people are committed to including elements of transparency in their projects. 

Leave a comment

Your email address will not be published. Required fields are marked *