Well, here we are. Only two sections left after this. I'm going to take the unit quiz tonight (at the last minute) to see how I've done. This week was a lot of MySQL query "stuff". I'm not sure if the concepts themselves are any more difficult than anything else we've learned and would say that last week's data modeling section was far more tricky but those lessons were crucial to understanding how SQL language works in a practical sense and why we build tables the way we do.
We were introduced to a new way of interacting with MySQL via phpMyAdmin and I found the tool quite useful and intuitive. It even shows you the code you created while filling in the tables verifying you inputting the correct info. A co-worker recommended MySQL Administrator but I think for now I'll stick with either Webmin, phpMySQL, or the command line based MySQL Monitor.
The most difficult time I had this week was working with joins and getting the syntax correct. I was particularly challenged when trying to tie three tables together becuase if the phrases were not constructed (as with any query) I would get error message saying things like "collection_id is vague in clause...." Left and Right joins were also tough and didn't seem to produce correct results if I tried to tie more than two tables together. But I gave it a shot. I haven't looked at what is in store for next week but I hope it builds on this week's and last week's lessons, reinforcing what we are learning
Tuesday, July 28, 2009
Tuesday, July 21, 2009
Data Modeling
We're in our 9th unit now and to get a better grasp of what it takes to put together a solid repository we've been going over data models and entity-relationship models. On the service it makes a lot of sense but in practice is quite challenging. When you have to stop and think about how attributes relate to a particular object or entity and how to best break that down for database management you can quickly get frustrated.
The areas I'm going to really need to work at understanding or normalization and Entity Relationship Diagrams. I just need to continue reading and seeing examples of how these are put together. I also need to find some more tutorials on how to decipher the crows foot notation. Unfortunately the wikipedia entry is rather vague with a diagram that doesn't go into too much detail. I'm still not altogether sure what the notations mean and how to use them. I wonder if having a solid background in calculous, physics, or logic would help.
I think another problem with most of the tutorials is they each tend to stick with one example. Seeing how different types of repository data can be modeled would be helpful. For example lets have some basic examples of manuscript, photograph, and other document collections modeled and see what others have already done to model, relate, and normalize their data-streams. I'm sure with a little searching I'll be able to uncover some other examples but it seems that either institutions keep this information close to the chest or they haven't actually done this yet.
The good news is that as I work through these concepts (with a little more time than these past few days) I'll have a much better understanding of what the programers are having to tackle behind the scenes. If I've learned anything out of this, its that a working digital repository is far more complicated than just placing objects on a server and filling in metadata fields. You have to understand how items relate to each other and clear up ambiguity, redundancy, and non-essential information to improve the speed and storage capacity of your database.
Tuesday, July 14, 2009
Technology Plans
This week's class section was entirely about technology planning in libraries and was probably some of the most reading we've had yet. Technology planning has been historically overlooked and mishandled in many organizations.
Coincidentally we've been dealing with this at work for that past several weeks as we've stepped back to reevaluate the purpose and function of our digital repository. We're in the midst of creating documentation about and for our digitization efforts as we try to come to terms with the scope, development and commitment of our projects. We'll be continuing this process for some time and as we are creating "living documents" we'll have to periodically revisit our plans to evaluate its effectiveness and adapt to future situations. I will probably be involved in technology planning throughout my career considering the complexity of digital libraries/repositories software, hardware, and the specialized staff who offer front line services and the management and maintenance of the systems.
This unit could not have come at a better time. I was able to bring our readings in and share them with the rest of our functional requirements group to help guide and also back up many of our decisions. I think I've also indirectly been promoting the SIRLS DigIn program buy showing all the value I'm getting out of the course in only the first section.
Some key points I've taken away from the readings this week include:
A plan must be a living document meeting the the mission of an organization and you must be not only be aware of technophobes but vigilant against technolust to avoid scope creep. (Stephens, Michael. Technoplans vs. Technolust. Library Journal, November 1, 2004).
A technology plan must be flexible. It is an ever changing, political document explaining in simple language to investors (internal and external) that you know what you are doing. It should be generic enough to get the point across without committing to too many specifics that you honestly can't anticipate and most wouldn't understand. The Arizona State Library's 2007-20012 technology plan (pdf) does does a wonderful job of laying out lots of goals and needs without getting bogged down in too much detail that would undoubtedly change drastically in the five year period it covers. (Michael Schuyler's Computers in Libraries article Life is what happens to you when you’re making other plans. Computers in Libraries, April 2000, pp. 54-55)
Staff, training, support, and maintenance have to be taken into consideration when making plans and also applying for grants. Most libraries cannot afford to offer sustainable services through self funding and will need to coordinate with other organizations, particularly state libraries to leverage funds. Libraries must make sure government policy makers understand the importance of funding and the impact of programs like Library Services and Technology Act (LSTA) and E-rate assignments. (Bertot, Carlo et al. Study Shows New Funding Sources Crucial to Technology Services. American Libraries March 2002 v(33)n(2) 2002 pp. 57-59)
I compared the California State Library (pdf) and Arizona State Library plans, since I've have lived in both states and have a vested interest in them. I was impressed with their focus and noticed trends specific to their function and politics. At first, I was a little perplexed that they weren't more "specific" until the readings emphasized the flexibility and generalized nature these plans need in order to be successful.
Coincidentally we've been dealing with this at work for that past several weeks as we've stepped back to reevaluate the purpose and function of our digital repository. We're in the midst of creating documentation about and for our digitization efforts as we try to come to terms with the scope, development and commitment of our projects. We'll be continuing this process for some time and as we are creating "living documents" we'll have to periodically revisit our plans to evaluate its effectiveness and adapt to future situations. I will probably be involved in technology planning throughout my career considering the complexity of digital libraries/repositories software, hardware, and the specialized staff who offer front line services and the management and maintenance of the systems.
This unit could not have come at a better time. I was able to bring our readings in and share them with the rest of our functional requirements group to help guide and also back up many of our decisions. I think I've also indirectly been promoting the SIRLS DigIn program buy showing all the value I'm getting out of the course in only the first section.
Some key points I've taken away from the readings this week include:
A plan must be a living document meeting the the mission of an organization and you must be not only be aware of technophobes but vigilant against technolust to avoid scope creep. (Stephens, Michael. Technoplans vs. Technolust. Library Journal, November 1, 2004).
A technology plan must be flexible. It is an ever changing, political document explaining in simple language to investors (internal and external) that you know what you are doing. It should be generic enough to get the point across without committing to too many specifics that you honestly can't anticipate and most wouldn't understand. The Arizona State Library's 2007-20012 technology plan (pdf) does does a wonderful job of laying out lots of goals and needs without getting bogged down in too much detail that would undoubtedly change drastically in the five year period it covers. (Michael Schuyler's Computers in Libraries article Life is what happens to you when you’re making other plans. Computers in Libraries, April 2000, pp. 54-55)
Staff, training, support, and maintenance have to be taken into consideration when making plans and also applying for grants. Most libraries cannot afford to offer sustainable services through self funding and will need to coordinate with other organizations, particularly state libraries to leverage funds. Libraries must make sure government policy makers understand the importance of funding and the impact of programs like Library Services and Technology Act (LSTA) and E-rate assignments. (Bertot, Carlo et al. Study Shows New Funding Sources Crucial to Technology Services. American Libraries March 2002 v(33)n(2) 2002 pp. 57-59)
I compared the California State Library (pdf) and Arizona State Library plans, since I've have lived in both states and have a vested interest in them. I was impressed with their focus and noticed trends specific to their function and politics. At first, I was a little perplexed that they weren't more "specific" until the readings emphasized the flexibility and generalized nature these plans need in order to be successful.
Although not necessarily a library tech plan I found the Scottsdale Unified School District tech plan (pdf) to follow along with the best practices of the readings. It emphasized needs, mission, budget, and provided several goals with concrete implementation strategies. It also laid out objectives on applying for E-rate annual funding.
Ultimately I've taken from this experience that operating without a plan is like putting your cart in front of the horse. You won't get far and you will loose out on partnerships and funding critical to the survival of your digital initiatives. Most technology projects fail not because they lack expertise or initiative but because they lack solid planning, buy-in of stakeholders, organization, and reasonable scope.
Ultimately I've taken from this experience that operating without a plan is like putting your cart in front of the horse. You won't get far and you will loose out on partnerships and funding critical to the survival of your digital initiatives. Most technology projects fail not because they lack expertise or initiative but because they lack solid planning, buy-in of stakeholders, organization, and reasonable scope.
Tuesday, July 07, 2009
Learning XML Unit 7 Blog assignment!
Learning XML
About four years ago when we started podcasting in the library I had to learn about XML (Extensible Markup Language) to create a functional RSS feed. We were also asked to begin investigating the pros/cons of RSS and RDF as we first started research work in developing our digital library. So XML quickly became a major part of my working life whether I liked it or not.
I initially learned XML by just looking at what other websites, podcasters, and repositories had done and how they were organized. I also went through various web tutorials, W3.org info pages, and even the Apple iTunes help pages on what elements were necessary to make our feeds work. This process was very unconventional and for the most part worked for my needs but was spotty and to be honest confusing.
Unit 7 of our class has been largely focused on the purpose and use of XML. We were instructed to view a series of instructional videos by Mark Long. Those videos, along with our readings, and the course lecture and assignment notes have been invaluable because I not only learned basic XML structure, which I was familiar with, but the basic rules that apply to that structure. I learned that "well formed" XML may not necessarily "Validate" against the rules of the DTD it is associated with. I don't find XML to be quite that confusing anymore but then I haven't even tackled XSLT (Extensible Stylesheet Language Transformations) yet.
The most helpful modules in the videos tutorials were the ones on structure (5 golden rules!), special characters (watch out for those greater than symbols), and most importantly attributes. I'm still not 100% on when to use or not use attributes in XML (I had actually never considered them myself) but it seems as though, most everyone else is still asking that same question.
Practice system update!
So far, so good! I followed the instructions in our Unit 7 assignment and was able to connect to my new "server" remotely, and even though it's a laptop run it in Headless Mode, which for non techies means I didn't use a keyboard or monitor actually attached to the system. In fact, to emulate the sense that the system was indeed headless, I closed it up and stuck it under my desk. Worked like a charm. I have been simultaneously running my VM system as well for added practice and was able to ping both systems and essentially have two separate servers running in my house. Albeit, closed systems. Each system also now has a personal web space for a user, which helped me understand the whole public folders at both the ASU and UofA personal web space accounts.
About four years ago when we started podcasting in the library I had to learn about XML (Extensible Markup Language) to create a functional RSS feed. We were also asked to begin investigating the pros/cons of RSS and RDF as we first started research work in developing our digital library. So XML quickly became a major part of my working life whether I liked it or not.
I initially learned XML by just looking at what other websites, podcasters, and repositories had done and how they were organized. I also went through various web tutorials, W3.org info pages, and even the Apple iTunes help pages on what elements were necessary to make our feeds work. This process was very unconventional and for the most part worked for my needs but was spotty and to be honest confusing.
Unit 7 of our class has been largely focused on the purpose and use of XML. We were instructed to view a series of instructional videos by Mark Long. Those videos, along with our readings, and the course lecture and assignment notes have been invaluable because I not only learned basic XML structure, which I was familiar with, but the basic rules that apply to that structure. I learned that "well formed" XML may not necessarily "Validate" against the rules of the DTD it is associated with. I don't find XML to be quite that confusing anymore but then I haven't even tackled XSLT (Extensible Stylesheet Language Transformations) yet.
The most helpful modules in the videos tutorials were the ones on structure (5 golden rules!), special characters (watch out for those greater than symbols), and most importantly attributes. I'm still not 100% on when to use or not use attributes in XML (I had actually never considered them myself) but it seems as though, most everyone else is still asking that same question.
Practice system update!
So far, so good! I followed the instructions in our Unit 7 assignment and was able to connect to my new "server" remotely, and even though it's a laptop run it in Headless Mode, which for non techies means I didn't use a keyboard or monitor actually attached to the system. In fact, to emulate the sense that the system was indeed headless, I closed it up and stuck it under my desk. Worked like a charm. I have been simultaneously running my VM system as well for added practice and was able to ping both systems and essentially have two separate servers running in my house. Albeit, closed systems. Each system also now has a personal web space for a user, which helped me understand the whole public folders at both the ASU and UofA personal web space accounts.
Subscribe to:
Posts (Atom)
