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.

Below is a summary of how these three projects are messin’ with metadata, as told by the Forum panelists. I also recommend reading Eric Hellman’s Google Exposes Book Metadata Privates at ALA Forum for his recollection and views of the same meeting.

ONIX Enrichment at OCLC

Renee Register, Global Product Manager for OCLC Cataloging and Metadata Services, was the first to present on the panel. Her talk looked at a new and evolving product at OCLC on the enhancement of ONIX records with WorldCat records, and vice versa. ¹

As libraries, Renee said “our instincts are collaborative” but “our data and workflow silos encourage redundancy and inhibit interoperability.” Beyond the obvious differences in metadata formats, the workflows of libraries differ dramatically from other metadata providers and consumers. In libraries (with the exception of CIP and brief on-order records) the major work of bibliographic production is performed at the end of the publication cycle and ends with the receipt of the published item. In the publisher supply chain, bibliographic data evolves over time, usually beginning months before publication and continuing to grow for months and years (sales information, etc.) after publication. Renee had a graphic showing the current flow of metadata around the broader bibliographic universe that highlighted the isolation of library activity relative to publisher, wholesaler, and retailer activity.

Diagram of the Process of Enhancing ONIX Records, from OCLC Services for the Publisher Supply Chain Webinar, August 2009

In her experience, Renee said that libraries need ways to enable our metadata to evolve over time and allow for publisher-created metadata to merge effectively with library-created metadata. The bibliographic record needs to be a “living, growing” thing throughout the lifecycle of a title and beyond. In concluding her remarks, she offered several resources to explore for further information: the OCLC/NISO study on Streamlining Book Metadata Workflow, the U.K. Research Information Network report on Creating Catalogues: Bibliographic Records in a Networked World, the Library of Congress Study of the North American MARC Records Marketplace, the Library of Congress CIP/ONIX Pilot Project, and the OCLC Publisher Supply Chain Website.

From MARC to Wiki with Open Library

Karen said right at the start that the Open Library project is different from most of what happens in libraries — it is “someone outside the library world making use of library data” — although the goal is arguably the same as others — “One web page for every book ever published.” As such, the Open Library isn’t a library catalog as librarians think of it in that it is not a representation of a libraries inventory. It has metadata for every book it can know about and a pointer to places where the book can be found, including all of the electronic books in Internet Archive (Open Content Alliance, Google Public Domain, etc.) as well as pointers back to OCLC WorldCat. Karen’s role for the project is that of “Library Data Informant.” The Internet Archive decided that they needed someone who understood library data in order to try to use it. From Karen’s perspective, she is trying to be a resource for project but not give them any guidance on how to implement the service. She is curious to see what the project would do when bibliographic data is viewed from a non-librarian perspective. If they have questions, or if they have assumptions about data that are wrong, then she intervenes.

Karen went on to briefly describe the Open Library system. Open Library doesn’t have records; rather, it has field types and data properties. In this way, it uses semantic web concepts. “Author” is a type, “Author birthdate” is another type, and so forth. There are no set field types, so if the project gets data from source for which a type doesn’t yet exist, it can create a new one. Each type can have data properties such as string, boolean, text, link, etc. Nothing is required and everything is repeatable. Everything — types, properties, and values — gets a URI (a URI is an identifier like a URL, but conceptually a superset of the universe of URLs). Titles, authors, subjects, author birthdates, and so on have URIs. Lastly, the underlying data structures are based on wiki principles: all edits are saved and viewable, anyone can edit any value, anyone can add new types or properties, anyone can develop their own displays, etc.

The data that is now in Open Library came from a variety of sources. They started with a copy of books from the Library of Congress, and continue to receive the weekly updates. They performed a crawl of Amazon’s book data. They have gotten some from publishers, libraries, and individual users. The last is perhaps the most interesting because it is mainly people outside the western world who are otherwise having trouble getting their works recognized.

Problems, Issues, Challenges, and Opportunities with the Data

Names -

“These library forms of names? Honestly no one but us can stand them.” Even something as simple as the form of last-name-comma-first-name is troublesome. No one else uses this form of the name: Amazon, Wikipedia, etc. In processing these, any information between parenthesis has been deleted, birth and death dates move into separate field types.

Titles -

