Roy Tennant has already commented.

1. Click on "Find Other Library Catalogs" in the upper right side of the Mirlyn screen, and you'll see the entry for MBooks/HathiTrust in the center of the page.

2. Limit searches in Advanced Search to "MBooks only" using the checkbox.

3. In Command Language, search for "wct=mdp"

You may have noticed that many MBooks records contain this reproduction note:

Electronic text and image data Ann Arbor, Mich. : University of Michigan Library 2008 Includes both image files and keyword searchable text. [Michigan Digitization Project]

These notes are going away. Searching on the phrase "michigan digitization project" in Mirlyn no longer retrieves all MBooks. Instead, use one of the methods described above.

Finally, we have gotten questions about items in Mirlyn with links to Google Book Search, but no link to MBooks. This occurs when Google digitizes a book from another source before they digitize our copy. An example of this can be found (for the moment) in this record. The link to GBS is created using Google's API. Eventually, Google will digitize the U-M copy and a link to MBooks will appear in Mirlyn.

* Chinese: http://hdl.handle.net/2027/mdp.39015055131992
* Japanese: http://hdl.handle.net/2027/mdp.39015067188378
* Hebrew: http://hdl.handle.net/2027/mdp.39015019327512
* German/Fraktur: http://hdl.handle.net/2027/mdp.39015070866887
* Russian: http://hdl.handle.net/2027/mdp.39015028011768
* Czech: http://hdl.handle.net/2027/mdp.39015026722820
* Polish: http://hdl.handle.net/2027/mdp.39015055374857
* Greek: http://hdl.handle.net/2027/mdp.39015047659472

The process used to convert from page images to text is called Optical Character Recognition, or OCR. (You can view the OCR text of any of the pages by switching to "text" under "view page as" on the left-hand menu in the pageturner.) Without good OCR, there's no way to search the books. Google is all about search, and they're working to improve the OCR they produce. However, the multitude of languages, scripts, and fonts in this collection poses a serious problem for OCR, and it's likely that Google won't be able to OCR all languages as they encounter them. In addition, the quality of the page itself is critical to good OCR. In many older books, particularly those published between 1850-1950, the paper has deteriorated and discolored, resulting in lower quality OCR.

I can read German, so I know that the OCR for the Fraktur script in the above example isn't perfect. However, given that there isn't much OCR software that can handle Fraktur, it's not bad. I don't read any of the other languages, so I can't make any judgment about the accuracy of the OCR in the rest of the list.

I think that this is an area that Google will continue to improve. You will be able to find examples of books in these languages with very poor OCR. Google is reprocessing texts and will send us new and improved versions, so we will get better OCR as the project progresses.

One of the complexities of this work is assessing the quality of OCR in languages that you don't read. I don't read Italian or Spanish, but they use the same alphabet and Latin roots as other western European languages, so I'm able to at least verify the words without knowing the exact meaning. Chinese, Japanese, Korean, Hebrew, Russian and Greek present many more problems for me. For instance, the text in most of the books in Chinese that I've seen runs from top to bottom (including the example in Chinese above), but the OCR goes left to right. Is that right? Are all the characters there, in the correct order?

The Greek title in the list shows another complexity with OCR: the pages alternate between Latin and Greek, but the text has Greek characters throughout. It's difficult for most OCR software to handle multiple languages in the same book.

We don't have a lot of experience in dealing with non-Western languages in the Digital Library Production Service department, and we'll be reaching out to experts--in the library, in the university, in our consortium--to help us answer questions.

Hebrew and other languages that read right-to-left present special problems for us. In looking at the example in Hebrew in the above list, it looks like the glyphs have been converted correctly, but we're using a right-justified margin rather than left-justified. Here's a sample page image:

And here's the OCR:

We'd welcome hearing from users about these issues.

We've now completed 5 studies (heuristic evaluation, cognitive walk-through, interviews, an informal "guerilla" test, and a comparative evaluation). We've just completed 6 formal usability tests and are in the process of analyzing the results.

Link to MTagger Usability Reports

• Alfresco CMS
• Daisy
• Drupal
• Joomla!
• ModX CMS
• Plone
• SilverStripe CMS
• Typo 3
• WebGUI

We took a look at each of these in some detail, taking into consideration programming languages and local expertise, amount of documentation, vibrancy of the active developer community, comparable "peer" installations (either in other libraries or at other similarly large-scale sites), and a very subjective review of how the admin and authoring interfaces acted. We summarized our findings in a spreadsheet:

