Wednesday, May 2, 2012

Clayton's Project Reflections

Considering the rough road that we had this semester, I am very pleased with how this assignment has turned out.  I am certain that the success of the project is due in large part to the group that we had assembled for it.  All of the group members live in the Nashville area, so it was quite easy for us to get together to work on it.  In addition, the vast majority of what we do as DE students is online, and it is nice to have a respite from being tied to the computer to get anything done.
It made sense to divide up the responsibilities of the assignment among the group members for both the project proposal and for the implementation of the project itself.  The delegation of tasks made it easier for us to work independently, and then put the pieces together.   Admittedly, this worked much better for the project and less so on the proposal.  No matter the circumstances, it is difficult for five people to write one paper because we all have our particular styles of writing and putting the parts together does not always line up.  I believe, however, that we managed the challenge pretty well with our proposal.  The assignment of tasks for the project itself was very effective and allowed each group member to focus on one area and become a relative expert.  Although, one downside of this method is that I do not feel that I learned much about those parts that I did not work on, such as the metadata portion.
Our project certainly started off on the right foot, in that, Joon already had the images that were to comprise the digital library.  It would have taken longer to start from scratch.  Truly, throughout the project, our group seemed blessed with good fortune.  Each step went as smoothly as it could have.  The question as to which content management software platform to use and where to host the site were the only real difficulties that we faced.  Once we learned that Omeka was easy to use and provided free server space, the decision was a no-brainer.  Indeed, as the group member that uploaded the image files and such, I can say that Omeka was easy to use.  The only issue that I had with Omeka, as mentioned in our presentation, was the limited number of themes that could be used for the site.  Granted, this was likely due to the fact that we were using the free version.  There are probably more themes available to site administrators if they are willing to pay for them.
All in all, the experience was a good one.  I am glad that we were able to do a project that provided some hands-on training in digital librarianship, rather than the same-old-same-old research paper option.  Again, my stellar group contributed to the positive experience and made it all the more enjoyable.

Tuesday, May 1, 2012

Jami's Final Thoughts...

I can’t say that I learned anything particularly new from this final project of building and implementing a digital library. Instead, the experience reinforced my assumptions about implementing a collaborative project. I don’t mean to imply that the project wasn’t worthwhile. On the contrary, I appreciated the opportunity to work with my colleagues and explore new technologies. In many ways, this project has mirrored my experiences in the “real world” work environment. Our group members had varying degrees of knowledge and expertise and we had no one to guide us through the process. While this led to periods of frustration, we were able to work through the challenges and produce a fine result.

As the project comes to a close, here are my final reflections:

A digital library is only as good as the collection that it represents. As with any project, I think the quality of the end product relies on the quality of the original concept. From our first meeting as a group, we knew we had the potential for a great project given the extraordinary work of our group member, Joon Powell. Joon’s images tell a fantastic story. I think we were all excited about the prospect of sharing that story with a wider audience.

Collaboration is the key to success. As I mentioned above, each one of us came to the project with a different set of skills and experience. Additionally, we had to turn to individuals outside of our group for technical guidance (an important lesson: you have to be willing to seek and accept help when necessary). Everyone brought something new and relevant to the project. This collaborative effort allowed us to contribute our individual areas of expertise and to learn from one another.

Communication and flexibility are essential AND a great team is invaluable. Looking back, I think it is remarkable that we did not assign a project manager. By the end of our first meeting, we delegated individual responsibilities. Each one of us knew what we were supposed to do and accepted full responsibility/ accountability for making sure our tasks were complete. As all of our tasks were related to one another, there were times that a change in one area affected the design or progress in another area. We quickly learned that things don’t always go as planned. While we had a proposal to follow, we remained flexible in our approach. So, when complications or obstacles arose, we were able to either rework our plans or adapt. Despite not having a “leader,” we managed to make it work through constant communication with one another at each stage of the process.

Sometimes, you just have to make do with what you are given. I found the Omeka platform to be lacking in a few areas. For instance, the themes and user interface were dull and limiting. However, given our limited time (and nonexistent budget), we ultimately chose Omeka because it was free and quick. We also knew that we had access to technical guidance through the UT library (thank you Bridger!).  I’ve encountered similar situations in my work experience. The decisions on choice of tools and equipment (such as hardware, software, ILS systems, etc.) are ultimately driven by the budget and not by functionality.

There's no substitution for hands-on experience. This is the second SIS course that I've taken that provided a direct opportunity for hands-on experience. I can't imagine that I would have had the same gratifying experience had I chosen to work individually on a traditional research paper. 

Tara's Reflection