In working with the Open Library developers, this is one place that Karen tried insisting on applying a library practice: knowing the initial article. For us, this is important for sorting books in alphabetical order. The developer response — why do we have to sort in alphabetical order? “Where else but library catalogs to we see things sorted in alphabetical order? Not in Google, not in Amazon, not anywhere. Alphabetical order is not in the mindset anymore.” They also found that the title might include extraneous data. Amazon, for instance, appends the series title in parenthesis to the main title. This is a demonstration of how other communities are not as concerned about strongly typing and separating information into fields. Amazon, of course, has reasons for series information into the main title: it helps sell books.

Product dimensions -

Publishers and distributors need to know characteristics of an item such as height, width, depth, and weight; they, of course, need to put it in a box and ship it. Libraries, concerned about placing the item on the shelf, record just height. Recording pagination is different, too: libraries use odd notations “ill. (some col)” and “xv, 200p.” versus simply “200 pages.”

Birthdates -

Librarians use birthdates to distinguish names; if there is no need to distinguish a name, birth and death dates are not added. Someone looking at this from the outside would ask ‘Why don’t all authors have birth and death dates?’ This can be useful information for viewing the context of an item, not just to distinguish author names. Open Library ran author names against Wikipedia to pick up not only birth and death years, but also the actual dates.

Subject headings -

Open Library using Library of Congress Subject Headings was out of the question. In processing the data, the Open Library developers just broke them apart into segments and used them. But because they were able to do data mining on the subject field types, they did find statistical relationships between the disassembled precoordinated headings and were able to present those to the user.

The View of the Data -

Rather than a traditional library view of long lists of author-title, the Open Library (in its next version coming in February) will have several different views into the mass of data: Authors; Books (what we would call FRBR ‘manifestations’); Works; Subjects; and eventually places, publishers, etc. For example, when searching for an author one would get the author page. On it would be all of the works from the author as well as other biographical information. It looks similar to a WorldCat identities page, except it is the actual user interface built into the system. Similarly, every work will have a page, and at the bottom of it one will see all of the editions of the work. Also, each subject will have a page, and one will see a list of works with that subject as well as authors who write on that subject. As Karen said, “The subject itself becomes an object of interest in the database, not just something that is just tacked on to the bottom of the library record.”

Data mining -

With the data in this format, it is possible to perform data mining actions against it. For instance, simple data mining such as country of publication, popular places that appear, etc. When they had the problem of author names — knowing when to reverse surname and forname — they ran the names against Amazon and Wikipedia and retained the ones where they found the order of the entry was the same. The Open Library developers are also experimenting with data mining to find publisher names. Publisher names, of course, vary dramatically, but by using ISBN prefixes they can pull together related items into a “publisher” view.

Karen suggested watching the Edward Betts’s site, one of the developers of the Open Library project with an eye on the data mining aspects. She said it is fun to look at our data when it can be viewed from this different point-of-view. She also said to watch out for a new version of the Open Library website coming in February.

Google Book Search Metadata

On the input side, Google is getting bibliographic metadata from over 100 sources in a variety of formats. MARC records are coming from libraries, union catalogs, commercial providers (OCLC), publishers/retails (one publisher supplies records in MARC format). Google also gets ONIX records from commercial providers (such as Ingram and Bowker), publishers, and retailers. Google is especially interested in data from non-U.S. retailers because it is a source of information about books published outside the United States; it helps facilitate discovery of items that they may not otherwise encounter in the publisher and library programs. Google also receives records in a variety of “idiosyncratic formats” — for example, publisher-contributed metadata (via the Publisher Partner Program); information associating books with jacket images; name authority records (from LC); reviews; popularity signals (sales data as well as anonymized circulation data from some library partners, useful for feeding into the relevancy ranking algorithm); and internally-generated metadata (for instance, whether a book is commercially available or not). Google processes all of this information to come up with a single record that describes a book. At this point they have over 800 million bibliographic records and one trillion bits of information in those records.

