Search

RIT Museum Studies

preparing museum professionals for the 21st century

Tag

Daniel Krull

Portfolio Project

I’m nearly finished completing the last assignment for this class, the Portfolio project. I initially encountered some difficulties, however, as Omeka was having technical issues and wouldn’t allow me to load my personal page or the RITMUSE Omeka page. This meant that I couldn’t find the “big idea” for my Cast Iron Exhibit from project #3, and I wasn’t able to gather any visuals for my response to project 2 (in which we uploaded a selection of objects from Project 1 to Omeka, WordPress, and Drupal). Omeka eventually began to work again, thankfully, so I was eventually able to obtain the visual documentation I needed. It was somewhat amusing, however, that while I was attempting to create a final summary of my experience working with different content management systems, one of them malfunctioned and therefore slowed me down. Still, Omeka ended up working, and I was able to continue on to screencap the tags I used for the Lodge Loaf Pan, to highlight the way I used the tagging option to provide an additional layer of context about the cookware in my exhibit.

Project 3

For project three, I decided to feature vintage and contemporarily manufactured cast iron cookware from the three companies that are best known for producing cast iron cookware: Griswold, Wagner Ware, and Lodge. The first two companies are now closed, and their products are considered collectors items, while Lodge is a modern company which makes good quality cast iron kitchenware. In addition to displaying over a dozen pieces of cast iron cookware and bakeware, I also highlighted paper advertisements that have been used to sell the cookware, along with photos of each company’s manufacturing plant from either the past or present.

APIs for the Dissemination of Heritage Materials

One topic that our class has recently examined through our readings is the of use APIs (Application Programming Interfaces) to expand the accessibility and openness of cultural materials, collections, and heritage information. APIs essentially provide an automated search mechanism through which one can search numerous digital collections or catalogues. This means that instead of merely being able to examine the heritage materials stored as a local archive or library, one can in fact delve into the digital catalogues of many different cultural institutions, accessing the original materials and metadata that those institutions would have previously offered only to their onsite visitors.

I think most people would likely agree that the preservation of heritage materials and information is important – after all, it’s recently become quite common for the average individual to research their family history to build a genealogical tree. Digitizing these materials certainly isn’t enough, however, as the usefulness of preservation is severely impoverished when accessibility to the materials is poor or nonexistent. APIs, however, offer cultural institutions the means necessary to expand the reach of their catalogues and collections, through which heritage materials can be made available and navigable to a national or even global audience.

Nomenclature for a Cast Iron Pan

I’m currently considering using my assortment of cast iron pans as the focus of my portion for our next project. I have approximately 18 pans (I need to recount – it’s hard to remember when I keep adding to the collection), and I love cooking with them even more than I love collecting them. I did look through Nomenclature 3.0 during yesterday’s class, to see what vocabulary I might be able to use during the project. So far, the best fitting term seems to be “Pan, Frying” under “Cooking Vessels.” I would have liked to discover a more specific term, but the way they’re categorized seems to be more about utility (frying, making muffins, making crepes, making bread, you get the gist) than material (or format, I guess?).  Nom

Continue reading “Nomenclature for a Cast Iron Pan”

Drupal

If you’ve read some of the blogposts from my classmates who struggled with Drupal, then you’ll likely have seen a range of reactions; some really appreciate this content management system (CMS), but offer caveats about where is falls short, others see the potential it has to offer, but were ultimately turned off by significant bugs or access issues, while others still found the entire experience to be a frustrating mess. I unequivocally fall into that first category, as I personally had very little trouble using Drupal to create an online exhibit for SpiRIT, and was able to complete my part of the project in just one class period. This meant that during the second of the two class periods we spent using this CMS, I was able to focus on helping other students work on their own cases, offering guidance and solving bug issues. Overall, I rather enjoyed my time working with Drupal, and certainly wouldn’t be opposed to doing so again in the future.

Our class as a whole, however, did run into some frustrating issues over the past week. We initially struggled with gaining access to the archive’s instance of Drupal, although that is more a tech support issue than a problem with the CMS itself. Still, seemingly at random, certain images in our digital exhibitions would fail to auto-shrink on their pages, and instead extended off the page in awkward ways. We also had issues getting the “Carousel Image” aspect of a larger exhibition to work properly, meaning that the thumbnail for the first-listed section of the exhibition was automatically used as the entire exhibition’s thumbnail, no matter what we tried to do to solve the issue. In one positive turn of events, at least, Jody Sidlauskas (RIT’s Associate Archivist) and I were able to tentatively solve the image resizing issue, by uploading .PNG files instead of images in the .JPG format. During my tests, that change has always fixed the issue, so hopefully that frustration with Drupal won’t bother us in the future.

Ultimately, I really liked Drupal’s potential, even though its quirks and a messy back-end slowed things down at times. It’s certainly not perfect, however, and I sympathize with those in my class who are happy to have this part of the project behind them

Omeka

This week’s foray into Omeka has certainly been interesting. While I do like WordPress, and it can be quite useful for certain applications, I’ve found the more metadata focused nature of Omeka to be particularly intriguing. WordPress is very much a blogging platform, while Omeka seems more well-suited to supplying and disseminating a greater level of detail, as can be seen in the extensive metadata options one can add to the automatic Dublin Core set. The native ability to include transcriptions with a object is another feature which I found to be rather nice. So far I’ve merely posted various items from my SpiRIT exhibit (along with their metadata) to our Omeka page, but I’m looking forward to delving further into the possibilities the platform has to offer.

Working with WordPresss

So far, working with WordPress to to create a blog-style digital exhibition of my case has been rather pain-free. I have worked with the platform before, but even so, it is generally pretty intuitive, so I haven’t run into many issues. One slight hiccup I did notice, however, occurred when one of my featured images was large, but not so large that it was automatically scaled down on the main page. I was posting about the Letter to the Editor, which is physically about 2″ x 5″. The scanned version’s sized made it look awkward on the main page because unlike the scan of the RIT Reporter cover, it wasn’t quite large enough for WordPress to just auto-scale it down. I spent some time looking through the photo editing options the platform offers, but didn’t find any solutions. I tried to just resize the image to make it larger, to see if that would cause the auto-shrinking to occur, but that was also unsuccessful. Ultimately, I decided to place the image of the clipping on a wider white background, so that it wasn’t so long and thin. This ended up working, as you can see below.Workaround Documentation

SpiRIT the Tiger

In 1963, a “Tiger Council” made up of RIT students purchased the two-month old Bengal tiger, SpiRIT, to serve as the school’s mascot. While SpiRIT was housed at a local zoo, the tiger was also brought to campus for a variety of events, so that students could interact with their mascot. Students trained as the tiger’s handlers, such as David A. Page (’66), formed particularly close relationships with SpiRIT, which made the animal’s untimely death in 1964 particularly difficult. In 1967, the tiger’s pelt was preserved, so that future generations could also experience the once-living embodiment of Student Pride in RIT.

Continue reading “SpiRIT the Tiger”

Student Pride in R.I.T. Poster

This 11×17 inch poster is entitled “Student Pride In R. I. T.” Created for a campus celebration, this piece includes a close-up photo showing the face on SpiRIT’s preserved pelt. The photo, “The Spirit of SPIRIT,” was taken by David A. Page, a class of 1966 Fine Art Photography undergraduate student who also served as SpiRIT’s handler.

Create a free website or blog at WordPress.com.

Up ↑