After this first pass, we ended up with a short list of 3 tools, the ones with the highest average score:

• Drupal
• Joomla!
• Plone

We then set up out-of-the box test installations of these three finalists and compared them in terms of workflow (our final designs weren't ready, so we didn't focus on making the test installs look "right"). We arranged phone conversations with library IT folks who were using these tools. And in the end, we selected Drupal. While the other two tools had strengths, we ended up deciding against Joomla! because of what we perceived as a surfeit of security problems over time with frequent releases to patch bugs or security holes. We liked Plone, as well, but we felt taking on a new programming environment (Python) for something as critical as our web presence was not sensible.

In the end, though, it was Drupal's strengths in terms of its modular construction, very lively development community, and the number of large academic libraries using it that led our decision.

This report is a follow-up to the McCown et al. article in IEEE Internet Computing two years ago [1], in which the researchers investigated the percentage of URLs from OAI records in Google, Yahoo and MSN search indexes. We were interested in whether Google in particular had increased the number of OAI-based resources in its search index.

Google's indexing does not seem to have retrieved more of the hidden web since the publication of the McCown, et al. article in 2006. We would venture to conclude that Google has not endeavoured to increase their support and access to OAI materials. Even taking into account the caveats in our report, we would also conclude that aggregations of OAI records are as valuable for user research purposes as they were at least two years ago.

[1] McCown, F., Liu, X., Nelson, M. L., and Zubair, M. "Search engine coverage of the OAI-PMH corpus." IEEE Internet Computing 10:2 (March/April 2006) pp. 66-73.

I've done a little bit of rough assessment, and can report on the ten most-used MBooks collections (they are all public collections). Collection usage includes viewing the collection page, searching the collection, sorting the books in the collection, and copying items to another collection. It does not include searching or viewing the items within that collection -- tracking use of a book from a collection vs. from Mirlyn vs. from links from blogs was outside the scope of my quick-and-dirty analysis. Usage from our network range was not included in this assessment.

Here they are:

1. Abraham Lincoln: Fact and Fable
2. Great Britain
3. Ann Arbor History
4. How to be a Domestic Goddess
5. Gothic literature
6. Historical Bicycling
7. Adventure Novels: G.A. Henty
8. What It Was, Was Football
9. Patents
10. French Texts

Abraham Lincoln: Fact and Fable is twice as popular as the next-most popular collection, Great Britain, which is almost twice as popular as Ann Arbor History. As far as I can tell, none of these collections is linked from anywhere else except for the G. A. Henty Adventure Novels, which is included as a link in Henty's Wikipedia entry. Even with the minimal metadata presently available on the Public Collections page, people are finding and using collections that are interesting to them.

The new interface now allows users to create their own collections of MBooks items and view public collections created by others. Users can also do full text searching across all items within a collection.

So, check it out! MBooks Public Collections Page

We have quite a few more enhancements planned down the road that include adding MTagger and making it easier to find MBooks items in Mirlyn.

We quietly released it last week so we could discover any remaining bugs and (my personal nemesis) browser display problems. We hope we caught them all, but please let us know if you experience any weird behavior. You can contact us via mdp-help@umich.edu or the feedback form linked to from the top of every MBooks page.

And please take a few minutes to fill out our quick survey to help us decide what features to add next.

Presumably, one way we could do it would be to make a book ticker – perhaps with covers or title page thumbnails, arranged in call number order (as one would browse a shelf).

That raises a few immediate practical questions:

1. Do we have identified title pages or cover thumbnails for all the books? What do we do for cases where we don’t?
2. Should we precompute thumbnails or try to derive them on the fly?
3. Can we use the Mirlyn call number to browse? They aren’t in the MARC record per se.

These practical questions raise a number of other usability issues, of course. Some are about thumbnails – what size would the thumbnails have to be to make them useful? When you clicked on them, where would you end up? Could you hover over them and see some volume metadata? Can we show thumbnails for in-copyright items? Others are about call number browsing – would you really want to browse all items by call number, or just those from a given library? That is, browse the “real” stacks for a holding location, like Shapiro Undergraduate Library, or the superset of all libraries, the stacks as they’ve never been in the physical world?

To me, the latter choice seems like the best one – it’s something that is only possible in a digital library, as we’d be drawing together items that are housed in separate buildings yet may be related. How do you imagine browsing in the digital library?

