Dublin Core, Stephanie Falkowski

Tropy is a useful program for organizing images and this post details getting started with this application.

Installation was simple and straightforward, and upon opening Tropy, the first thing was to create a project. I started with a generic “Project 1” so I could see how it would work before I had an idea for a sample project.

Tropy allows you to change the name of projects as you are working on them, simply by clicking on the title and selecting “rename project.”

As the new title suggests, this first project now centers around the biblical story of the healing of the paralytic at the pool of Bethesda found in John 5:1-15. I have various images (paintings, maps, models, etc) relating to this passage that are in a variety of different file formats. Entering them into Tropy is done via the highly user-friendly method of drag and drop.

What makes Tropy so useful is that you can enter metadata for each image. Though Tropy has it’s own suggestions for metadata fields, it also has the option to use standard Dublin Core – which I used for this project. In preferences, this can be set to the default, so the first fields you see are those corresponding to Dublin Core categories.

Adding tags is done by simply selecting the item or items you want to assign a tag to and under the tab in the right hand panel there is a place to click and add such information. There’s even an option to customize tag colors.

Continuing to learn about and use Dublin Core, in this project I got more practice collecting this information and filing it into the correct Dublin Core fields. I chose six items all relating to the crusades and relations between East and West. Five are books, and one a journal article.

There are certainly limitations to using only these fields. Not all relevant data can be fit into these fields. For instance, even to properly format a citation from one of these items, one needs more information, such as place of publication. For journal articles it is even worse, with no clear place to put the name of the journal. In this example, I first put this information under source, but then thought this would be problematic if I were to decide to use source to track other information, such as who digitized the older books that weren’t born-digital. For this reason I thought again and put the name of the journal under publisher, though that can obscure who published the journal.

Another difficulty is that with only a creator field, it is difficult to distinguish between authors, translators, and editors. Using only standard Dublin Core fields also introduces other ambiguities, as it disguises the categorical differences between articles and monographs for example, both having the identifier of “text.” With nearly everything being “text,” this becomes a less than helpful designation. Even in the format description this distinction cannot be discerned, as I opted to not enter the dimensions, weight, etc. of the physical book, but the electronic version I am actually accessing, whether it is a pdf or an epub – all these items happen to be in PDF format. Coverage was a difficult field, as this is not always clearly included in descriptions and subject keywords. Sometimes it can only be determined by actually looking through the book and its contents.