Queries

As predicted by Professor Fulton, my main struggle this week was constructing queries using JOIN. Ultimately, I was able to syntactically create queries that worked, but honestly I am not sure that I really understand the difference between a left join and a right join and when you would use which. Maybe it will make more sense to me over time with practice. I am thrilled to be learning how to get behind the scenes with MySQL and think this may be one of the most useful aspects of the course for me. It directly relates to my work with the Archivists' Toolkit and potentially other projects as well. The rest of the MySQL training was easy and I had no trouble picking up the syntax. Like I said, I can construct correct queries (well maybe after one error return!), but I don't really understand what difference the left and right join are making conceptually in the data that is returned. It could just be that it wasn't really relevant to the data we inputted because none of our tables or rows had null values. Perhaps that would make the difference more evident, or maybe I am still way off?

Data Modeling and Database Design

I really enjoyed this week's topic. I learned alot about what goes into planning and designing a database beyond just specifying what you want a software application to do. I am still struggling with the entity-relationship diagrams, but it made more sense after I had to think through it for my own database. I think it is actually the different diagramming conventions that are tripping me up more than the concepts behind it. I really liked the "Data Modeling: Finding the Perfect Fit" article. It was much clearer and easier to grasp than the wikipedia articles. I am still not clear on the differences between conceptual, logical, physical, and semantic models and all these different diagrams with their multiple arrows pointing all over do not help! Database normalization, however, I totally connected with. Oh my, could I totally geek out over normalizing database structure. It is all so neat and organized, and I love the concept of atomicity getting everything broken down into its most individual parts. I think I could get too carried away with this and end up living in a closet like that guy in Real Genius...

Technology Plans

I found most of the readings for this week very interesting. There were a few that I found somewhat outdated and too public library focused to be of much use to me, such as the Bertot article "Study Shows New funding Sources Crucial to Technology Services." The Dugan article "Information Technology Plans" offered a good breakdown of the components of a solid technology plan and the Gerding and Mackellar article "Applying for Technology Grants" pointed to multiple good resources for technology planning and grant funding. There were several readings, however, that I found particularly relevant to my work and interests. I like the Stephens article "Technoplans versus Technolust" for its emphasis on tying a plan to the organization mission, acknowledgement of the need for flexibility, and explanation of Everett Roger's Innovation Adoption Curve. I could so easily categorize my colleagues into his 5 categories: Innovators, Early Adopters, Early Majority, Late Majority, and (my favorite) Laggards. Sager's article "Environmental Scanning and the Public Library" was also especially valuable despite its public library focus. The kind of deliberate awareness of one's environment that he describes and how critical it is to developing strategic goals for your organization translate across the information professional community. The article that hit closest to home in a too familiar way was Whittaker's "What Went Wrong? Unsuccessful Information Technology Projects." As I am currently working on a software development project that has already considerably gone over budget and off schedule, I wish I had read her article before starting the project. We have encountered several of the pitfalls she describes, including poor project planning, lack of monitoring, unrealistic time and cost estimates from vendors, and vendors overextending themselves and not meeting deadlines.

As Lead Archivist of a Digital Program, I am intricately involved in technology planning at my institution. I have to advise on archival requirements for storage, software choices, software development projects, staff training on new software, etc. As the program grows and the archive moves more towards digital archiving, I only see the Digital Program and my role in technology planning growing. It is already at the core of every program, including reference, processing and description, and even donor relations. Moreover, the IT staff, while very knowledgeable about the technology involved, do not understand the special needs of an archive and need that perspective to be incorporated into their planning.

XML

I reviewed the UACBT tutorials. Having been working with EAD to encode archival finding aids and also working with multiple metadata standards for describing digital objects for over 8 years, this portion of the course was already extremely familiar to me and I had no trouble following along with the tutorials or doing the homework assignment.