All of these records from all of these sources are processed and remixed with Google’s parsing algorithms about twice a week. The first step is to transform the incoming records into a “less verbose format” for storage and processing. It is a SQL-like structure that allows elements of the metadata to be queried. Records are then parsed to extract specific bits of information, transform the bits as necessary, and write the information to an internal “resolved records” data structure (a subset of the data coming from the input formats). In the presentation, Kurt had examples of how making inferences from data coming from both MARC and ONIX can be troublesome. Parsing also involves extracting “bibkeys” from the records to aid in matching across sources of data. Four types of identifiers are extracted from bibliographic records: OCLC numbers, LCCNs, ISBNs, and ISSNs. They provide usually useful signals when matching bibliographic and help with assertions that two records describe the same manifestation. Google also tries to parse item data when present in records representing multi-volume works, enumeration and chronology. They will also treat barcode as a form of a “bibkey” if they get it from a library. The parsing algorithm will also split records containing multiple ISBNs representing different product forms (e.g. hardback, paperback, etc.).

With all of this data parsed into records, Google starts its clustering process where records are examined and attached to each other. Bibkeys provide significant evidence for relating records to each other, but bibkeys are not always present in a record (non-U.S. records and older records frequently contain no bibkeys). The algorithms then fall back on text similarity matching using title, subtitle, contributor and other fields such as publisher and publication year. The results are clusters of records representing the same manifestation. An algorithm then attempts to derive the “best-of” record for a single cluster from all of the parsed input records. This is done in a field-by-field voting process based on the trustworthiness of individual fields from record sources.

Kurt went into some of the challenges facing the team building the clustering and best-of record creation algorithms. For instance, in dealing with multivolume works they know of 5 numbering schemas with 3 number types in 15 different languages. Enumeration is now showing in the public display, but the development team is still working with unparsable item data due to inconsistent cataloging practices between institutions…and sometimes inconsistencies within an institution. Another problem is non-unique identifiers. In the current data set ISBN 7899964709 is shared by 75 books and ISBN 7533305353 is associated with 1413 books. There are also poor quality or “junk records”. Kurt said his favorite was “The Mosaic Navigator” by Sigmund Freud published in 1939. These are hard to identify with an algorithm, and they rely on reports of problems that enable the developers to go in and “kill” the troublesome record. Another example is a book by Virginia Woolf where the incoming record had conflicting information; it had two 260 fields that contained different dates (1961, correct, and 1900) with fixed field information that strongly suggested that 1900 was the single date of publication. When the data problem is systematic, they can identify it and compensate for it. Kurt’s example for this case was “The United States Since 1945″ published in 1899. This one was highlighted in Geoffrey Nunberg’s criticism of Google Books metadata. In this case, there was a source of metadata from Brazil that when they didn’t know the date of publication would use 1899. When Google went back and looked at the date distribution of books there was a huge spike in 1899. Once Google knew about it they were able to go in and kill that information from that source of records. ³

In closing, Kurt said that Google is committed to engaging with the library community on improving metadata and metadata processing.

The text was modified to update a link from http://www.niso.org/publications/white_papers/Stream lineBookMetadataWorkflowWhitePaper.pdf to http://www.niso.org/publications/white_papers/StreamlineBookMetadataWorkflowWhitePaper.pdf on January 19th, 2011.

The text was modified to remove a link to http://www.oclc.org/speakers/bios/register_renee.htm on February 11th, 2011.

Footnotes

1. For those not familiar with ONIX, it is a suite of standards promulgated by EDItEUR for the interchange of information on books and serial publications. It is primarily used as the communication channel between the publishing industry through distribution chains to retail establishments.
2. By the way, it seems like BISAC is an acronym for “Book Industry Systems Advisory Committee”, the former name of the Book Industry Study Group.
3. A side note: Google isn’t the only one tripped up by this. If one searches for the ISBN of the item, 0195038487, you get to more than one site that has the same incorrect publication date. At least Google is attempting to clean up the data!

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 keys¹ 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).

The discussion around the table after Jay’s remarks tested some of the “edge cases” to the established hard-and fast rules. OCLC Governance, at least as I understand it, surrounds institutions who are members of the OCLC Cooperative. By implication, the benefits (and also the responsibilities) of membership in the OCLC Cooperative transfer to staff employed at those member institutions. People who work for governing (institutional) members of OCLC can get Developer Network API keys to create services for their library. And except for the fuzzy notion explored previously whether individuals are members of the OCLC cooperative, this all seems pretty clear.

