This year the ALCTS Forum at ALA Midwinter brought together three perspectives on massaging bibliographic data of various sorts in ways that use MARC, but where MARC is not the end goal. What do you get when you swirl MARC, ONIX, and various other formats of metadata in a big pot? Three projects: ONIX Enrichment at OCLC, the Open Library Project, and Google Book Search metadata.
Jay Jordan’s remarks during the OCLC Update Breakfast and the discussion at the Developers Network table at that breakfast generated further fuel for my previous philosophical thoughts on “Who is a member of the OCLC Cooperative?” In the context of things like Developer Network API keys1 this question of who is a member of OCLC the cooperative and who is not meets the on-or-off, ones-and-zeros nature of computers. One can’t “kinda” have an API Key unless that capability is programmed into the software (or a human chooses to override the established rules for who has a key).
I think it is a statistical anomaly that many of the meetings I attended during ALA Midwinter were somehow related to OCLC. That statistical anomaly has certainly played out in postings here on DLTJ of my impressions of Midwinter meetings. Continuing with this thread of OCLC events, I attended the OCLC Update Breakfast Sunday morning for a membership-dues-paid croissant and orange juice, and to listen to Jay Jordon’s biannual update on the past, present and future of OCLC. What follows are highlights that I found interesting in the course of his remarks, but certainly not a comprehensive report of what was said. Video of Jay’s remarks where recorded and are to be posted at some point on the OCLC website (roughly six to eight weeks from now, if my memory of past events can be any guide).
On Saturday morning of ALA Midwinter 2010, Dr. Jennifer Younger moderated a session on the progress of the OCLC Record Use Policy Council. The meeting started with an introduction to the reasons behind the creation of the Record Use Council, the charge of the Council from the board of trustees, and how the framing of the discussion of the policy is guided by the values and history of OCLC the cooperative. There wasn’t much new here for those that have been following the progress of the policy discussion, so I am skipping over it most of it with the exception of a few notable topics. After that, I’m focusing on the lengthy question and answer session that followed Dr. Younger’s background presentation.
This morning I was at the OCLC Americas Regional Council Meeting just prior to the opening of the meeting. In addition to the prepared talks and remarks, there was a series of breakout sessions the end of the meeting. Ever sense the record use policy kerfuffle got started, I’ve been thinking more about the governenace aspects of OCLC as cooperative, so I attended the session on “The Cooperative’s Shared Values and Social Contract.” It was a very interesting discussion, and for several hours after my mind was spinning with implications of the heartfelt ideas contributed by those at the meeting. In the end, I’m stuck with this line of thinking, starting with a statement then a series of questions:
Most e-mail messages I send are digitally signed using a process called “Pretty Good Privacy“, or PGP. In e-mail applications that don’t understand PGP, this digital signature will show up either as an attachment called “PGP.sig” or as a part of the message starting with “BEGIN PGP SIGNATURE” at the bottom of the e-mail. This file — containing gibberish to the human eye — is used by PGP-aware programs to verify that the message actually came from me. If you are using PGP, I could also sent you a message that only you could read (e.g. “encrypted”). This page gives some background on PGP and why I consider it important.
It is the start of a new year1, and it seems like a good time to update my public encryption key. My previous one — created in 2004 — is both a little weaker, cryptographically speaking, than the ones newly created (1024-bit versus 2048-bit) and also an uncomfortable mixing of my professional and personal lives. For my previous key, I attached all of my professional and personal user ids (e.g. e-mail addresses) to the same key. This time I decided to split my work-related user ids from my other ones. My reasoning for the split is that I might be compelled by my employer to turn over my private key to decrypt messages and files sent in the course of my work. If my personal user ids are also attached to that private key, my employer (and who ever else got ahold of that key), would be able to decrypt my personal messages and files as well. That is not necessarily a good thing. So my solution was to create two keys and cross-sign them. I’ve outlined the process below.
These keys are part of a computer standard and software algorithm called “Pretty Good Privacy“, or PGP. If you are interested in more of a background about PGP, see a companion post on why I digitally sign my e-mail.
- Some have even said it is the start of a new decade, but of course that isn’t true. We won’t start a new decade until 2011, just like we didn’t actually start a new millennium until 2001. [↩]