Magari un tempo sarebbe stata una fumeria d’oppio per la bella borghesia.Viene in mente questo quando si scendono le scale che portano nell’interrato dove si trova Spice Temple, locale di cucina cinese moderna ma di alta qualità, forse il meglio... Stefano Bonilli http://blog.paperogiallo.net/

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.

... e poi andiamo a cenare nel miglior ristorante di Sydney mentre piove, il vento impedisce di tenere aperto l'ombrello, fa freddo.E' l'inverno, bellezza, ti dice il tuo angelo custode stravolto dalle 27 ore di viaggio.Andiamo a mangiare sul porto,... Stefano Bonilli http://blog.paperogiallo.net/

Ho scoperto una nuova categoria di ‘cibo amico’! In realtà questa categoria l’avevo sotto il naso da tempo solo che non so perché non mi ci ero mai soffermata, si tratta dei cakes comme des pains del libro sui cakes maison di Ilona Chovancova, sfogliato mille volte eppure mai che avessi fatto una ricetta da quella breve sezione lì dedicata ai cake da usare in tutto e per tutto come se fossero dei pani. In realtà proprio dei pani non sono: più densi e più ricchi, contengono uova e yogurt e olio e sono lievitati al bicarbonato, sono però ottimi da affettare e usare come pane per panini, crostini e quel che si vuole :-) Allora siccome io volevo un superpane supernutriente e pieno di solo cose buone, ne ho inventato uno mio, che da qualche giorno accompagna colazioni, insalate e zuppe fredde e di cui sono davvero molto molto contenta :-) insomma, un finto pane tuttofare, buono e sopratutto molto molto pieno di cose buone per voi :-))

Cake integrale con ceci e alghe

farina integrale 150 g
farina di segale integrale 150 g
uova 3
yoghurt magro naturale 12 cl
acqua o latte 13 cl
olio d’oliva 7 cl
ceci lessati 200 g
misto fiocchi di alghe essicate 4 cucchiai (ho usato il misto oceano dell’Algheria :-)
semi di sesamo 2 cucchiai
lievito per dolci non zuccherato 1 bustina
sale & pepe

Sbattere le uova con lo yoghurt, il latte e l’olio. Aggiungere le farine, il lievito, i ceci, le alghe, condire con sale e pepe e mescolare bene. Versare il composto in una teglia da plumcake sui 25cm e cospargere la superficie con i semi di sesamo. Infornare a 180° C per circa 45 minuti o finché il cake è gonfio è asciutto. Io lo conservo al frigo e, già affettato (con un quadrotto di carta forno fra una fetta e l’altra), al congelatore, in modo che basta tirarne fuori una fetta e lasciarla scongelare quando serve :-)

Note: There is a print link embedded within this post, please visit this post to print it.

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

L'Australia intera poteva, almeno in teoria, essere letta come uno spartito.Non c'era roccia o ruscello, si può dire, che non fosse stato cantato o che non potesse essere cantato. Forse il modo migliore per capire le Vie dei Canti era... Stefano Bonilli http://blog.paperogiallo.net/

Eccola qui la pasta con le sarde, una di quelle ricette che tutti conoscono e nessuno mangia mai.Tutti conoscono la pasta con le sarde di nome ma poi la ricetta è un'altra cosa e al ristorante, se non si va... Stefano Bonilli http://blog.paperogiallo.net/

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

Fa caldo in modo africano anche nelle città dove l’estate di solito picchia meno.Le stagioni non sono più quelle di un tempo e altre imprecazioni di questo tipo fanno da sottofondo alla nostra vita quotidiana.Chi può vive in una bolla... Stefano Bonilli http://blog.paperogiallo.net/

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?

Avevo voglia di vedere Roma all'alba e così ieri mattina sono uscito di casa alle 5,45, complice il caldo notturno, e ho percorso a piedi le strade che durante il giorno e la sera fino a tardi sono piene di... Stefano Bonilli http://blog.paperogiallo.net/

La buona notizia è che ho quasi finito il famigerato libro (fra esattamente sette giorni dev’essere tutto chiuso, finito e buono da stampare – delle volte che a qualcuno questa notizia possa interessare, comunque prima o poi magari vi racconterò qualcosa del making off), la cattiva è che ho ancora mezza dozzina di altre cose da fare prima di andare in ferie, incluso il remake del viaggio in Savoia di due anni fa (tranne che stavolta non si tratta di macarons…). Nel mentre sbircio disperatamente alla colonnina di mercurio che non sembra aver molto voglia di tornare a indicare dei livelli di caldo che fossero anche vivibili sicché, francamente, al momento mi diverto poco e cucino ancora di meno (e mi spiace per quelli che vivono in montagna e che la sera dormono con il piumone leggero e che tutto sommato vorebbero che si cucinasse un po’ di più – hanno tutta la mia invidia :-). Insomma, rien de neuf sous le soleil – et c’est bien le cas de le dire. Questo detto, l’altro giorno l’abbiamo fatta fresca e dolce, oggi invece la facciamo fresca e salata…

Zuppa fredda di carota, cumino e yoghurt, the ricetta: Sbucciare mezzo kg di carote, tagliarle a pezzetti, sistemarli in un pentolino e coprire a filo con dell’acqua. Aggiungere un cucchiaino scarso di semi di cuino mezzo cucchiaino di semi di coriandolo, tre fili di zafferano, e lasciar cuocere il tutto per un 10-15 minuti finché le carote non caranno morbide. Frullare, salare e pepare e lasciar raffreddare. Quando la zuppa sarà fredda, aggiungere 3dl di yoghurt magro naturale, e allungate se serve con poca acqua in modo da rendere la zuppa bevibile al bicchiere. Aggiustare il condimento e tenere al fresco per diverse ore prima di servire.

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.