Work Area for Projects and Designs

This page links to project ideas, designs, and documentation. Actual project coding may take place elsewhere.

eXtensible Catalog (XC)

"The University of Rochester River Campus Libraries are designing and developing a set of open-source applications that will provide libraries with an alternative way to reveal their collections to library users. This set of applications, called the eXtensible Catalog (XC), will provide easy access to all library resources (both digital and physical collections) and will enable library content to be revealed through other services, such as content management systems and learning management systems."

• Survey of Needed/Desired Features

Open Cover Database

A database of book, DVD, CD covers that can be accessed and used by anyone.

Basic Goal

• A web-accessible database of covers.
• Covers in sizes small and large (?others?)
• Eventually offer other images
  • front cover
  • back cover
  • spine image
  • title page image
  • What about 'chapter excerpts'? Is this project really a subset of distributing ONIX data?

 

Access Method(s)

http

Match keys

• URL-based, with ISBN, e.g. http://www.coverthing.com/small/00607550X
• URL-based, with LCCN, e.g. http://www.coverthing.com/large/00271772
• URL-based, with OCLC number, e.g. http://www.coverthing.com/small/ocm43836713
  • I'd argue against any use of proprietary numbers TS
  • Problem is, that many libraries consider OCLC# to be THE key. So it is a possible match key, depending on the context (kc)
  • If we want this to work as an international service, the use of OCLC# (as well as the LCCN, for that matter) would be very limiting. (ar)
  • If used, OCLC number would have to also match against prefixes 'ocm' and 'ocn' stripped out(MM))
• URL-based, with EAN/ISBN-13 key
• URL-based, with title/date key (priority? TS)
  • I think this is a "mop-up" key, for those old and "long tail" items that don't have other, more modern keys. I'd put it in the "last 5%" area, until proven otherwise.
  • If only "modern keys" are chosen much will be missed of what was dumped in via recon projects -- i.e., those core collections duplicated widely -- not to mention originally catalogued and local collections NOT widely duplicated; plus OCLC is not primary match key for non-US libraries, including neighbors to the North in Canada (we used UTLAS bib utility years ago); think deeper. I just did a quick run to see how many records we have without so-called modern match keys -- too much basic stuff there (MM)

 

 

 

 

• Returns:
  • Cover, when match is found
  • 1x1 transparent pixel, when no match found (or a 404? 204 there are arguments on both sides)
  • ?? when more than one match is found
    • some covers are dependant on either audience or locale/language. EG, Harry Potter adult covers and junior covers. Harry Potter Polish language etc. These would probably be identifiable through their ISBN, but not through a title search.
  • Each returned image url should be accompanied by a unique CoverThing ID which can be cached/saved by the consuming code. This would allow a degree of permanency. You could otherwise be in a situation where a cover may change from one week to the next depending on the covers that were available at the time. It would also allow CoverThing image return to be sped up for 'known' images.

 

• Alternate Return Type:
  • A more complete machine readable XML data should be available as an alternate, where an XML structure identifying the match(es) found and all metadata for each is returned. Metadata will include URLs to any type of image held, alternate keys representing the same resource, etc. I tried to put in an example in pseudo-XML, but I couldn't get pbwiki to not mess it up. If appropriate and convenient, Dublin Core or other suitable standards could be utilized.

 

 

 

Local Caching

Local caching of images is encouraged.

Access Limits

Consider restrictions, if necessary, eg.

• X requests/day, X mb/day
• Each image X times/month (ie., you must cache)

 

xml

What about an xml based service?

• Submit a variety of possible keys in an xml file - service tries them in priority order?
• Response could contain information for retrieving Cover/Spine/other images
• Allow OAI harvesting?
• Replicate Amazon API for covers would allow easy customisation of existing Amazon cover image services

 

What about JSON results?

• JSON (JavaScript Object Notation) allows very easy integration of results from a search into a client side display.

 

Building the database

• Images from LibraryThing - 230,213 user-provided covers (pending legal review by LT TS)
• ONIX data
• Develop way for libraries to contribute covers (and related agreement for the content)
• Many, many author or subject-specific repositories out there, most not from librarians

 

Using the database

• Search for items by average color of the cover
• Prototype by Dave Pattern at http://webcat.hud.ac.uk/perl/colour.pl (needs speed improvement for large-scale use)
• See also Dave Pattern's blog discussion at

http://www.daveyp.com/blog/index.php/archives/172/

Dave Pattern. (2007 February 1.) Michael Stephens = Norman Bates?!?

 

http://www.daveyp.com/blog/index.php/archives/170/

Dave Pattern. (2007 January 31.) Searching for books by the colour of the cover.

 

http://www.daveyp.com/blog/index.php/archives/169/

Dave Pattern. (2007 January 30.) Colors of North by Northwest.

• Ideally, we'd also be able to search by other prominent features of the cover