This project can be deemed a success in many ways.  I have not had the opportunity to do something so hands-on during my time at SIS.   From this project, we are able to have a concrete result from our work, available online for any prospective employer to see.  There were some road blocks and frustrations, mostly in the administration of the project at the beginning.  Once we set our minds to just getting it completed to the best of our abilities, the forward progress was apparent. 
Based on the structure of the original proposal, we divided up our tasks with the intent that we would each have some equal workload.  Although I think we each initially volunteered for an area of our “expertise” (or at least some background), I personally knew that I needed to gain some experience in areas in which I had no solid foundation, especially metadata.  I had no experience at all in website design, but I volunteered for the task.  Although I did not start much of my research for my annotated bibliography on content management systems until after we got deep into this project, combining my task of researching Omeka with reading about other CMS’s really helped solidify what I practiced with this project.  By the end of the project, when we were actually uploading the files and metadata, we all met together and attempted the uploads together.  None of us had ever created a website before so the actual creation process was something we all needed to see and do. 
Although the five of us had not all worked together at once, each of us had worked with another in some capacity in past classes and therefore had someone to vouch for our accountability and performance.  I understand that not all projects, in the academic or professional world, are granted this advantage and for that, I am extremely grateful I was able to work with the people I did.  We each knew our assigned tasks and no one failed to deliver on their part.  We did seek some much needed advice and instruction from Bridger outside of class that helped us understand exactly what Omeka could and could not do.  Most of our progress was simply trial and error, especially when it came to the actual implementation.  We uploaded the images twice and the metadata at least three separate times in an effort to get them to link together. 
If this had been an actual digital library, I would assume that there would have been a little more feedback and criticism from the host institution that may have required more research or modifications on our end.   I was a little frustrated with the lack of “pizazz” offered by Omeka, but we knew that we were working with the free model.  None of us had any experience or understanding of how we would even go about using the server model, although I think that project would have been even more valuable.  Had this class been dedicated to the creation of a digital library all semester long in conjunction with content lectures, I know that many students would have really benefited from the hands-on and practical experience of going out to the web and actually creating something tangible.  Overall, this was a valuable project, and I wish that other SIS courses did similar projects.  

Monday, April 30, 2012

Cassie's Reflection: Looking at the Digital Library in the Mirror


               I have learned many things from this digital library experience, but it is tough to evaluate whether my expertise increased significantly or not. I feel that many of the conclusions our group came to in regards to metadata, guidelines, the technical aspects of the project and navigating Omeka were guesses that eventually made some sort of sense via trial and error (and research, of course). This might always be the case, however, if there is not digital expertise in-house, and of course each new experience builds upon the last. Knowing that this learning curve exists for beginners, and that there may not always be an expert available to show one the ropes, taught me that if I should pursue a digital library project in the future, seeking outside feedback from experts, consultants or colleagues in the beginning phases would be helpful to give the project shape and direction. Exploration is the necessary first step of any project, and with so much information available on the subject, as well as the collective knowledge of digital librarians everywhere, it would be helpful to seek out guidance from those trusted sources.
               I learned that a good team is essential in completing any successful project because there are too many steps for one person to do, and each of the steps is dependent on the other. Because of this inevitable overlap and cause and effect relationship, the members of the team must have a strong skill set and specialized knowledge, or at least a willingness to learn, and of course tenacity to see the project through all the inevitable technological difficulties. Fortunately, our team was just such a team, and we were able to rely upon one another throughout the entire process. I have been continually impressed with my teammates’ knowledge and abilities, and my own knowledge has expanded because of this interaction.
               I would have liked to have had more hands on experience, but the responsibilities were fairly and necessarily divided. Therefore some of us “did” and some of us planned. However, I do feel that my knowledge of the “how-to’s” from start to finish have increased significantly from what it was before. As we asked questions, found answers, and then questioned the answers, there was a lot of learning taking place, and valuable resources were found for future reference. As I continue to expand my knowledge in this arena, I would like to have actual experience working in a digital library in order to understand how things are run when there are resources available and protocol is set. Understanding workflows inside a library setting would be greatly helpful.
               All in all, I definitely learned that planning is essential, and that you have to be ready for things to go wrong. When they do, however, there are plenty of resources available to help you figure things out. Troubleshooting, teamwork, and a commitment to excellence are all key components in the creation of any successful digital library.

Tuesday, April 24, 2012

Joon's Final Reflections


As this semester draws to a close, I would like to reflect on this final Digital Libraries project. I think my group members will agree that this project has been quite valuable. As a group, we were able to draw from a diverse pool of skill-sets and talents, delegating appropriate tasks and reconvening after each milestone. Perhaps most impressive was our ability to trouble-shoot. Thankfully, as graduate students we have an extensive network of information professionals with whom we can consult when our own resources have been exhausted. I hope my group members will also celebrate our success.
A last detail we decided to polish up was our tags. We all decided we would add a few tags to five items. I believe types of illnesses, region of TN and a number of other concepts were encompassed by these index terms.  We considered using Medical Subject Headings (MeSH terms) but decided since the people using this library were not necessarily medical professionals, that laymen’s terms would be more recognizable to the social justice community. The terms we decided on maximized the library’s usefulness and accessibility. Another finishing touch included picking an image to be showcased in the final site’s banner. I kicked around a few ideas with Clayton but in the end we decided to have that image rotate, in order to keep the site a little more dynamic.
If I had to critique the final site, I might alter the thumbnails of the portraits to better frame some of the subjects. Overall I think we had a clean simple interface though. I also thought our final presentation to the class was quite successful, with each of us creating our own individual slide, describing our delegated part and then touring classmates through the finished product. I think we each spoke for similar lengths of time and answered questions pretty effectively.
After listening to all the presentations for all the projects, I feel that I got a sense of just how diverse digital libraries can be. They are really a great way to reach all kinds of different people. From Appalachian musical instruments to graphic novels to social justice, digital librarians offer a trove of information to anyone who can cross the digital divide. I hope that librarians like Melanie and Bridger, who specialize in metadata practices, are valued by the institutions that house their work.

