Holy Heroes!

So one of our first tasks in our Advanced Digital Collections course is to collect 15-20 digital items that we'll eventually use when we build our little mini online museums/archives. (I think.) I actually had a bit of trouble deciding what to collect. I'm sure I made it more difficult than it really is, of course. As it always does, my mind eventually drifted back to-- what else?-- Star Wars, and I hit upon my theme-- heroes.

Since the day I discovered Joseph Campbell and his ideas of the hero archetype, I've been fascinated by the type of stories that, for whatever reason, belong to the human experience whatever the culture.

So, my collection idea started from there and branched out to include a pretty broad definition of heroes-- real-life heroes, ancient heroes, superheroes, and movie heroes. Songs about heroes, radio stories of heroes, pictures of heroes, videos about heroes, and stories of heroes. I even included a satire of heroes.

Here's a list of the items in my collection:

1. Martin Luther King's "I Have a Dream" speech (video)
2. Editorial about sports heroes (audio)
3. Interview with "Sully" Sullenberger (radio)
4. Superman picture (image)
5. Luke Skywalker picture a la Obama "Hope" design (image)
6. Luke Skywalker picture w/ lightsaber, black background (image)
7. Luke Skywalker picture in flight suit w/lightsaber, fire background (image)
8. George Lucas discussing Joseph Campbell (video)
9. "Have Gun Will Travel" song (audio)
10. "Superfriends" (1973) opening credits (video)
11. "Superfriends" do "Office Space" (video)
12. "The Odyssey" (pdf)
13. "Clash of the Titans" movie trailer (video)
14. "Holding out for a Hero" song (audio)
15. "What is a Hero?" CBS news segment (video)
16. Subway Hero CBS news segment (video)
17. Herakles killing the Nemean Lion vase (image)
18. Hercules comic book segment (pdf)
19. "Profiles in Courage" excerpts (pdf)
20. "The Woman Who Dared" editorial cartoon of Susan B. Anthony (image)

There could be many ways to access my collection. I might use "real" and "imaginary" as descriptors. "Ancient" and "modern" could also work. Describing by format image, sound, video, document, etc. might be useful. Keywords such as "lucas," "georgelucas," "george_lucas," "star," "wars," "starwars," star_wars," "skywalker," "lukeskywalker," "luke_skywalker," etc. can get out of hand right away. I think I'd like to enable user tagging to make keyword more efficient.

As to who might access this collection, I would think teachers, schoolchildren, and anybody with an interest in heroes. It's a broad enough subject that it should appeal to many people. It's not, however, the place to do serious research.

forewarned, forearmed

This week, in reading about project management, I was amazed at the advice Make sure to have a plan. Or, more to the point, I was amazed that there was a need to give such advice. Who would attempt a project in which other people were counting on you, and not develop some sort of a plan first?

Apparently people do. Crazy people.

I was really fascinated by some of the software out there to help keep projects on time, on budget, and on track. I wish I had one of those for everyday use. I already pretty much do mental Work Breakdowns, but completely underestimate the time needed to complete the tasks.

How long will it take me to finish my homework today?

About two hours.

Wrong! PERT says twelve hours. You forgot to factor in eating, sleeping, laundry, and staring off into space at random intervals.

I think this kind of software would be invaluable to a project manager who is in charge of a lot more than just herself and her homework!

So that's what the PM wants to accomplish. The other piece of good advice from the readings this week was preparing for possible risks. I loved the idea of the "cube" in Cervone's readings, where risks can be plotted and assessed as to risk, probability, and effect. This also seems like a sensible way to prepare for possible obstacles and avoid pitfalls.

Even though there are many types of program plans, each with their own processes and sub-processes, it's worth toting around a tabbed binder with project plan details to get the project where it needs to be.

learning curve

Learning anything new is a little exciting, a little tense, and a little frustrating. I definitely felt all three as I plodded through the units-- I say plodded, because the unit learning and exercises were fine and precise, and sometimes I felt as though I was extremely clumsy, like trying to knit with mittens on. Nevertheless, I have emerged from the course knowing a lot more than I did before about what goes on underneath the user interface of a digital collection.

Even using the word underneath with more confidence is a boon-- the layers of applications, protocols, scripts, and compilers makes more sense to me. At the very least, I should be able to talk to an IT person and have a semi-intelligible conversation!

