In recent presentations, I have been suggesting that libraries will need to adopt more archival skills as they manage digital collections and think about provenance, evidential integrity, and context, and that they will also need to adopt more museum perspectives as they think about how their digital collections work as educational resources, and consider exhibitions and interpretive environments.

I doubt that any archivist would disagree with this. Even better, I think this offers a great opportunity to reach out and have those in allied fields really understand how and why we've done things slightly different for so long. I'm glad to see that my new employer has picked up on this holistic approach with platforms like the NYPL Blogs.

1. Content-addressable storage for electronic mail stored immediately upon sending or retrieval
2. Creating explicit retention policies based upon time
3. Compliance with relevant laws and best practices
4. Straightforward discovery for any use, regardless if internal or concerning litigation

Google Message Discovery, as well as other related offerings such as e-mail security, clearly has its origins in Google's acquisition of Postini last year. Postini isn't some startup with dubious or perpetually beta offerings (e.g. Dodgeball or GrandCentral); some of their better known clients include BASF and  Merrill Lynch. At $25 per user per year, the service seems to be an incredible steal.

 
def create_session(api_key, api_secret):
    """Creates as session using FlickrAPI."""
    session = flickrapi.FlickrAPI(api_key, api_secret)
    (token, frob) = session.get_token_part_one(perms='write')
    if not token:
        raw_input("Hit return after authorizing this program with Flickr")
    session.get_token_part_two((token, frob))
    return session
 

That was less painful than the PPD test for tuberculosis. Oh, and uploading?

 
flickr.upload(filename=fn, title=title, description=desc, tags=tags, callback=status)

Using this little code plus a few other tidbits, I created an uploader that parses CSV files of image metadata exported from an Access database. And when done, the results look a little something like this.

This time around, I felt like I got a whole lot more out of attending; I'm not sure if this is due to the changing nature of my job, increased attention, or some other factor, like neckferrets and dongles. The great majority of the talks, be they keynotes, traditional presentations, or even just lightning talks, were excellent. Furthermore, this time around I felt a whole lot more connected to the miasma - so much so, in fact, that I ended up giving two lightning talks (or three, depending on if you consider the one I gave with Gabriel Farrell on kobold_chiefain Fac-Back-OPAC). The most impressive thing overall, though, were lolcats that came out to play:

Thanks to the work of Noel Peden and Dan Scott, the videos should be up soon enough. If you want to see the detritus available through Web 2.0, search for the tag code4libcon2008.

1. We want sovereignty over the profiles, relationships, content and media we create and maintain.
2. We want open formats, protocols and policies for identity discovery, data import, export and sync.
3. We want to protect user rights and privacy.

And, of course, the thing that made me squeal with delight like a pig in mud:

4. DataPortability will not inventing any new standards.

I mean, that's probably the best news that someone like me could get. They have a graphic on their home page that sums it all up perfectly:

Now, naturally they didn't have preservation in mind at first, but as Peter's post notes, it's ripe for that sort of use. This also got me thinking about Dan Chudnov's old brainstorm about blog mirroring using Bittorrent and Atom, too. In particular, note this comment of his:

It's a pretty simple idea: you extend an aggregator system to "archive" entries posted each day into bittorrent files, and then build a secondary system to turn the data distributed over bittorrents back into browseable "blog" mirrors if/when you need to. The best part is that you don't really need any new technology to do it.

I feel like things are coming full circle. I also feel like I could really have fun and find new ways to extend ArchivesBlogs, at least when I finish the other countless little projects that litter my mind. Anybody got some free time they want to contribute?

First, I should mention that zgw.py isn't designed to be a complete implementation of a Z39.50 gateway. There are many areas in which there is much to be desired, and it's probably not as elegant as some would like. However, that wasn't the point of the project. My ultimate goal was to create a simple client that could be used as a starting point from which to develop a complete web application. The query syntax is pretty straight forward, as long as you're using CCL syntax. One can search either from a form, or by issuing a HTTP GET request to a specially formulated URL, e.g.:

• Author: /search/au="schellenberg, theodore"
• Title: /search/ti="describing archives a content standard"
• Keyword with boolean: /search/shakespeare and vietnamese

Although it's not entirely complete, I have tested it against a number of different Z39.50 servers and have been able to retrieve results accordingly. It's a fun toy, if nothing else...

Anyhow, if you'd like to play around with it, I have an active installation available online. Please be gentle and thoughtful in regard to your queries, though. If you'd like to look at the code and see how this has manifested itself, it's available online via Subversion at http://svn.matienzo.org/public/python/zgw/.

Also, I have no excuses for botching up ArchivesBlogs temporarily by mucking about and wiping out some of WordPress's databases that make FeedWordPress, the plugin that grabs content for ArchivesBlogs, do its thing. The recovery was simpler than I thought it would be, but this is probably the largest amount of unplanned downtime we've had. Keep your eyes open, as a replacement for FeedWordpress may itself becoming along sooner or later.