skip to main |
skip to sidebar
ePods is a collection of eighteen podcasts, both audio and video, intended for educational purposes in K-12 classrooms with content suitable for both teachers and students. I chose to collect individual podcasts as well as podcast series that focus on science and technology content to limit the scope of the taxonomy. This allowed me to think about developing a controlled vocabulary specific to the content and observe it in practice while adhering to the application profile I developed based on Dublin Core elements.
There are many sites that aggregate educational podcasts, but most are not repositories and do not generally cater to only K-12 users. I believe there is a need and subsequent opportunity to develop an educational repository for multimedia objects that is both relevant in content and easy enough for teachers and students to use in a classroom setting. I found that, with a little patience and practice, Drupal’s underlying modular architecture allows developers with little to no experience create a powerful repository and user-friendly interface. Drupal was chosen for this project for a number of reasons, but especially because members of its enthusiastic user communities regularly create and share customizable features and modules that can be integrated to existing sites with minimal impact on their functionality.
I used Instructables.com as a model for ePods because it is both a community and a repository with faceted classification and sophisticated browsing functionality. While it is not intended for use in K-12 classrooms, the content of Instructables is educational and often contains more than one format type per entry (audio, video, images, text, sound). The site also allows users to add their own Instructables projects and comment on content. This type of participatory, community environment is what I envision for ePods and is something that Drupal can accommodate.
Drupal’s interface is accessible to all levels of users and can be as simple as a single webpage or as complex as a repository of repositories. Once the basic settings have been configured, Drupal can be a blog, a repository, a social networking site, an e-commerce site, an organization’s main website, a wiki, or all of those things. So, for example, if ePods begins as a repository, Drupal’s modular architecture is flexible enough to build off of this basic structure to create a multi-faceted site beyond what other systems like ePrints and DSpace can provide.
Many types of organizations use Drupal for collections and customized features to make them accessible on the Web. Institutions like the Indianapolis Museum of Art and Alabama’s Hoover Public Library, countries like Belgium, and companies like ABC Family are using Drupal to power their content collections, public websites, and community sites. Because ePods content is inherently multimedia, these different types of uses and support for most file types made Drupal an obvious front-runner when choosing an application. To organizations on a perpetually tight budget, its low cost of ownership (server space) sounds even better when juxtaposed with its flexibility, extensibility, and ability to be easily upgraded, adapted, and repurposed over time.
The Drupal user community provides many resources for developers at all levels of technical proficiency. The countless tutorials and ongoing discussions about installing modules, customization, and troubleshooting are invaluable to developers and are what makes Drupal so appealing to organizations like libraries with limited IT budgets and many types of content. Drupal’s OAI-PMH module and support for faceted classification is another draw for educational institutions that wish to share their collections with many different types of communities. Applications like DLIST and ePrints offer similar user support, classification, and open metadata harvesting, but lack the modularity and flexibility that Drupal provides.
The Application Profile developed for ePods is heavily based on Dublin Core elements. In creating the submission form for new ePods objects in Drupal, the basic elements (Title, Audience, Institution, Format, Language, Subject) are required. Keywords, Source, Copyright, Instructional Method, and Body descriptions are optional. Drupal treats all selections and free-text elements as tags and allows administrators to block offensive words.
Since ePods is intended for use by teachers and students in K-12 education, “Teacher” and “Student” accounts were created and submissions were not made with complete consistency to experiment with a more realistic taxonomy than one that a traditional cataloger would create. Just how the free-text terms would function in a large real-world situation is not something I could exactly emulate because I can’t necessarily disable my own librarian sensibilities when submitting content. However, the implementation of required elements, some by selection only, are converted to tags by Drupal and fairly easy to complete with Drupal’s suggested text capability.
Though my initial inclination was to create a strict vocabulary, reading Shirky (2005) convinced me that it is impossible to manage and not necessarily desirable to do so over time since the users will end up dictating the vocabulary anyway. So, for the free-text elements, I added instruction and examples in the Help Text field to guide users without limiting them to a list of terms. One potential problem that I encountered and have not resolved is that Drupal treats words with capital letters as separate keywords in the taxonomy even if they are spelled identically. There are modules that allow administrators to force capitalization and/or no capital letters in tags and something like this would have to be installed to avoid massive duplication of terms.
I installed a few additional Drupal modules to enhance the functionality of the submission process, browsing, and free tagging. The TinyMCE WYSIWYG module installed in the original Drupal configuration allows users to add rich text and upload images to complement their multimedia content. To increase the browse-ability of the collection, I installed a module called Tagalicious that creates a tag cloud that can be included in any or all pages for users to select. I set it to display the most popular tags in a larger font. I also installed a Tagalicious-dependent module called Community Tagging so that users can add tags to other’s content. This is a useful module for increasing the visibility of poorly tagged objects, especially since young students would presumably be entering their own content. Both Tagalicious and Community Tagging are dependent on the Taxonomy Browser module. I also installed the Bookmarks module along with the DHTML Menu that displays at the top of the browser window so that users can easily bookmark content.
It’s fairly easy to get lost in the scads of available Drupal modules and hacks. There are a few that weren’t installed but could further enhance the ePod site’s functionality and content. Modules that allow users to repurpose content for the web and create more of a social network within the collection are available, but are more complicated to install and beyond the scope of this project. Also, as mentioned previously, the OAI-PMH module could be added to allow for open harvesting and sharing of data with other educational collections. The Creative Commons widget or some similar copyright module would be a prudent addition for this type of collection since there are bound to be intellectual property disputes over content of this nature.
All users can view all content and re-edit previously posted items in ePods. The familiar “Search this site” box is an obvious entry point and what I would expect most users would rely upon if the tags and minimal navigation are not returning relevant content. It is easy to navigate ePods because the Drupal’s interface follows such ubiquitous web design principles and maintains constant elements such as the logo linked to the homepage and sidebar navigation.
The primary strength of the ePods collection is that it is easy to use. Visitors can view content without logging in and the submission process, for registered users only, is straightforward. Users can browse by tag or by the home page created to navigate students to student-oriented content and teachers to content relative to their needs. More navigation pages could easily be created by creating links to nodes and searches. Overall, though, I believe that ePods has a stable core foundation and could easily be implemented on the Web with minimal involvement of IT professionals. The key is to make it simple and keep it simple.
References
Belgian Federal Government. (2008). Portal Belgian Government. Website. URL http://www.belgium.be/en/
Drupal (2008) Drupal Modules. Webpage. URL http://drupal.org/project/Modules
Hoover Public Library. (2008). The Hoover Public Library. Website. URL http://www.hooverlibrary.org/
Indianapolis Museum of Art.(2008). Indianapolis Museum of Art: Modern, African & Fine Art, Garden. Website. URL http://www.imamuseum.org/
Instructables. (2008). Instructables - Make, How To, and DIY. Website. URL http://www.instructables.com/
Shirky, C. (2005). Ontology is overrated - categories, links, and tags. Webpage. URL http://www.shirky.com/writings/ontology\_overrated.html
Walt Disney Internet Group (2008). ABC Family: Online TV, Video, and Blogs. It's a new kind of family. Website. URL http://abcfamily.go.com/
One of the issues I was disturbed by in cataloging my collection using EPrints was the ability to select more than one Subject Heading per record. On the surface, this seems really great because it's inherently flexible. However, since every cataloger is different (especially self-archivers), I see the potential for major disaster when browsing by subject in this type of environment. Compounding this problem, at least in my collection, is the inability to exploit full-text searching in multimedia collections. Unless each video/audio file is transcribed, the metadata needs to be extremely descriptive.While the Subject Headings are useful in a general sense, they tend to be quite broad and would only begin to filter results within a very large collection. On the other hand, tags have the capability to be SO specific that they might weed out too much in a browsing environment. The potential for inconsistency in self-archiving is so great, but I found that Drupal's tools for creating a more guided entry process with customizable non/required selection and entry fields could eliminate at least some of these problems. I keep straddling the fence between micromanagement of these elements and Shirky's points regarding the irrelevance of such efforts.I have been approaching cataloging and metadata creation inconsistently on purpose. Though I try to retain some amount of uniformity in each of the records, I have also chosen to add some keywords/tags to records and omit them in others to really see how this affects the user experience in both browsing and searching. This behavior has produce rather predictable results - even I can't remember which tags are linked with certain objects and I have to do some digging to get back to the object/s I was looking for.On the other hand, I review user queries and results on a daily basis at work where we strive to create catalog records that are consistent as possible without any user input. Day after day I see skewed results and irrelevant returns resulting from pretty simple searches in a highly-controlled vocabulary due to idiomatic expression variations, plural terms, compound keywords, etc. So, I guess I still have hope for a system that uses both controlled vocabulary and free-tagging.
Drupal is complex and I can tell we've just barely scratched the surface in the last few assignments. Regarding its suitability as a repository for my proposed ePods collection, I think it's still a bit early to really assess. On the other hand, for my skill level and on behalf of the other tech-savvy-but-not-IT-professional librarians out there, I think Drupal could be a sustainable solution for individual or repositories of collections because it can be easy to use.And yet, the management assignments have sufficiently piqued both my curiosity about the differences and flaws of other content management options while raising doubts about any single, perfect solution that can meet the needs of a large institution - Drupal included. It becomes more dicey when you start taking advantage of it's modularity. Also if my collection were to be hosted by, say, a university library that may or may not be a member of the Drupal fan club, would it be easy to integrate with and among other collections? If it had to conform to a style sheet, would Drupal's intuitiveness persist? Until I can answer these questions, I don't feel comfortable with a definitive thumbs-up for ePods in Drupal.
I have to say, I'm feeling pretty good about the tech assignments - so far. I took the first DigIn course over a year ago and I'm surprised at how much I remember. It helps that my current job requires me to use a lot of what we learned in the Applied Technology course. The assignments are nicely laid out, step-by-step, and, even when I've created problems for myself with typos and/or misunderstandings, there's enough time to go back and repeat the steps until I get it right. The repetition of correcting mistakes has been informative and enlightening.I much prefer VMWare to the initial 'lab machine' set-up because I don't have to switch back and forth between physical machines. It was a real challenge to read instructions and follow them on two different screens. I also like that you can create multiple virtual machines within VMWare and save snapshots throughout the process.It seems that we are finally getting to the real 'meat' of DigIn in this course, which is a relief because I had some anxiety about picking up where I left off last winter with the nitty-gritty technology assignments. The management portion also ties in nicely because we're actually getting to explore some of the content management systems that we've been reading about from the beginning.
Content Management Systems (CMS) were explored in a 2006 issue of Library Hi Tech, starting with their basic definition, moving on to technical explanations, and a showcase of relevant case-studies. In Beach and Dial's "Building a collection development CMS on a shoe-string," the authors describe the plight of the small academic library where funds are limited and the redundancy of efforts does little to provide integrated access to library materials for distance learners. The Texas A&M University-Kingsville's (TAMUK) Jernigan Library Technical Services Department was not making a smooth transition to the request and delivery of materials via the online interface. Instructors reported that they were "teaching down" to make use of the few resources the library could provide and students reported their frustrations regarding the limitations of an antiquated online delivery system in the age of distance learning and course management software. Additionally, the library had no transparent way for tracking order requests and it was clear that something needed to change.
Beach and Dial worked with library staff to create a CMS for collection development that would make use of user-contributed/initiated cataloging that took the burden off of the cataloging department. Records were processed as they were ordered by instructors. Rather than library staff taking the time to select titles that they felt the university should have in the collection, they were able to include instructors and create bibliographic data simultaneously. Catalogers have ultimate authority control over the quality of the records, but their work is certainly simplified by this process. When the book arrives, the record already exists. Prior to the CMS's implementation, library catalogers and staff were repeatedly re-entering the same data regarding bibliographic records from scratch throughout the collection development process. "The concept of entering bibliographic data one time only" seems so logical and yet such an essential breakthrough here. There was initial resistance to abandoning the card cataloging ways of the library faculty and staff even in 2004 - yes, I said resistance - but it was apparently a huge hurdle in retraining the staff to make use of the electronic records.
The most important shift in the TAMUK Library's outreach strategy was to treat all Library Website users as distance learners. This allowed them transition from the traditional 'library as a place' mindset and to developing resources that made sense in an integrated Web environment. CMSs make this much more simple for small, less technologically-rich academic libraries because Website creators are freed up to focus on content rather than architecture. Another important facet of the user-created data was that it identified both the instructor and the instructor's department in the request. Though the authors didn't go in to much detail about this other than focusing on inventory-control, it seems that this type of local metadata could be very valuable to building online sub-collections and integrating with Course Management Software resources.
The results of the TAMUK case-study were not conclusive when this article was published, though it did appear to have some positive impact on the library's collection development workflow even early on in the CMS implementation. I went to the TAMUK Jernigan Library website (http://lib.tamuk.edu/) and was disappointed to find that it was not even close to being part of a CMS. In fact, the access services page actually uses their IP address as its URL (http://139.94.160.6/access/access.htm). So, while collection development is important to library users, I'm not so sure that the students and faculy can really take this site seriously when seeking resources - which I think was the intended direction initiated by Beach and Dial.
References
Beach, R. & Dial, M. (2006). Building a collection development CMS on a shoe-string. Library Hi Tech, 24(1) [Electronic Resource]. Retrieved September 13th, 2008, from http://www.emeraldinsight.com.ezproxy2.library.arizona.edu/Insight/ViewContentServlet?Filename=Published/EmeraldFullTextArticle/Articles/2380240109.html
Texas A&M University-Kingsville's James C. Jernigan Library Website (2008). Retrieved September 13th, 2008, from http://lib.tamuk.edu/
I plan to develop a collection of educational podcasts as a continuation of my proposal from Digital Collections. As podcasts tend to be ephemeral in nature and parts of series, I will cull a group of podcast series intended for general educational purposes and suitable for both educators and students to use indefinitely. As the content in each podcast or series will vary, it is important to begin developing a basic taxonomy from which users will be able to add meaningful metadata through tagging, enabling a user-created, faceted classification system. To limit the scope of the collection, I will collect only technology-related podcasts that serve as lessons and/or the products of specific lessons. The content, intended audience, and academic levels will be limited to K-12 educators and students. There will be no limitations on the creators of podcasts and series. Narrowing the scope of the content will allow me to focus on the development of a specific sub-section of the broader taxonomy to find out how multiple layers of tagging work on a small scale. Originally, I felt that it was important to exercise authority control over user-created data, but time, experience, and the words of Clay Shirky have convinced me that micromanaging faceted classification is often redundant and irrelevant over time. The model for my Digital Collections project ( ePods ) was Instructables.com because it utilizes efficient content management and user-participation in classifying entries through tagging. Though I will be acting as both the "creator" and "user" of the collection, I plan to vary the way I create metadata in those roles. As the collection's creator, I will add basic terms like "podcast," "education," and "technology" to all of the items in the collection. As a user, I will add more specific terms on an item level that vary in consistency. I'm anxious to see how the metadata behaves in a content management system and how it will be impacted by user-created components.
ePods is a collection of eighteen podcasts, both audio and video, intended for educational purposes in K-12 classrooms with content suitable for both teachers and students. I chose to collect individual podcasts as well as podcast series that focus on science and technology content to limit the scope of the taxonomy. This allowed me to think about developing a controlled vocabulary specific to the content and observe it in practice while adhering to the application profile I developed based on Dublin Core elements. 
Drupal’s interface is accessible to all levels of users and can be as simple as a single webpage or as complex as a repository of repositories. Once the basic settings have been configured, Drupal can be a blog, a repository, a social networking site, an e-commerce site, an organization’s main website, a wiki, or all of those things. So, for example, if ePods begins as a repository, Drupal’s modular architecture is flexible enough to build off of this basic structure to create a multi-faceted site beyond what other systems like ePrints and DSpace can provide. 
Since ePods is intended for use by teachers and students in K-12 education, “Teacher” and “Student” accounts were created and submissions were not made with complete consistency to experiment with a more realistic taxonomy than one that a traditional cataloger would create. Just how the free-text terms would function in a large real-world situation is not something I could exactly emulate because I can’t necessarily disable my own librarian sensibilities when submitting content. However, the implementation of required elements, some by selection only, are converted to tags by Drupal and fairly easy to complete with Drupal’s suggested text capability. 
I installed a few additional Drupal modules to enhance the functionality of the submission process, browsing, and free tagging. The TinyMCE WYSIWYG module installed in the original Drupal configuration allows users to add rich text and upload images to complement their multimedia content. To increase the browse-ability of the collection, I installed a module called Tagalicious that creates a tag cloud that can be included in any or all pages for users to select. I set it to display the most popular tags in a larger font. I also installed a Tagalicious-dependent module called Community Tagging so that users can add tags to other’s content. This is a useful module for increasing the visibility of poorly tagged objects, especially since young students would presumably be entering their own content. Both Tagalicious and Community Tagging are dependent on the Taxonomy Browser module. I also installed the Bookmarks module along with the DHTML Menu that displays at the top of the browser window so that users can easily bookmark content.
All users can view all content and re-edit previously posted items in ePods. The familiar “Search this site” box is an obvious entry point and what I would expect most users would rely upon if the tags and minimal navigation are not returning relevant content. It is easy to navigate ePods because the Drupal’s interface follows such ubiquitous web design principles and maintains constant elements such as the logo linked to the homepage and sidebar navigation. 