As a former schoolteacher, I pretty much involuntarily use metacognition when I'm learning something new. I can't help but take a step back and analyze how I am learning something, and where I am in the learning process. I noticed that with almost every unit, I compared my learning-- not the content, but the learning process-- to when I learned HTML. HTML is the most recent computer language I've learned (and really only one of two, the other being BASIC, a language I was somewhat traumatized by in the 9th grade).

At any rate, when I learned HTML, through a combination of self-teaching and later through a Pima class, I got to the point where the syntax and vocabulary became second nature to me. Learning CSS (I kind of threw CSS in there with HTML as one of my two computer languages) was a little easier, having had experience with HTML. I'm no expert in HTML or CSS, but I consider myself competent. I could experiment a bit, using my understanding of the syntax and vocabulary. Sometimes it worked, sometimes it didn't, but I was comfortable enough to try.

Another part of my HTML/CSS learning is that when I was finished, and I loaded the page, and something was wrong, I was confident enough to understand that I had the basic principles correct in my coding, but I probably had a typo somewhere. (With CSS I allowed that I may have made a mistake, but not a gross error.)

With the information and skills we've studied in this course, I'm definitely still a novice. I haven't acquired the familiarity with the concepts to be able to experiment much, or know that my errors are probably just typos and not a misunderstanding of the material.

But, novice is on route to competence, which is what we're aiming for (if I wanted to be an expert, I'd be in a computer programming school!). And I feel as though I'm ready to tackle the similar/brand new challenges of the advanced course. Because I know that the more I work with it, just as the more I worked with HTML and CSS, the less foreign and the more familiar the concepts will be.

son of SQL

Who knew that I prefer the world in 2-D? Relational databases are a labyrinth I can't seem to navigate my way out of. It's not that I don't know whether to turn right or left. I don't know if I'm upside down, which exit I'm supposed to be heading for, and I forgot how I got into the maze in the first place!

I think part of it is because I'm new to it. If I spent some time with it, I'd probably feel more comfortable with it. But, SQL (and relational databases) are in many ways non-verbal-- which is my strength. And my weakness is spatial orientation. I can remember, quite vividly, driving back from California on a Sunday night, sitting in the passenger seat, insisting to my friend that we were driving parallel to I-10. It was Phoenix, it was one o'clock in the morning, and no one was out except us. I was almost frantic; I wanted to get home so badly and I was so sure that we were never going to make it back to the freeway because we were running parallel to it.

And then we got to the on ramp. I felt internally disoriented now. Like a slap in the face, I was reminded once again that spatial orientation-- not my strong suit.

This is what relational databases look like to me:

Only maybe insert a few more going in at different directions.

So using MySQL under these conditions is just a wee bit difficult. Mostafa says, we can be precise with our MySQL queries. Sure, if you know what the heck you're doing!

The written examples in our Assignment packet helped me tremendously, especially because I chose to use the database provided, and I could use the examples as a template. I'm verbal: I saw the words, could see the pattern in the words, and could eke out a few queries that way. And there's nothing like seeing the query results table come scrolling up the screen instead of, "Error. You are a dummy and I can't understand what you are trying to tell me."

So, yay for the scrolling results, a small feeling of victory, and one step closer to wrapping my mind around MySQL.

bridge to nowhere

So this week I was pretty psyched about the readings and the exercises because the types of commands that are in MySQL make sense to me (pretty much). I think MySQL might work how my own brain works. I kept thinking, Maybe you should have been a programmer, or a database engineer or something. You've got this!

And then I tried to create my own, extraordinarily simple database proposal regarding three images. Three. And I cannot tell you how frustrated I got! It's not too often that I feel that inadequate. I kept drawing tables and writing in entities, then decided that they were attributes, then decided, no, they're values. My head was spinning in circles about what, exactly, to do with the attributes. Do they get their own tables? Doesn't that make them entities? And all the foreign keys, when should they come into the picture? Arrrrrrrgh!

On top of that, my "simple" database just got more complicated when I realized that I ended up with a many-to-many relationship between two tables-- one art piece was created by two people, because one died partway through painting it. I knew I had to make a bridge table to connect the piece table and the creator table, which I thought I did... but since it wasn't recognized as a bridge, I think I need to revisit that concept a bit. Stupid artist, why did you have to die right then? Now you've ruined my life.