But what about individuals in the employment of a library that is not a member of OCLC that want to create applications that benefit library users. Further, following Jay Jordan’s definition of partners OCLC wants to work with (as expressed during the OCLC Record Use Policy Council Update), that non-institutional-member individual can return value back to the cooperative (by contributing the ideas to the Developer’s Network Showcase, by contributing working code to a software repository, etc.). Isn’t that returning value to the cooperative? Should this person be granted a Developer Network API key even though their institution is not a member? Can we conceive of a process and guidelines by which this could happen? (Has it perhaps already happened in the human-created fuzz of OCLC-the-stewards overriding the established rules?)

I’ll state here that I would support the creating of a process by which anyone — from a member library or a consultant doing work on behalf of a member library or a 12-year-old kid) can request a Developer Network API key. What is needed is a clear understanding that those who get such keys gain some kind of adjunct membership in the OCLC-the-cooperative, and as so are expected to return value to the cooperative through their work with the API key. (There would need to be transparency from OCLC-the-steward on who in this category is getting keys, who is not, and for what reasons — at least in summary.) The area of consultants or other agents doing work on behalf of a library is an area that would need further exploration. I would offer that it is okay for one such agent to use an API key to help a particular client, but I also agree with Jay that it is not okay for that same agent to use that key to derive revenue from helping non-OCLC members with the same key. The latter fails the renumeration-back-to-the-cooperative test (either financial or intangible benefit) that Jay remarked on during Saturday’s Record Use Council session and one that the Record Use Council seems to be struggling with.

These are tough but interesting issues. We’ve left the days where the benefits of membership were tied to the delivery of shelf-ready cards and dedicated terminals for online original and copy cataloging. OCLC seems to be transforming itself from a library-used service to a world-used service. I give OCLC-the-stewards credit for listening to OCLC-the-membership about appropriate ways to make use of the shared resource that is WorldCat, and credit to OCLC-the-membership for pushing OCLC-the-stewards into creating ways to expand access to that shared resource.

The text was modified to update a link from http://dltj.org/article/alamw10-oclc-record-use to http://dltj.org/article/alamw10-record-use-policy/ on December 31st, 2010.

The text was modified to update a link from http://dltj.org/article/alamw10-oclc-record-use to http://dltj.org/article/alamw10-record-use-policy/ on December 31st, 2010.

Footnotes

1. “API” is an acronym for Application Programming Interface. In summary, an API is the set of rules by which one program can task another program for data or to perform a service. An “API key” is the mechanism through which a requesting application establishes the right to be able to use data and services of another application. In this context, the holder of an OCLC Developer Network API key can access the wealth of data and services being offered by OCLC.

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).

WorldCat Growth since 1998

New “Search Engines”

OCLC Services in the Cloud

OCLC is also looking to help with collection management as a cloud-available tool. Working with the New York University Libraries, OCLC is bringing analytics to bear on collection management and space allocation decisions by helping with data about the location of items in the campus library, in the library’s “ReCAP” remote storage, and what is available digitally in HathiTrust. And speaking of HathiTrust, the public interface to 7.5 million volumes digitized largely through the Google Book Search partnership, OCLC is working with project participants to aid the metadata description of items in HathiTrust, to ensure that items in HathiTrust have records in WorldCat, and to add WorldCat Local as an interface to the HathiTrust collection.

Recent problems for Cataloging Partners

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.

Highlights of the Background Presentation

WorldCat itself is now made up of 170 million bibliographic records and 1.5 billion statements of holdings from libraries. A policy is needed to create a viable business plan for sustaining this resource.

What the policy will cover: rights and responsibilities of members that have created WorldCat — the rights of members to use elements of WorldCat and the shared responsibilities to the members of the cooperative that go along with the rights; identifying acceptable use by third parties; what are OCLC’s rights to use the records on behalf of the members; and a process for collective participation in reviewing and modifying the policy over time. It will also have a “rather robust” preamble that answers the question of why a policy is needed, what problem is the policy is trying to solve, and what it is about WorldCat that necessitates a policy.

An Aside: What’s In a Name — OCLC-the-membership and OCLC-the-stewards

The View from the Database Level

1. As a supply of bibliographic records.
2. The ability to represent library holdings — the collective collection of libraries and the capability to reveal what libraries have in places like Google Book Search.
3. Knowledge organization pieces: taking the shared contribution of libraries and makes something more from it using authority control, terminologies, the Dewey Decimal classification system, FRBR work sets, etc.