Monday, April 16, 2012

Metadata Guidelines

The following list contains the name, description, and example of use for the Dublin Core elements to be included in the metadata for The Faces of TennCare image collection. The full set of guidelines, "Using Dublin Core - The Elements", are available on the Dublin Core Metadata Initiative (DCMI) web site.

Title. The name given to the resource. Typically, a title will be a name by which the resource is formally known.

The Title is comprised of the name(s) of the individual(s) photographed. Do not use abbreviations or symbols and do not underline or place the title in quotations.
Example:  Mike and Nancy Frankich

Description.  An account of the content of the resource. Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or free-text account of the content.

Since the Description field is a potentially rich source of indexable terms, care should be taken to provide this element when possible. Best practice recommendation for this element is to use full sentences, as description is often used to present information to users to assist in their selection of appropriate resources from a set of search results.

The Library of Congress provides several guides to describing and cataloging photographs on its web site at http://www.loc.gov/rr/print/cataloging.html.

Type.  The nature or genre of the content of the resource.

The Faces of TennCare is comprised of images. Therefore, "Image" (capitalized without quotations) should be used in this field.

Creator.  An entity primarily responsible for making the content of the resource. Typically, the name of the Creator should be used to indicate the entity.

Personal names should be listed surname first, followed by given name.
Example:  Powell, Joon

Rights.  Information about rights held in and over the resource. Typically, a rights element will contain a rights management statement for the resource, or reference a service providing such information. If the rights element is absent, no assumptions can be made about the status of the rights with respect to the resource.

Example:  ©2006 The Faces of TennCare. Images may not be copied, printed or otherwise disseminated without express written permission the rights holder or its agents.

RightsHolder.  A person or organization owning or managing rights over the resource.

The RightsHolder for all images is Joon Powell (format as written).

Date.Created (maps to Date).  A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability of the resource.

We will use the qualifier, Date.Created, to make this more specific.
If the full date is unknown, month and year (YYYY-MM) or just year (YYYY) may be used. Many other schemes are possible, but if used, they may not be easily interpreted by users or software.
Example: 2006-02-16

Format.  The physical or digital manifestation of the resource. Typically, Format may include the media-type or dimensions of the resource. Examples of dimensions include size and duration. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource.

Example:  TIFF

TechniqueCapture (maps to Format).  See above.

In this case, we are using this element to provide information on the type of equipment used to capture the digital image.
Example:  Digital photograph taken with a Canon EOS DIGITAL REBEL.

Location (maps to Coverage).  The extent or scope of the content of the resource. Coverage will typically include spatial location (a place name or geographic co-ordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity).

Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [Getty Thesaurus of Geographic Names, http://www. getty.edu/research/tools/vocabulary/tgn/]).
Example:  Cookeville (Tennessee)

Identifier.  An unambiguous reference to the resource within a given context. Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system.

The Identifier will be the image file name. Each image will have a unique identifier consisting of the lowercase letters 'ftc' (acronym for Faces of TennCare) followed by a 3-digit number.
Example:  ftc_001

Uploading the Content

Our group convened at the Nashville Public Library (our de facto "office") to finalize the csv metadata document and upload the content to our Omeka site. Many thanks to Bridger from UT for his guidance and advice on the metadata and csv process!

The process did not work as seamlessly as we had hoped. On our first try, the csv document didn't import properly due to the commas in our text. On the second attempt, the images didn't link to the metadata (we had items with images and no metadata). On our third attempt, we succeeded in importing the csv file and linking the metadata to the image files, however it created all new items (thus, doubling the number of items--so we had a few items with metadata but no images). Clayton is going to resolve this by just deleting the photos and uploading them again to the new items we created. 

Our next task was to address how we wanted to assign subject headings or tags to our images using a controlled vocabulary (such as Medical Subject Headings (MeSH) or the Library of Congress' Thesaurus for Graphic Materials (LCTGM). We ultimately decided to assign tags to the images. We will discuss this matter further in a subsequent meeting.

Finally, we turned our attention to the design theme of our site. Unfortunately, there are few choices available when using the free version of Omeka at omeka.net. So, while we aren't overly thrilled with the aesthetic design of our site, we at least enjoyed the satisfaction of seeing the fruits of our labor online for all to see.