Oh, well, he couldn't help it, I guess. I think what's in store for me is re-reading and /or re-watching some of the stuff on database modeling, to build a better bridge.

the other twenty percent

Of all the reasons non-profits such as schools, libraries, archives, and museums to use a technology plan, one stands out to me above all the rest: narrowing the digital divide. The changing nature of technology means that when one area of the divide is narrowed (say, mobile phones), another widens (currently, high speed Internet access). As gaps slim, but don't meet completely, some people are satisfied that the digital divide is closing, citing statistics such as over half of Americans now have Internet access at home. First of all, as if over half is an acceptable amount, and second of all, as if it were that simple.

This is where the 80% rule usually comes in to play. Some people convince themselves that if most people benefit from technology, that's the best we can do. Many people in all walks of life do strive to satisfy 80% of their constituency. And that's a good start. But, as John Carlo Bertot says,

It is one thing to design programs that work for most; it is another task to go back and ensure that the intended benefits of a program have reached those who are most in need, often despite the system's design, regulations and procedures.

The other 20%, or those whose needs are not met by the initial design of the technology plan of a non-profit, are just as important as the majority of the constituency.

I'm pleased that Arizona's five year LSTA plan does acknowledge that libraries are one place to balance the inequity of the digital divide. Some of its programs, such as instruction that introduces its constituents to computers and the Internet, address the imbalance. Arizona's technology plan, while comprehensive, isn't very specific. In some ways, this benefits the description of the programs, which can be modified to fit the needs of the users of particular libraries.The questions are, of course, in what manner will these programs be implemented? Will the Needs Assessments done by the libraries really define what the constituency needs? Will the 20% avail themselves of the programs? How will local politics affect the effectiveness of the programs?

Where ever I am fortunate enough to find employment after I finish my graduate work, I hope to be able to narrow the digital divide as much as possible. Outreach has to be a major part of that work. The knowledge and skills I'm learning and fine-tuning in both SIRLS and the DigIn program will arm me with the know-how to at least be a part of that conversation.

I'm lucky to belong to the 80%. It's time to take luck out of the equation.

We last left our intrepid heroine on the brink of disaster, lost in Linux's Labyrinth, a sinister lair riddled with rabid daemons, ports to nowhere, and sockets with jaws of steel. In search of her companion, Apache Web Server, our plucky heroine must battle the evil forces that threaten sudo shutdown at every turn...





If our heroine had directions, written in HTML, to help her navigate the treacherous labyrinth, it might look like this -->

She wouldn't make it past port 22 with that bit of unhelpful information. Our heroine would have to make her best guess as to which port is that port, where is there and what thing is that thing. The HTML jacks up her adrenaline with all the bold and the italics and the large font, but that's about it.



Our heroine would do much better with directions written in XML, because metadata is included within the document itself. Should she want to know which port to avoid, well, it's

Luckily for her, our heroine had previously taken two courses which helped prepare her to understand XML: Organization of Information followed by Cataloging. Her cataloging instructor spent a couple weeks exposing the class to XML and working with it a bit. She was able to reread those sections in Lois Chan's Cataloging and Classification in order to remind herself what she had previously learned.

This is not to say our heroine remembered everything from the cataloging course. As a visual learner, and one who usually learns better through a person than an inanimate object such as text, she used Mark Long's lecture series in UA CBT almost exclusively. Mark Long's lecture is pretty good, because he explains what he's talking about as opposed to merely reading the slides.

As an adventurer, and one who is fond of derring-do, our heroine attempted to learn more about XSLT through w3schools. After perusing through that, and HTTP Request, and XPath, our heroine determined that the best use of her time was to prepare for her work with Apache Server. (Never fear! Our heroine has not been defeated by XSLT, much like the Swamp Fox of the American Revolution, she's run away to fight again!)

And so, our heroine reviewed the basics of what she had learned last semester, and solidified her understanding of what XML can be used for, and dabbled a bit in more advanced XML-- mostly via video, with a dash of w3schools thrown in. 

She felt confident in her basic understanding of XML, ready to tackle the dangers of Linux's Labryinth! Stay tuned for the thrilling conclusion to our story: "XML Marks the Node;" or "XARGS: Revenge of the Gnomes."