Week 10 - maybe a little whiny

While working on the database sections, I was reminded of a special project I was part of about two years back at my public library. The cataloging department had a massive backlog of items from the transition to outsourcing for the cataloging and processing incoming items. It was not a smooth transition and for almost a year there were problems with a sizable percentage of incoming items. Most of these were failed MARC records that due to one problem or another, weren’t working in the Millinium system. I was hired for about ten months to find, update or replace the record as appropriate. If you ever really want to learn cataloging rules, look at several hundred bibliographic records every day and try to find what is wrong with them. Why I mention this is that we needed to spend the least amount of time on each record as we possibly could while still allowing the public to use them and allow us to track carefully for reimbursement. For our internal needs, we wanted to be able to track every last one of them and each failed record had to include several data points that could be used for various retrieval queries; date, format, error type(s) , record id #1 and failed record id #2. By looking at what was wanted at the end, we worked out the minimum of what we needed to do to each record. It generally worked but it was never more than adequate and I have never really understood why.

Having no experience with MySQL at the time I am finding it interesting to see the parts that we did that matched up with the logic behind MySQL and to contrast that with the areas where we didn’t match. By focusing too much on the most immediate need for the changed records – which was to prove we should get money returned, we didn’t do a very good job of organizing the failed records into other useful tables that could have helped us later on. Getting the concepts behind MySQL and it’s query levels has given me some ideas as to where the problems might have been.

I used Wikipedia as a MySQL database example in this week's discussion post and do not feel I did a very good job on the assignment. The words are just out of reach. I read too fast on a subject I am not easily understanding and I will have to slow down and think this through again when I can devote a real block of time to it. Databases feel like the section that will never end.

Week 8 - again

It is an interesting question as to how my involvement with future technology planning will be changed by my involvement with the Digin program. Since one of my goals for joining the Digin program is to re-position myself professional and possibly move out of the public library sector. So my previous experiences may have little to no bearing on my future. What can be stated with certainty is that Digin has taught me a great deal about the current state of the profession and its most pressing needs as well as a better understanding of the nuts and bolts necessary behind the scenes. Both of those facts can't help but color my future in terms of interest in technology management and planning.

Week 9 - it was hard!

With the ERD diagramming project this week I kept getting caught up in the differences between a one to many versus the zero to many relationship between entities (I am also praying there is a difference between these and a many to many relationship ). I thought I had a fair idea after my initial read through but when actually diagramming kept getting hopelessly confused. Every time I tried to begin again I worked out a different diagram. Eventually, and I know this sounds obvious but it really did take me some time, I realized I needed to define some relationships myself. Some of the relationships were pre-determined by their nature but several could be open to interpretation. Which is why it is called a planning process. I can see how other people would come to different conclusions and that these differences might make for significant differences in end-user results. My final ERD diagram tries to make my decisions clear and I either did it or I have mucked the whole thing up. Returning to the readings while I was working all this out actually did not help me much. The Mostafa tutorial on tables ultimately was the basis of my Eureka moment. I am curious if others found that there seemed less uniformity in the Crow's Feet notation than I was comfortable with. For example I couldn't tell if the flat or dotted line between entities (shown in the Perfect Fit article) was universally applied as I did not see it in other readings or examples I found on the web. I think experimenting with different types of information and uses, looking over examples and a great deal of experience are required to reach any competency in this field and has given me new respect for database designers.

two kinds of tech plans

As I was digesting the readings for the week it occurred to me that it might make the most sense to have a kind of two-faced technology plan, meaning embedding a useful one into a generic plan so as to meet all the necessary goals. On the one hand, a technology plan can be a useful guide for laying out an organization’s goals and technology philosophy as well as a way to inspire and invest staff, stakeholders and the public. On the other hand a technology plan needs to inspire and involve the very disparate groups of staff, stakeholders and the public and making all three happy can be a tricky business. As Michael Schuyler writes, most people don’t know nor care to know the intricacies of how technology is managed; they just want it to work when they turn it on. So for them you give a generic technology plan that satisfies on the surface level. But for the purpose of actually knowing what to do, who should do it and how to pay for it for people who really do need and want to know a realistic technology plan is a necessity. One that involves elements I do believe are important to the health and vitality of a library like the concepts behind environmental scanning. Some kind of double speak might emerge where behind the generic topics, useful information is coded for those who are truly listening. Also I can’t decide if the idea of peer reviewing technology plans as Schuyler suggests would be a brilliant or if it is like comparing apples with oranges and the potential wide range of differences between libraries make it essentially useless.

How I learned xml and grew to love youtube

One of the learning tools that has come as a surprise to me is youtube. I frankly thought youtube was for ephemera - like a sneezing panda or a kid getting his finger bitten by his baby brother. I did not take it seriously, no spend much time in the youtube playground. It has been a major find for resources in the technologies that support the digital library. The latest case in point is for XML instructions. The tutorial that ultimately was the most useful to me was the Just Enough XML to Survive because it condensed the ideas into its most pure forms and then strung them together, showing the underlying logic. Plus, the voice was great, the presentation was clean and it all was aesthetically well done. I wonder how video teaching is different than classroom teaching and if university professors are able to make the transition. I poked around for 'amateur' tutorials and it was very impressive the number and the quality. The Four Minute series by Zlantorb is a good example of a kind of flash card system for learning and refreshing memory. As I am not a big fan of the 3 schools I was most happy to have found other options and often surprised at their quality. Youtube will not be overlooked as a tool any longer.