We provide a thumbnail image of the cover or title page (although there's been some controversy about this lately). In addition, we also tell you what level of access you can expect if you follow the link to Google Book Search. Google Books has three levels of access, while MBooks has only two:

In Google Book Search, "Snippet view" means that you cannot view the full-text, but can see up to three text snippets; "Search Only" in MBooks means that you can search for keywords, and discover where all the matches occur, but can't view the pages. (See this previous post for more about "Search Only.") "Limited view" means that the book is part of Google's Publisher Partnership, and a limited number of pages is available for reading. You won't be able to see the entire book, but you will have access to a significant number of pages. "Full-text" in Google Book Search means that you can view the entire text, and get a PDF file of the entire text, while "Full Text" in MBooks means that you can view the page images using the MBooks pageturner, and get a 10-page PDF excerpt.

If you look at very many records for MBooks in Mirlyn, you will soon note that in some cases the access levels differ between MBooks and Google Book Search.

• We make US Federal documents freely available, while Google restricts access to "snippet view" in many cases: 2010 and beyond : preparing Medicare for the baby boomers : hearing before the Special Committee on Aging
• In this case, Google Book Search offers "limited view," which allows you access to many pages in the book, while MBooks offers "search only" access: 500 bracelets.
• In this case both Google Book Search and MBooks provides "full text" access: The £1,000,000 bank-note, and other new stories, by Mark Twain

In this last example you'll have full-text in either Google Books or MBooks, so you can decide which interface you prefer. Knowing how to read the Mirlyn record will help you find the best access for any given book. Happy reading!

--Perry Willett
--Head, Digital Library Production Service

We're still working out some bugs and interface issues but hope to release soon. Check back in July!

We've also completed a "guerilla" test and we're in the process of conducting interviews and preparing for formal user tests and a survey. Reports for those studies will also be put online when they're done.

Link to MTagger Usability Reports

- Suzanne Chapman
-- UWG chair/DLPS Interface & User Testing Specialist

There are a couple of issues. The first is about URLs. The most stable and persistent URL is the one that we include in the Mirlyn record, and also at the top of the pageturner with other descriptive metadata. It's called a "handle" and is a robust persistent identifier managed by CNRI (more on handles at http://www.handle.net/). They look like this:

http://hdl.handle.net/2027/mdp.39015021038404

and this is the URL that we encourage people to use and save. However, since they all start with http://hdl.handle.net/2027, people don't recognize them as belonging to the University of Michigan. Users are much more familiar with URLs that include the umich.edu domain. Nevertheless, since these handles are persistent and robust ("2027" is registered with CNRI as belonging to us) these are the URLs that should be used.

Other URLs will be less stable. The sharper-eyed among our readers will have noted that our URLs recently changed from starting with "mdp.lib.umich.edu" to "sdr.lib.umich.edu". We will redirect users any time they use a URL starting with "mdp.lib.umich.edu" but these local domain names will change over time. The same is true for the URL parameters such as "page," "num," "seq," "orient," etc. Phil Farber's response to the same post noted above provides documentation on what these mean, but be aware that these will change without warning. URL hacking will lead to tears before bedtime.

The other related issue has to do with page numbers and other metadata. People will notice that many MBooks include a table of contents with page numbers on the left-hand side, such as this one. You may also notice that some books lack this table of contents, and use "sequence" instead of page numbers. Here's an example of a book for which we do not have page numbers.

It all has to do with the metadata. At a minimum, we know the sequence in which the pages of any given book should be displayed. The pageturner buttons for forward and backward use this information to work properly, but for some books, this is all the information we have. Since the sequence of pages starts with the front cover, it's unlikely that the sequence number will match the actual page number. (And as Suzanne noted in her comments to this post, if someone has a better term than "sequence" please let us know!) Many of these books without page numbers were early efforts by Google; they are sending us newer, better versions of these books, so eventually the entire collection will include page numbers.

In many (soon most or all) cases we will have page numbers, along with additional metadata identifying title pages, tables of contents, first pages of sections, and other page features. We get these metadata from Google. We don't know how Google generates them, but it's undoubtedly an automated method. This means that they won't be perfect. When we do have metadata indicating the title page, we will open the book to the title page as a default. If we don't have any metadata about the title page, we will open to the first image (usually the front cover).

Page numbers are, to quote the kids, whack. In some books, they are out of sequence, or repeated, or misnumbered, or missing. With many journals, the library has bound together two or more issues, each with its own pagination from 1 to whatever. Therefore, the online volume could have multiple pages numbered 207, as in the example that David points to in his comments to the post mentioned above. Right now, MBooks will take you to the first instance of p. 207 if you type that into the "goto" box. We could probably do something to alert people to the fact that there are multiple pages numbered 207, and give them links to each of them.

We need to consider having persistent URLs to individual pages. People want to refer to individual pages, and we should have a method with a stable URL to allow them to do it. We could also do more to have a predictive method of referring to a page. Ed Vielmetti recently wrote some ideas about this in his blog.

We will look at this more carefully soon, once we get through the current round of development for collection builder and other new features.

--Perry Willett
--Head, Digital Library Production Service

One of the great things about working at a library is the depth and breadth of data at our disposal. One of the more frustrating things is how terribly locked-up all that data is.

What, I wondered, would happen if I could radically lower the bar of entry to the catalog for programmers of even marginal ability? The University of Michigan has a pretty big collection, and there's no telling what people could do with that data if getting at it was a lot easier, if they didn't need special permission or access to a particular machine, and if it was useful inside the browser using Javascript as well as in server-side operations?

So I went about trying to create a system that fulfilled, at least partially, those criteria. Unlike many ILS systems, Aleph already provides a whole suite of interfaces, including an XML-based API they call the XServer. Unfortunately, the XServer has, in my opinion, a number of shortcomings:

• As its name suggests, it's based on XML, which can be confusing to deal with to the uninitiated. Remember, my focus is on weekend programmers, maybe just writing javascript inline in an HTML document.
• URLs for an XServer search don't mean anything. First you do a search, and get back a search set. Then you ask for some records using that search set in the URL. It's essentially a random identifier, and looking at the URL doesn't tell you anything about what search was done or what you're getting, and you're sure not going to construct one by hand.
• The interface is...messy. It's clearly a system that grew up organically, and there are a lot of inconsistencies concerning how things are named, what parameters are called, etc. I wanted an interface where you could take a good guess at what the URL should look like and be right 90% of the time.

When I was all done, I had a system that supports queries like this:

A book by ISBN:

http://mirlyn.lib.umich.edu/cgi-bin/api/basic.json/isbn/097669400x

Or a couple:

http://mirlyn.lib.umich.edu/cgi-bin/api/basic.json/isbn/0596000278;097669400x?records=all

The most recent 10 books by anyone named 'Bonk'

http://mirlyn.lib.umich.edu/cgi-bin/api/basic.json/author/bonk?records=1-10

And how about the next ten?

http://mirlyn.lib.umich.edu/cgi-bin/api/basic.json/author/bonk?records=11-20

You can search by title, author, keyword, most standard numbers -- just about anything you can use to search the catalog via the website. The full list of searchable indexes and their aliases, as well as all the current Mirlyn API documentation, is on the new MLibrary API wiki.

While all the above examples return a subset of available data in the JSON format, you can also return XML if you're more comfortable with it, and besides the "basic" data you can get circulation status or full MARC records (expanded into either XML or JSON). Just replace "basic.json" in the above URLs with something like "marc.xml" or "circstatus.json".

There's still a lot to do (allow user-defined sorting, let people browse by callnumber, etc.) but it works and is useful and is certainly friendly, in enough ways, that people can start digging into it if they want.

I've put some simple javascript examples on the MLibrary Labs page; check them out, and drop me a note (or, better yet, comment here!) if you have questions or ideas.

If a book has been scanned by Google, there is a "search in in this book" field within the library catalog record. Depending on the particular book, a search will result in full text results (if the book is in the public domain) or search-term only view (if the book is in copyright).

Here is an example of an out-of-copyright book (with full-text results available): 1931: A Glance at the Twentieth Century. The record in the catalog looks like this:

Screen Shot of Mirlyn Record with "Search in this Book" Option

And here are the results of that search:

Screen Shot of MBook Search Results

All books that have been scanned -- one million and counting -- are searchable. Search results are linked to the full text for those works that are in the public domain. Search results for books that are still under copyright are shown in brief view. Brief view displays a phrase or two on either side of the search term, but doesn't include full-text display of the page. In either case, the search in the book tool will help you know if you want to get the actual book off the shelf before you visit the library or make a delivery request.

Try these sample records:

Full-text: The Miscellaneous Writings of Lord Macaulay

Search only: 500 Bracelets: An Inspiring Collection of Extraordinary Designs