The new issue of TechKNOW is now available. July 2010, Volume 16, Issue 2

• AutoIt for Technical Services Workflow / Becky Yoose, Miami University Libraries
• Coordinator's Corner / Fred Gaieck, Ohio Reformatory for Women
• Book Review: Introducing RDA: A Guide to the Basics / Chris Oliver
• BarTender Software Allows Dayton Metro to Eliminate Stickers, Streamline Workflow / Andrea Christman, Dayton Metro Library
• US RDA Testing Period
• Book Review: Acquisitions in the New Information Universe: Core Competencies and Ethical Practices / Jesse Holden
• LCSH Headings for Cooking and Cookbooks Have Been Changed

(Full document now here! Thanks Marshall Breeding!)

The newly created competitor to OCLC's cataloging services, SkyRiver, is suing OCLC in federal court in San Francisco. (Press release, PDF) I have only seen the press release, so until someone figures out how to free up the actual legal document, what we know is:

SkyRiver is claiming that OCLC is attempting to "monopolize the the markets for cataloging services, interlibrary lending, and bibliographic data, and attempting to monopolize the market for integrated library systems, by anticompetitive and exclusionary practices." The press release refers to OCLC's "tax-free profits," and that OCLC has used those profits to purchase 14 for-profit companies.

The press release quotes Leslie Straus, President of SkyRiver, as saying:
“In the process OCLC has punished its own members who have tried to seek out lower cost alternatives like SkyRiver.”Which undoubtedly refers to the Michigan State issue, which I reported on here. In that case, OCLC appears to charge MSU an unusually large fee for uploading records to WorldCat after MSU began cataloging on SkyRiver instead of OCLC.

Undoubtedly, a good part of the concern here is over OCLC's plans to provide Web services that comprise the full functionality of an integrated library system (ILS), thus competing with current ILS vendors. You probably know that SkyRiver was started by Jerry Kline, owner of Innovative Interfaces. If OCLC successfully launches a full-service option for libraries, Innovative and other ILS's will suffer. As the representative of a major ILS company explained to me a few years ago, the library market is a zero-sum game: every time one vendor wins, others must lose, because the number of customers is not growing. The library market is a pie that can be divided into any number of slices, but the pie remains the same. This makes the rise of any one company a threat to all. In the commercial marketplace, the vendors compete over functionality and price. With its non-profit status OCLC has a distinct advantage: it doesn't pay federal income tax on the revenues it brings in. That said, given its size and depth of its involvement in day-to-day library operations, it is plausible that even without its non-profit status OCLC would be a formidable competitor for ILS vendors.

I cannot comment on the charges of anti-trust because the press release does not give enough information. Hopefully we will get more details about this suit in the near future.

In a move that could have far-reaching implications for competition in the library software and technology services industry, SkyRiver Technology Solutions, LLC has filed suit in federal court in San Francisco against OCLC Online Computer Library Center, Inc. The suit alleges that OCLC, a purported non-profit with a membership of 72,000 libraries worldwide, is unlawfully monopolizing the markets for cataloging services, interlibrary lending, and bibliographic data, and attempting to monopolize the market for integrated library systems, by anticompetitive and exclusionary practices.Seen on the Library Technology Guides site.