It was interesting to note a non-U.S. perspective that the council has heard regarding the value of WorldCat. While most North American libraries strongly value WorldCat as a supply of bibliographic records (copy cataloging), the national libraries outside of North America are joining because adding their records to WorldCat gives greater visibility to their holdings. So the second and third value propositions above carry more weight than the first, which is arguably the most valuable aspect for North American libraries.

The challenge the Council said it is facing is to put enough controls in place to protect the value and viability of WorldCat while allowing enough flexibility for members, non-members, and OCLC to experiment and derive new, valuable services. One of the questions the review council is grappling with is how can the Cooperative use “community norms” to ensure the responsibilities assigned to the members are followed so we govern ourselves.

In taking this database-wide view, the council has set aside issues of individual record ownership and copyright of data in records and focused on what is valuable about the collection of records as a whole to the membership. WorldCat as a whole collective is copyrighted. As explained in the follow-up discussion with members of the council, the intellectual property law surrounding WorldCat records extends across many juristictions, so the council chose to focus at the database level.

Third Parties

In licensing WorldCat data to others, OCLC-the-steward is looking for remuneration of some sort for OCLC-the-cooperative. If the business use by a non-member third party is one that will harm the value and viability of the WorldCat Network, then the policy council wants to see it governed in some way. Remuneration can be in monetary form, where that external party pays a fee for the data. Or it can be in a non-monetary form, such as the quid pro quo with the internet search engines that have WorldCat data and in return drive traffic back to local libraries through linkage on WorldCat.org. As Jay Jordan put it sucinctly, “I’ll do a contract with anyone that returns value to the cooperative. Oftentimes, that is not cash.” It was stated that there have been attempts to download the entire WorldCat database. In order to be able to legally stop that, there must be a policy in place that prohibits it.

WorldCat as Linked Data

Questions

1. In Jennifer’s introduction, she talked about not only the value of the bibliographic records but also the value of the holdings. Has the Council looked a differing policies for bibliographic information versus holdings?
2. The discussion of linked data was incomplete due to time constraints. Has there been a discussion about a differentiation of value for different types or views of data? Machine access version human-oriented access? Linked data of some portion of the bibliographic record? Is the representation of the benefit of the world in general being taken into account in drafting policy guidelines?

This morning I was at the OCLC Americas Regional Council Meeting just prior to the opening of the ALA Midwinter 2010 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:

• I am a librarian at an OCLC member organization.
• Am I, personally, a member of the cooperative?
• If so, and most people seem to speak as if it were so, is there a difference between being a member of the library community and a member of OCLC?
• Can I be a member of one and not the other?
• How are my “member” responsibilities to OCLC the cooperative different from my “membership” responsibilities to the library profession?

The phrase “Social Contract” can be broken down into two pieces: Society and Contract. Taking the latter first, I think of the contract as a shared agreement with and among the membership of the cooperative. So before defining the nature of that contract, we need to define the nature of the society forming the contract. For me, what came out this session was a lack of my own understanding of the definition of the collaborative’s “society” in this instance. What seemed particularly awkward to me was a call-to-action towards the end of the breakout session for OCLC members (as in individuals) to get connected to library schools to tell new professionals about the OCLC shared values and social contract. That struck me, as someone thinking that he maybe sort of outside of the “OCLC membership,” as bordering on indoctrination and coercion. Which is to say that the students signed up to be members of the library profession, not necessarily members of a cooperative, because I’m pretty sure the two are not synonymous.

Perhaps this level of discomfort stems from the fact that I wasn’t around when the cooperative was formed, when it seemed like most people speaking up in the room had been. My introduction to OCLC came right at the conversion from dedicated leased lines to access via the internet. As such, I don’t know of a time before there was a strong cooperative for sharing bibliographic records in real-time.

I also find that I don’t have clarity across another dimension of the “society” term. As OCLC appears to try to chart a new course with governance (the evolution of the Members Council to the Global and Regional Councils) and membership (an increasing focus on international libraries and non-library cultural memory institutions), the membership seems to be struggling with what is the bounds of “society” collective. For me, this can’t help but add to the confusion about who is a member — as an individual — and who isn’t.

So I’m left with these questions. If there are answers — or even other opinions — I’d appreciate pointers to them and discussion in the comments.

The text was modified to remove a link to http://www.ala.org/ala/conferencesevents/upcoming/midwinter/2010/index.cfm on February 11th, 2011.

