When I saw the post I printed it out (i know…the trees) and started marking it up.  This morning when I came back into the office I took a look at the paper and realized that most of the ideas that I liked were basically screaming “I’m a project!”  Some of the highlights from the post were:

• create a user-base for your data
• market to that user-base
• think about publishing your data at the beginning of the project
• consider the sustainability of publishing your data
• think about what you’re hoping to accomplish with your open data
• who are you targeting by opening up your data
• build your project based on what you want to accomplish and who you’re targeting

None of these points are really that new to me (or to anyone that works in systems).  You need to plan before starting on a project, and if you plan right you can have an awesome project.  I think planning is what makes data.gov.uk so much better than data.gov.  It was well thought out.  They considered user-bases in advance.  They incorporated RDF into the data catalogue (yes that’s the british spelling…we are talking about a british site afterall).  These little subtleties are what people are the most excited about.

At the same time I recognize that a lot of times we’re working with retrospective data, data that we thought no one would ever want to take a look at.  But that doesn’t mean you can’t make it useful now, and data.gov.uk proves that. Through great planning they created a very useful tool.

So my point is PLAN PLAN PLAN.  A well thought out plan can make a project succeed or fall flat.

Share/Save

Ex Libris owns a little product called SFX.  Anyone that knows OpenURL knows that its pretty darn simple to figure out.  What you’re really paying for is someone to update the KnowledgeBase; anyone who has ever heard a sales pitch from an Ex Libris Rep knows that its all about the KnowledgeBase.  In essence users of Ex Libris’ SFX have been doing co-operative cataloging from the beginning (albeit via an intermediary).  When libraries see a problem with a journal record or find a missing journal record, they submit the problem to Ex Libris’ KB Team who fixes it for them.  When Verde was released, this functionality of sudo co-operative cataloging extended to that product as well.  And don’t forget that MetaLib also has a KnowledgeBase with records that users can update.

OCLC does the same thing for catalog records.  Libraries create records, upload them to the collective, and they get shared out.  The difference (up until now) was that OCLC didn’t have a product that you could really use with those records other than a search engine.  Ex Libris on the other hand built three products, two that provided services to users and another that helped libraries manage their resources.  OCLC it seems has decided to do something similar.

And, get this, other vendors are already following suit.  Serials Solutions has a number of products based on it’s KnowledgeBase (360 Link, 360 MARC Updates, 360 Resource Manager, etc. etc.).  The more products they create based on their KnowledgeBase the closer they get to a co-operative cataloging collective, at which point who knows, maybe they might want to also break into the ILS game.  EBSCOHost is another vendor I see gathering their resources together for co-operative cataloging efforts.  EBSCOHost already has a phenomenal KnowledgeBase of article records, arguably the best in the business.  They are in the process of releasing their Discovery Layer which I have to say is very sleek.  Who’s to say that an ILS type resource isn’t already on someone’s brain over there.

I believe the library world will start to organize around co-operative cataloging vendors (and I’m going to put OCLC into the vendor pool like Ed pointed out others are starting to do).  Essentially libraries will need to make a decision; do you like Ex Libris’ KnowledgeBase, OCLC’s KnowledgeBase, or some other vendor’s KnowledgeBase.  So Karen’s concerns about how your membership in other consortia will be effected disappears; essentially you’ll be in one large consortium type environment once you choose a vendor.  Or perhaps your membership in local consortia will be limited to getting quick delivery of materials and sharing other types of administrative duties.

And yes, OCLC is in an unfair position since they have been cultivating their KnowledgeBase for significantly longer than other vendors.  But I don’t think this will stop other vendors from developing their own co-operative cataloging collectives.  As technology progresses and it becomes easier and easier to develop discovery applications (think VuFind or BlackLight) or pool resources to develop your own ILS (think Evergreen or OLE), vendors have no choice but to get into the business of selling us data decoupled from an interface, because in the end we just don’t have the time to create all that data on our own (can you imagine the team necessary to abstract and index all those books, journals, articles, etc that we currently supply to our patrons).  Don’t lie, you know you want them to give us the data and then leave it up to us to do all the cool app development.

While in the beginning I thought the cloudy ILS was a big deal, in retrospect I think the bigger deal is how the other vendors will react to OCLC’s announcement.

CAVEAT: I don’t think my predictions will come to light tomorrow…I’m thinking somewhere down the line…say 5 years.  And yes I do understand how annoying it is that libraries have cataloged all that material and shared it with OCLC only to find out that OCLC is itself a vendor.  I find it annoying too.

Share/Save