News from ALA.The ALA Committee on Cataloging: Description and Access (CC:DA) has approved the consolidated Greek romanization table of April 2010. This revised table differs from the existing table only in the inclusion in the consolidated table of two archaic letters and additional examples. The consolidated table also does not include Coptic for which a separate table will be developed. The approved consolidated table has replaced the existing table on the Cataloging and Acquisition Web site (http://www.loc.gov/catdir/cpso/roman.html) and will be published in the Summer 2010 issue of Cataloging Service Bulletin. The Policy and Standards Division wishes to express its gratitude to those who commented on the draft table.

I woke up this morning to find a very excited flurry of posts in my Twitter stream pointing to the launch by the UK National Archives of the legislation.gov.uk site, which provides access to all UK legislation, including revisions made over time. A post on the data.gov.uk blog provides some of the technical background and highlights the ways in which the data is made available in machine-processable forms. Full details are provided in the "Developer Zone" documents.

I don't for a second pretend to have absorbed all the detail of what is available, so I'll just highlight a couple of points.

First and foremost, this is being delivered with an eye firmly on the Linked Data principles. From the blog post I mentioned above:

For the web architecturally minded, there are three types of URI for legislation on legislation.gov.uk. These are identifier URIs, document URIs and representation URIs. Identifier URIs are of the form http://www.legislation.gov.uk/id/{type}/{year}/{number} and are used to denote the abstract concept of a piece of legislation - the notion of how it was, how it is and how it will be. These identifier URIs are designed to support the use of legislation as part of the web of Linked Data. Document URIs are for the document. Representation URIs are for the different types of possible rendition of the document, so htm, pdf or xml.

(Aside: I admit to a certain squeamishness about the notion of "representation URIs" and I kinda prefer to think in terms of URIs for Generic Documents and for Specific Documents, along the lines described by Tim Berners-Lee in his "Generic Resources" note, but that's a minor niggle of terminology on my part, and not at all a disagreement with the model.)

A second aspect I wanted to highlight (given some of my (now slightly distant) past interests) is that, on looking at the RDF data (e.g. http://www.legislation.gov.uk/ukpga/2010/24/contents/data.rdf), I noticed that it appears to make use of a FRBR-based model to deal with the challenge of representing the various flavours of "versioning" relationships.

I haven't had time to look in any detail at the implementation, other than to observe that the data can get quite complex - necessarily so - when dealing with a lot of whole-part and revision-of/variant-of/format-of relationships. (There was one aspect where I wondered if the FRBR concepts were being "stretched" somewhat, but I'm writing in haste and I may well be misreading/misinterpreting the data, so I'll save that question for another day.)

It's fascinating to see the FRBR approach being deployed as a practical solution to a concrete problem, outside of the library community in which it originated.

Pretty cool stuff, and congratulations to all involved in providing it. I look forward to seeing how the data is used.

I have just returned to the US from a couple of weeks vacation in Ireland and England. I was more than usually struck by my bookstore (aka book shop) experiences, and this prompted the curation entry I have just written. First of all, an interesting note that I have quoted... dempsey http://orweblog.oclc.org

As existing practices evolve and new ones emerge it often takes time for the way in which we talk about them to settle down. There may be some interim terminological confusion. This has happened in our world with 'archive' for example. We can also see this happen with curation/curation/curator. In... dempsey http://orweblog.oclc.org

I’m using the insanely awesome Flot JQuery plotting/charting package for the soon-to-be-released range limit plugin for Blacklight.

So one problem I ran into. The place I’d like to put my Flot chart is in a div on screen that is often initially hidden, and only shown when the user expands it by clicking on a heading.

There are at least two problems with that. One is that Flot requires an explicit width and height to be set.  But I’d like to have my plugin be ‘liquid’ in it’s display of flot.  Flot is fine if you set the width and height with javascript, as long as you do it before you draw Flot. Okay, so I figure I can look up the width with JQuery.width(), compute the height using a good ratio.  Except you can’t look up the width of a hidden div, it doesn’t have one.

The other, more obvious problem, is that Flot simply won’t draw in a hidden div, even if you do explicitly set the width and height. It does all sorts of wild calculations to figure out the best places to put labels and such, and it can’t do that unless it’s placeholder container is actually in the DOM, not hidden.

So, I thought, okay, it needs to be shown, but what if it’s shown, but off screen (absolutely positioned somewhere way off the monitor). Does that work?  Well, sort of, sometimes. If I took only the plot placeholder div and moved it off screen, Flot would be willing to draw, but when I later moved it back on-screen to view it, flot’s labels and tick marks and such were all over the place, in the wrong places.

But. If I took the parent div to the flot placeholder, the one that in my page is actually being hidden and shown, and moved it off-screen… everything worked.

So here’s what I do to draw a Flot chart “off screen” without really being off-screen.   Show the parent div; calculate the width/height; move the parent div off screen, have Flot draw itself, re-hide the parent div, put it back on screen. It all happens quick enough that it’s as-if Flot were drawn in a hidden div.

Working in the four browsers. It may not exactly be a general purpose solution, because it may depend to some extent on the surrounding DOM, but it works in my DOM.

Here’s a nice little wrapper routine I wrote that, at least in my case, does the job. (using a javascript closure to wrap the actual drawing).

// example use: wrapPrepareForFlot( $(placeholder_div), $(parent_that_might_be_hidden), desired_width_to_height_ratio, function(placeholder) { //code to actually draw Flot goes here }); // definition: /* Set up dom for flot rendering: flot needs to render in a non-hidden div with explicitly set width and height. The non-hidden thing is annoying to us, since it might be in a hidden facet limit. Can we get away with moving it off-screen? Not JUST the flot container, or it will render weird. But the whole parent limit content, testing reveals we can. */ function wrapPrepareForFlot(container, parent_section, widthToHeight, call_block) { var parent_originally_hidden = $(parent_section).css("display") == "none"; if (parent_originally_hidden) { $(parent_section).show(); } $(container).width( $(parent_section).width() ); $(container).height( $(parent_section).width() * widthToHeight ); if (parent_originally_hidden) { parent_section.addClass("ui-helper-hidden-accessible"); } call_block(container); if (parent_originally_hidden) { $(parent_section).removeClass("ui-helper-hidden-accessible"); $(parent_section).hide(); } }

There’s a different approach you could take too, that I might revisit later, which would have it’s own tricks: Instead of trying to pre-render the plot in a ‘hidden’ div, don’t load it until the user actually shows the div, then start loading it. Because JS/JQuery doesn’t have a built in “onshow” event, this would take some tricks too, but should also be do-able. Wonder if there’s a JQuery plugin to provide a general purpose on-show event somehow?

Filed under: General

The SolrMarc example/default configuration tries to get a publication date out of 260$c.

This is a tricky thing to do, because you’re trying to parse not entirely coded data. And on top of that, I just discovered that dates in other calendar systems can legally appear in 260$c, if that’s how they appear on the title page. A title page has Hebrew Callendar 5750 in it? That’ll be in the 260$c. Oops.

So it’s probably better to try and get dates out of the 008 fixed field. One problem here is it’s a lot more confusing, you’ve got to get ascii decimal digits out of fixed byte positions (machine readable what?), and you really need to talk to a cataloger to get to the bottom of “date1″  and “date2″, as well as the “date types” and what they mean.

Beware f date type “q”, for “questionable date”, meaning that the publication date is somewhere in in the range of date1 and date2.  (These would seem , by examples in the OCLC documentation, to be inclusive boundaries, although the documentation doesn’t actually explicitly say that).

On top of that, dates in date1 and date2 can show up with “u”s in them for unknown digits. “19uu” means sometime in the 20th century.

And in the final note in the this is really meant to be machine readable? column, let’s say you know something was published in the 19th or 20th century.  You might think you’d use the “q” date type and put date1=1800 and date2=1999, that would certainly express what you know. But no, the OCLC examples say to put this in as “q” date type, with date1=18uu and date2=19uu. huh?

The other problem with getting dates out of 008 fixed bytes is that since so many of our traditional ILS’s completely ignore them, it’s not clear to me how correct they’ll be, since a mistake didn’t matter much before.  But in a testament to years of catalogers entering correct data even though their systems did nothing with it, the data seems at first analysis to be pretty good. I think it’s going to be better than trying to get a date from 260c, especially with the “hebrew date” issue.

Filed under: General

Image via WikipediaLC continues to create cartographic genre/form terms.
The Policy and Standards Division (PSD) of the Library of Congress continues to develop genre/form headings on a discipline-by-discipline basis, and will implement genre/form headings for cartographic resources on September 1, 2010....
On September 1, 2010 the Library will implement cartographic genre/form headings and the revised form subdivisions in new cataloging. PSD will work to update existing bibliographic records to change the form subdivisions and add genre/form headings, and expects to complete the process within a year.Related articles

• Genre/Form Terms Policy at LC (catalogablog.blogspot.com)
• Bigwood, David: Name Authority Records Enhanced with Geographic Coordinates (catalogablog.blogspot.com)
• Bigwood, David: Genre/Form Headings for Moving Images (catalogablog.blogspot.com)

The Licence Negotiation team here are thinking about the kinds of technical questions they should be asking publishers and other content providers as part of their negotiations with them. The aim isn't to embed the answers to those questions in contractual clauses - rather, it is to build up a useful knowledge base of surrounding information that may be useful to institutions and others who are thinking about taking up a particular agreement.

My 'starter for 10' set of questions goes like this:

• Do you make any commitment to the persistence of the URLs for your published content? If so, please give details. Do you assign DOIs to your published content? Are you members of CrossRef?
• Do you support a search API? If so, what standard(s) do you support?
• Do you support a metadata harvesting API? If so, what standard(s) do you support?
• Do you expose RSS and/or Atom feeds for your content? If so, please describe what feeds you offer?
• Do you expose any form of Linked Data about your published content? If so, please give details.
• Do you generate OpenURLs as part of your web interface? Do you have a documented means of linking to your content based on bibliographic metadata fields? If so, please give details.
• Do you support SAML (Service Provider) as a means of controlling access to your content? If so, which version? Are you a member of the UK Access Management Federation? If you also support other methods of access control, please give details.
• Do you grant permission for the preservation of your content using LOCKSS, CLOCKSS and/or PORTICO? If so, please give details.
• Do you have a statement about your support for the Web Accessibility Initiative (WAI)? If so, please give details?

Does this look like a reasonable and sensible set of questions for us to be asking of publishers? What have I missed? Something about open access perhaps?

I don't do much thinking about 3D virtual worlds these days but it's good to see the recent announcement by one of our early Second Life projects, SLOODLE, that they have been awarded a Learning & Teaching Innovation Grant from the JISC:

The year long project on Supporting Education in Virtual Worlds with Virtual Learning Environments will conduct pilots at each participating institution and will explore how web-based learning environments (esp. Moodle) can effectively support and enhance learning in virtual worlds.

Lorcan Dempsey has a blog post about ‘stitching costs’ that gives me some useful language to plug Umlaut some more.

Libraries are also familiar with high ‘integration’ costs: perhaps these might be called stitching costs. This means that it may be costly developing higher level services based on integration of various lower level services.

Umlaut is in part intended to deal with ‘stitching costs’ for one class of services: “known item services”.  And also with where ‘stitching’ and ‘switching’ intersect — once you’ve integrated a bunch of your services in a rube goldbergesque contraption, then part of the cost of switching one of the underlying services out becomes the ‘stitching’ of the new one into your overall aggregate system. An issue more and more libraries will probably start running into, as more have developed such ball-and-twine systems of integration over the past few years, possibly in such a way that the first time one of the underlying components need to be switched, it’s going to be painful.

The idea of Umlaut is that it’s a platform that you can easily write plugins for to consult various internal and external sources of data on ‘known items’ (catalog, link resolver knowledge base, worldcat, Scopus, whatever).  The platform is there for you so you can just focus on the source-specific logic in the plugin, is the idea. Then Umlaut vends the aggregated information collected through both an HTML web page, but also several APIs designed to be as easy to use as possible, so you can embed the aggregated information in whatever other services or web pages you want.

There is a full api (delivering in XML or json), as well as an API that delivers a collection of HTML snippet sections ready to be dropped in as-is on a foreign web page. Both APIs provide incremental results with information on what services are still fetching data, for polling. (As fetching data from various external services can end up being slow).

So theoretically, once set up, this should decrease both the ‘switching’ and ‘stitching’ costs of individual elements in your infrastructure.  Switch out a source of known item data? No problem, just write an Umlaut plugin for the new one. Switch out a service that consumes known item info from Umlaut and delivers it to users? No problem, the new service just needs to access Umlaut’s easy to use APIs.

Now, in practice, it is admittedly not necessarily quite so simple as I mkae it sound, as writing both writing an Umlaut plugin and making a new product access and deliver info from Umlaut’s APIs can be significant tasks — but I’m convinced that this architecture significantly lowers stitching costs, and switching costs due to stitching costs, in the long run.

As a chief example, it should theoretically allow us to consider ‘link resolvers’ just in terms of quality of knowledge base, without worrying about the link resolvers own interface. As Umlaut accesses the link resolver knowledge base via api and provides it’s own (html and api) interfaces, if we decide that there’s a better product for it’s knowledge base, we should be able to write an Umlaut plugin for the better one (as long as it has an api), switch it out, and not only will our user experience be mostly unaffected, all existing ‘stitched’ services will not have to be touched a bit, they’re still talking to Umlaut, which just has a new plugin data source.  This depends on the desired new link resolver having an PI which is sufficiently robust and performant for Umlaut’s needs, but not on any of the desired link resolvers own presentation features.

Filed under: General

I am on vacation and traveling this week, and so am taking the opportunity to air again an entry of a couple of years ago on what I called 'stitching costs' .... We are familiar with switching costs, the costs of changing a supplier. I may decide not to change... dempsey http://orweblog.oclc.org

One of the recurrent themes of this blog has been the work done by libraries to put more of their services in the flow of their users' working, learning and research behaviors. In this context, I was pleased to see the work by my colleagues on implementing Worldcat searches in... dempsey http://orweblog.oclc.org

Image via CrunchBaseGoogle has bought Metaweb, the folks behind Freebase. This could be an important step on the way to a more semantic web.
In addition to our ideas for search, we’re also excited about the possibilities for Freebase, Metaweb’s free and open database of over 12 million things, including movies, books, TV shows, celebrities, locations, companies and more. Google and Metaweb plan to maintain Freebase as a free and open database for the world. Better yet, we plan to contribute to and further develop Freebase and would be delighted if other web companies use and contribute to the data. We believe that by improving Freebase, it will be a tremendous resource to make the web richer for everyone. And to the extent the web becomes a better place, this is good for webmasters and good for users.Related articles

• Google Acquires Metaweb To Make Search Smarter (techcrunch.com)
• Deeper understanding with Metaweb (googleblog.blogspot.com)

It occured to me a while ago that Umlaut isn’t just a ‘link resolver front end’, or an ‘improved link resolver’. It is those things, but when you improve a link resolver enough, and pay attention to all forms/genres (not just journals), what you get is what I’m clunkily calling a Known Item Service Provider, an additional piece of library infrastructure.

I’ve come to think that this is in fact an essential tool that most library digital infrastructure is missing. As an infrastructural tool, it’s not neccesarily designed to answer just one question for one very particular use case, it’s designed to answer the general question (for people and machine access): “What can you tell me or do for me about item X”?

Andy Powell brings up a specific question/use case that’s a sub-set of this: If I know a print book I’m interested in, and likely even know it’s ISBN, does the library have a licensed ebook version?  And secondarily, is there an ebook version in existence whether or not the library licenses it?

This is definitely something in Umlaut’s domain. How well does Umlaut do at answering it?  Currently, the second one ‘does an ebook exist whether or not we license it’, not very well, but if external sources of data (with APIs) could be identified to answer it (as Andy begins doing), plugins to Umlaut could be written to grab those data and make Umlaut’s answer better for this specific use (and perhaps improve other unexpected uses too, since you’ve improved the infrastructural tool).

The first one, does the library have an ebook version, Umlaut does better at, at least at our library.

This works because our library has endeavored to list most ebooks we have in our catalog, and Umlaut tries to do searches of the catalog.But it’s success depends on:

• We have a record in the catalog OR in our link resolver knowledge base for the ebook. (Umlaut tries to combine both sources of information).
• Umlaut successfully finds it, which is somewhat trickier than it sounds, since Umlaut uses some heuristic algorithms to try and balance precision (minimize false positives) with recall (minimize false negatives), as well as avoiding duplicate information when data exists in both the catalog and the link resolver.
  • sometimes the ebook record in our catalog has the print ISBN on it too. This will make umlaut’s job easier. Not sure if the SFX knowledge base puts print ISBNs on ebook records.
  • Sometimes Umlaut will do a title-author search of our catalog, but whether it does or not is related to complicated heuristics, which could be tuned for this use case and our data if we put some time into it.

But in fact, it does a reasonably good job anyway. Here are some example Umlaut URLs which take a print ISBN, and tell you “what can the library do or provide for this item”, and the result includes licensed ebooks.  I’ll include a few title-author input too, to show that’s feasible too.

• (Although it occurs to me that most of these ‘ebooks’ are web readable, not neccessarily downloadable to a reader; not sure if that’s what Andy meant. We don’t have many downloadable ebooks in our collection; if we did, they’d show up here too, ideally identified as such, although that can be tricky).
• http://findit.library.jhu.edu/resolve?isbn=0387167897
• http://findit.library.jhu.edu/resolve?isbn=0127364501
• http://findit.library.jhu.edu/resolve?rft.title=the%20geneva%20ballad&rft.au=samuel%20butler
• http://findit.library.jhu.edu/resolve?rft.isbn=0596001916
• http://findit.library.jhu.edu/resolve?rft.title=women under socialism&rft.au=august bebel
• http://findit.library.jhu.edu/resolve?rft.isbn=9780195181142 (this one, Umlaut fails in de-duplicating, and presents two links to the same place, although they’re identified differently.
• http://findit.library.jhu.edu/resolve?rft.isbn=9783540718352 [ditty for this one, duplicate links provided. but that's better than none at all!]
• http://findit.library.jhu.edu/resolve?rft.title=The%20kidneys%20and%20how%20they%20work [ I don't know if an NIH PDF counts as an 'ebook', but still shows the concept ].

It’s definitely far from perfect, I showed you some succesful positives, finding false negatives would take more time, but I’m sure there in there. (We generally tune Umlaut to avoid false positives, so those are less likely, but there’s surely a few).

Umlaut doesn’t use xISBN or any other “work set expander” service right now, that’d be one obvious improvement, I’d hope to make sometime. Although ideally not before collecting some kind of evidence on how often Umlaut fails for certain tasks in ways that would be improved by a “work set expander”.  There are other data sources and other tunings to Umlaut’s heuristics that could be done.

But I think it shows itself pretty admirably anyway. The point is that Umlaut, as an attempted platform serving as “Known Item Service provider”, is a general purpose tool that can handle this specific use case among many others, and the beauty of a general purpose tool is when you improve it for a certain use case, you get unintended benefits to other use cases you hadn’t yet considered, instead of just having very specific tool for very specific use cases.  I propose that a Known Item Service provider like Umlaut ought to in fact be a key part of an academic libraries infrastructure.

Filed under: General

Some of you will know that we recently ran a quick survey of academic e-book usage in the UK - I hope to be able to report on the findings here shortly. One of the things that we didn't ask about in the survey but that has come up anecdotally in our discussions with librarians is the ease (or not) with which it is possible to find out if a particular e-book title is available.

A typical scenario goes like this. "Lecturer adds an entry for a physical book to a course reading list. Librarian checks the list and wants to know if there is an e-book edition of the book, in order to offer alternatives to the students on that course". Problemo. Having briefly asked around, it seems (somewhat surprisingly?) that there is no easy solution to this problem.

If we assume that the librarian in question knows the ISBN of the physical book, what can be done to try and ease the situation? Note that in asking this question I'm conveniently ignoring the looming, and potentially rather massive, issue around "what the hell is an e-book anyway?" and "how are we going to assign identifiers to them once we've worked out what they are?" :-). For some discussion around this see Eric Hellman's recent piece, What IS an eBook, anyway?

But, let's ignore that for now... we know that OCLC's xISBN service allows us to navigate different editions of the same book (I'm desperately trying not to drop into FRBR-speak here). Taking a quick look at the API documentation for xISBN yesterday, I noticed that the metadata returned for each ISBN can include both the fact that something is a 'Book' and that it is 'Digital' (form == 'BA' && form == 'DA') - that sounds like the working definition of an e-book to me (at least for the time being) - as well as listing the ISBNs for all the other editions/formats of the same book. So I knocked together a quick demonstrator. The result is e-Book Finder and you are welcome to have a play. To get you started, here are a couple of examples:

• Programming Perl
• No country for old men

Of course, because e-Book Finder is based on xISBN, which is in turn based on WorldCat, you can only use it to find e-books that are listed in the catalogues of WorldCat member libraries (but I'm assuming that is a big enough set of libraries that the coverage is pretty good). Perhaps more importantly, it also only represents the first stage of the problem. It allows you to 'discover' that an e-book exists - but it doesn't get the thing 'delivered' to you.

Wouldn't it be nice if e-Book Finder could also answer questions like, "is this e-book covered by my existing institutional subscriptions?", "can I set up a new institutional subscription that would cover this e-book?" or simply "can I buy a one-off copy of this e-book?". It turns out that this is a pretty hard problem. My Licence Negotiation colleagues at Eduserv suggested doing some kind of search against myilibrary, dawsonera, Amazon, eBrary, eblib and SafariBooksOnline. The bad news is that (as far as I can tell), of those, only Amazon and SafariBooksOnline allow users to search their content before making them sign in and only Amazon offer an API. (I'm not sure why anyone would design a website that has the sole purpose of selling stuff such that people have to sign in before they can find out what is on offer, nor why that information isn't available in a openly machine-readable form but anyway...). So in this case, moving from discovery to delivery looks to be non-trivial. Shame. Even if each of these e-book 'aggregators' simply offered a list1 of the ISBNs of all the e-books they make available, it would be a step in the right direction.

On the other hand, maybe just pushing the question to the institutional OpenURL resolver would help answer these questions. Any suggestions for how things could be improved?

1. It's a list so that means RSS or Atom, right?

Image via WikipediaI'm wondering, now that Atlases is a genre term (as it should be) what will the subject headings for world atlases be? Earth $vAtlases maybe?

I also just noticed the difference between topographic maps and physical maps. The later do not include any vegetation or man-made structures. Many maps with topographic in the title should get the genre term Physical maps.

The final report of the ALCTS Non-English Access Working Group on Romanization has been released.
The Working Group was established by the ALCTS Non-English Access Steering Committee in June 2009 to examine the current use of romanized data in bibliographic and authority records and to recommend whether romanization is still needed in bibliographic records. The Working Group would like to thank all who submitted comments on our draft report released in November. This input from the wider cataloging community was invaluable, and many of the comments received have been incorporated directly into the final report.The Committee considered 2 options: A) transliteration and vernacular in records and B) vernacular only in records.
A majority of the Working Group believes that the factors discussed in this report are significant enough to make a general shift to Model B in bibliographic records premature at this point. Some members of the Working Group feel that having romanized access points in records provides enough added value that their use should be continued indefinitely. Others believe that in an environment of shrinking staffs and production pressures we should anticipate future developments in making our decision and recommend a move to Model B sooner rather than later. However, most believe that although a gradual move towards the use of Model B for current cataloging is probable, we should continue use of Model A for now as we prepare for a potential transition.The committee had other recommendations as well.