The year is coming to a close, so that must mean that the midwinter meeting of the American Library Association is right around the corner. Yep, there it is — just two and a half weeks away in Boston. A conference in Boston in January — the rates have got to be cheap. ¹ Given the fast approaching meeting, it is definitely time to strategize about how to tap into the pulse of library-land. Here is my plan so far. If you would like to get together in the spaces between meetings, or at the meetings themselves, let me know!

Friday, January 15th

On Friday afternoon I’ll be at RMG’s 2010 ALA/Midwinter Annual Presidents’ Seminar (2:00pm to 5:00pm; Convention Center Room 162 A/B). Rob McGee’s seminars bring together the heads of library automation companies to talk through the issues of the day. Of late, he has also been giving a platform to the various open source library automation projects that might not have a corporate face, so it usually turns out to be a well-rounded discussion. This has long been a Midwinter highlight for me.

At end the day, I’ll probably be at the LITA Happy Hour (5:00pm to 7:00pm; Capiz Bar of the Renaissance Boston Waterfront Hotel). Note the “probably” — it depends on the arrival schedule of someone I need to meet. If weather messes with late afternoon flights, I’m more likely to be at the happy hour.

Saturday, January 16th

My Saturday morning plans continue with an open meeting of the OCLC Record Use Policy review council (10:30am to noon; Renaissance Boston, Atlantic rooms 1/2). As seen by the reaction to the proposed policy, this group is getting to the heart of OCLC as a cooperative and WorldCat as a pool of bibliographic information. Will we come to a new shared understanding of what membership in OCLC is? Can WorldCat records become the heart of open bibliographic linked data? Am I telegraphing my desires too much? We’ll see…

Saturday afternoon has my firmest commitment of the conference: the LITA JPEG 2000 Interest Group (1:30pm to 3:00pm; Convention Center room 157B). I’m serving as chair of this IG, and although we have no formal programming plans, those that come to the meeting in the past have engaged in interesting and thoughtful conversations about the use of JPEG2000 for presenting still images online and for archiving still and moving pictures. Good stuff.

Saturday afternoon rounds out with either the LITA Standards Interest Group meeting (4:00pm to 5:30pm; Convention Center room 104A/B) or the ACRL Image Resources Interest Group meeting (4:00pm to 5:30pm; Westin Copley Place, Great Republic room). On the one hand, the LITA Standards Interest Group is about the only place NISO is planning a public presentation during Midwinter (from what I understand they are not buying exhibit spaces, so they can’t schedule their normal independent update meeting). On the other hand, the ACRL Image Resources Interest Group is just getting going this year, so I’d like to learn more about what they are planning to do. Tough choice…might default to just staying at the convention center…we’ll see.

Sunday, January 17th

Next planned event is the discussion meeting of the LITA Top Technology Trends Committee (10:30am to noon; Convention Center room 162A/B). A good place to network and soak up information.

Then it is back over to the Westin Waterfront for the OCLC Developer Network Luncheon (noon to 1:30pm; Westin Waterfront, Webster Room). Hobnobbing with geeks and eating cold cut sandwiches. Enough said?

Sunday afternoon is open, and will probably be spent in the exhibit hall.

Monday, January 18th

Flying out Monday late afternoon.

Free Midwinter Airport Shuttle

Free Airport Shuttle-(Proof of hotel reservation in ALA hotel block and sign up required) You will receive a free airport shuttle ticket from the Boston Convention and Exhibition Center to Logan International Airport on Monday, Jan 18, 2010 if you reserve a room in the ALA hotel block though Experient (our registration company). You must sign up for the ride at the shuttle supervisor table located at the shuttle drop-off location at the convention center. You must keep your ticket to present to the bus driver when boarding for the airport. Tickets are not transferable. Exhibitors are included.

Sounds great to me. Now, where am I going to stash my luggage on Monday…

The text was modified to remove a link to http://www.ala.org/ala/conferencesevents/upcoming/midwinter/2010/travel.cfm#free%20shuttle on January 20th, 2011.

The text was modified to remove a link to https://www3.oclc.org/app/ala_registration/ on January 28th, 2011.

Footnotes

1. I wonder when we are going to San Antonio next? That is my favorite place for a midwinter meeting. What?!? According to the future conference schedule we’re not schedule to go back to San Antonio but will be back in Boston for 2016? Bummer!