Friday, February 4, 2005

Getting the OpenURL Referrer to work; Firefox extension design issue #

I worked with Thomas Ventimiglia of Openly Informatics, Inc. to debug Openly's OpenURL Referrer, a Firefox extension for inserting OpenURLs into Google Scholar search results. Our consultation resulted in Tom's tracking down and implementing two bug fixes:   1.0.8 (1/28/05): Fixed bug involving Empty Profile Name Box/Error when creating new profile   1.0.9 (2/3/05):  Fixed bug involving namespace conflicts with other FF Extensions                            Special thanks to Raymond Yee and Richard Silverstein for helping us identify this elusive bug! The basic problem was that the OpenURL extension was conflicting with another extension that I had previously installed (copyurlplus, to be exact). The initialization routines for both extensions were named the same. So apparently, because copyurlplus had been installed first, the OpenURL extension ended up calling the initialization routine of copyrurlplus! The workaround, in Tom's words: "The solution was to package all of our functions and global variables in a uniquely-named object that would not collide with anything in another extension's namespace." He then pointed me to Coding For Portability, Part 1 » Thirteenth Parallel for further explanation. I had been wondering about the interaction model among extensions, and had naively thought that extensions would have their own namespaces and that there was a very well-controlled model of interaction. This bug that Tom and I worked on shows that I was wrong. Should we be concerned? I think so. Now that we have had a taste for this problem, a quick google search on "firefox extension namespace" shows that at least one other person has run into the same issue: Mark Bokil reports at Microsoft's Peter Torr Attacks Mozilla Firefox Security - MozillaZine Talkback: I feel there are some serious design issues with the way extensions are currently implemented. I came across some problems while writting two extensions so here are my observations of the current extension development method: [....] The problem I see with this ad hoc method is design standards. While writting extensions I ran into problems where I would create a global variable or name an extension method a certain name and my extension would stop working. After some head scratching I figured out that the main content window and my extension variables were all in the same namespace or scope. [....] What I started to do was to wrap my extension in a Javascript object and then refer to my variables and methods using my domain name to create a unique memory namespace. So my variables look like markbokil-org.settingOne or methods look like markbokil-org.getMenuxOptionsPanel(). Possibly Ben Goodger could add to this discussion or a rep. from mozilla.org could chime in here for a community discussion in the forums. No answer yet.   Posted by Raymond Yee on 2/4/05; 5:26:42 PM from the Unclassified dept. Discuss

Notelets for 2005.02.03 #

For those of us who love the trees on the UC Berkeley campus, go read: 1.26.2004 - Going out on a limb for Berkeley’s venerable trees: "Take away the lecture halls, the brilliant students, the Nobel laureates, even take away the Campanile and the tie-dye, and there'd still be a unique feel to Berkeley. Where to find it? Try the trees." I decided to subscribe to the Code4LibList. I wonder how the OCLC's Recombinant Catalog Metadata Project went. I've been using Paintshop Pro version 9. There is Python based scripting available in PSP. But can I invoke PSP from an external Python script? Maybe says Python scripting with Paint Shop Pro 8.0. But instead of messing PSP programming, maybe I should stick with getting back to Python Image Library. If I ever have to read MARC with Python, I'll look at textualize: pymarc: The pymarc module provides an API for reading, writing and modifying MARC records from python. MARC (MAchine Readable Cataloging) is a metadata format for bibliographic data. The New York Times > Technology > Circuits > When the Sous-Chef Is an Inkjet: But the sushi made by Mr. Cantu, the 28-year-old executive chef at Moto in Chicago, often contains no fish. It is prepared on a Canon i560 inkjet printer rather than a cutting board. He prints images of maki on pieces of edible paper made of soybeans and cornstarch, using organic, food-based inks of his own concoction. He then flavors the back of the paper, which is ordinarily used to put images onto birthday cakes, with powdered soy and seaweed seasonings.   Posted by Raymond Yee on 2/4/05; 12:23:51 PM from the Notelets dept. Discuss

Something to aspire to in our software #
Lorcan Dempsey's weblog: A Hullistic approach: They support the general emergent pattern, which sees recombinance of finer grained service elements across library, learning and admininistrative environments. Of course, this is something that is yet only intermittently supported in our applications.   Posted by Raymond Yee on 2/4/05; 12:20:57 PM from the Unclassified dept. Discuss

Disciplinary perspectives on scholarly communications #

Clifford Lynch wrote Mailing List CNI-ANNOUNCE@cni.org Message #112953: Last week, the University of North Carolina at Chapel Hill held a two day convocation on the changing shape of scholarly communications in the digital world. I was fortunate enough to be able to attend part of the meeting. As background for the convocation, a number of members of the campus community developed white papers to help inform the discussion. These include a number of superb and rather unusual papers written by faculty and taking a very valuable disciplinary perspective on the evolution of scholarly communication. These papers are available at http://www.unc.edu/scholcomdig/ I learned a great deal from reading these papers, and I believe that they may be valuable not just to readers interested in scholarly communications developments, but perhaps specifically as resources and sources of ideas for other institutions planning similar campus-wide discussions.   Posted by Raymond Yee on 2/4/05; 12:18:42 PM from the Unclassified dept. Discuss

A metadata moratorium? #

Yesterday, I  read Is It Time for a Moratorium on Metadata? by Dick Bulterman. Fun read and good description of the current limitations of metadata schemes, especially for non-textual objects. There's a lot more to say than what I can do here. And a lot more to ponder, especially since I've been in the business of creating tools (like the Scholar's Box) that manipulate metadata. I like his "personal back-to-basics definition of metadata": "Optional structured descriptions that are publicly available to explicitly assist in locating objects". "Now, 10 years later, I’m not sure we’ve learned much that's new about using metadata to locate generalized media except that metadata in the context of electronic processing is probably not nearly as useful as it was in conventional library catalogues." "For nontext data—such as video, images, audio, and so on—direct mining is difficult, but exactly at the point that metadata might be useful, manual creation simply doesn’t get done because creating useful metadata descriptions (the proverbial thousands of words) is not in the critical path of content creation." The author does a good job at listing problems with automatic metadata generation systems. I can testify that it's hard to get good automatic metadata after working hard to get it from my own Treo600Phone. "it is totally unrealistic to expect that the devices’ users will spend any time thinking up descriptive filenames or adding extensive captions: They’re too busy taking new pictures!" I know that Marc Davis is hard at work to change this situation -- and I'm curious to know the state of the art with respect to metadata generation with video and images. See  DigiLib: University of Groningen: Moratorium on metadata, another analysis of Bulterman's article.   Posted by Raymond Yee on 2/4/05; 12:13:03 PM from the Unclassified dept. Discuss