« May 2006 | Main | July 2006 »
During ALA in New Orleans over the weekend I saw a workman showing the cell phone on his belt to his companion. "Twenty-five dollars. I bought one for my mother and one for my girlfriend. My girlfriend's has GPS in it. I can see where she is. I can get on the computer and see where she's been!"
From his expression, I'd be surprised if his girlfriend is aware of that feature.
--Th
Jeff offers some more insight on how to think about OpenURLs
--Th
I’m starting to figure out how to explain OpenURL to our developers without having them tune out in the first 10 seconds. My claim is that a request to any web server in existence can be modeled in the simplest of terms: what, who, where, why, when, and how. If you accept that premise, then OpenURL is a simple matter of mapping those labels to the ones defined by the OpenURL Ministry of Silly Names:
OpenURL defines various other abstractions, but these are the most relevant for now. A model based on what, who, where, why, when, and how promises a simple, intuitive way to think about any web service. There is more that needs to be said about how this model relates to OpenURL, but perhaps the key provided above offers a clue that OpenURL isn’t as complex as the silly names imply.
Jeff
Updated 2006-06-16 11:21 EDT--fixed some typos
Tim Spalding has announced thingISBN on the Thing-ology Blog. It works very much like OCLC's xISBN service that I've mentioned here several times. He also has a very interesting option that allows you to see which ISBNs thingISBN has in common with xISBN, and which ISBNs each service has the other doesn't. Obviously, with a billion holdings vs. LibraryThing's three million, xISBN has more ISBNs in it, but LibraryThing does quite well, especially for paperback ISBNs.
One of the main differences in the services is that thingISBN relies on explicit links across editions/expressions, while xISBN computes everything based on the MARC data. Of course, the MARC data has ways of bringing together (and separating) these, so maybe the difference is more an interface issue than a real one. We also go to great lengths to make sure each of the ISBN clusters is distinct, so that you always get the same cluster no matter which of the ISBNs in it is used. I talked to Tim about thingISBN, but forgot to ask him about that.
--Th
A few weeks ago I posted OpenURL 1.0 for Reptilian Brains by Jeff Young. Jeff has continued to think about this problem and has come to the conclusion that the whole world is an OpenURL resolver, it just doesn't know it (yet). Well, not quite, but here are his latest thoughts.
--Th
In a previous blog entry, I argued that OpenURL wasn't nearly as difficult to implement as people believed. My naïve belief was that programmers would eagerly embrace the potential of interoperability, as long as the barriers weren't too high. The frustration expressed in that article was the result of learning that "two lines of code" was too high a price to play for those benefits. Programmers don't care about "slightly harder"; they want "significantly easier". Most standards don't have much of a chance against this reality.
As it turns out, however, that's not the only thing I got wrong in that article. I was also wrong about OpenURL being only "slightly harder". I now believe that OpenURL is, in fact, "significantly easier". So much so, that every web service in existence is already 100% OpenURL-compatible. "But what about rft_id and url_ver=Z39.88-2004", you might ask?
What I finally realized (just this morning) is that these are artifacts of specific applications (what OpenURL calls CommunityProfiles). My narrow-minded understandings of OpenURL lead me to believe that all applications should (ideally) conform to existing URL construction patterns (what OpenURL calls Transports). I had no excuse for this prejudice. The OpenURL standard defines a registry where instances of CommunityProfiles and Transports can be defined and expanded. OpenURL doesn't dictate anything. It is merely a model to describe and (optionally) develop systems.
Think of it this way. Every web server in existence is a 100% compatible OpenURL resolver. No exceptions. In OpenURL terms, the URL construction they use to invoke their services is called a Transport. Just because no one ever bothers to register their construction in the OpenURL registry is another matter. It's not required. The point is, they could register it without changing a single line of code. The same is true for CommunityProfile, which is intended to describe the application in detail. Just because no one bothers to do this doesn't alter the fact that they could do so without changing a single line of code.
So, why was I so committed to the transports that were used as examples in the standards document? I don't know. Why didn't anyone point this out to me? I don't know.
Jeff
I spent a couple of days in Quebec City to attend the board meeting of the NDLTD in conjunction with ETD 2006.
Quebec is a lovely city, and very French. I heard as much Japanese on the streets as I heard English. My French is virtually non-existent, but it isn't too hard to tell when you are hearing someone who isn't really fluent. Listening to some of the speakers at the opening session presenting in both French and English, I was surprised that it is more pleasant to hear heavily accented English and fluent French than to listen to fluent English and heavily accented French.
I was always under the impression that Canadian French sounded strange to the French, but a Frenchman at dinner said that it was perfectly understandable and much closer to Parisian French than many of the dialects in France itself. The Candians do coin new words, though, for things the French would use English for. Ten of us went out to dinner and we had quite a mix: at least French, Slovakian, German, Swedish, Norwegian, Dutch, Scottish, and the lone American. I wasn't able to stay for the conference, but it looked like it was going to be quite successful.
I'm chair of the NDLTD standards committee. Our main goal over the next six months is to revise ETD-MS. There are several things that need to be worked on for this, some of them basic, such as getting the XML namespace for Dublin Core correct. We also want to reach some consensus on how the level (undergraduate, masters, doctoral) of a thesis should be specified, and a way of indicating the discipline of a thesis.
ETD 2007 will be in Uppsala, Sweden. I'm looking forward to it.
--Th
The screen image to the left is the actual default screen that popped up when I asked for a PDF file from the Journal of Librarianship and Information Science. The text I wanted to read is the little rectangle in the middle.
Now, it's easy to close the Sage panel, and the Pages panel in the PDF viewer doesn't need to be open, but with JLIS's border on the right, the Adobe toolbars (top and bottom) and the browser toolbars, there just isn't enough room left for a readable page. This is only going to get worse as more and more companies want to get their toolbar in your browser. I see many people's browsers now that have so many toolbars on them that even HTML pages are difficult to read. In this case, JLIS does have a 'View article in full window' link which removes their sidebar, but I didn't notice it until it was too late. Even then, with 6-8 rows of controls, tabs, banners, footers, and status lines, the page is vertically challenged (screen image on the right).
I run two monitors off my PC, both 17 inch CRTs, one at 1024x768 and the other 1280x1024 (to make it easier to evaluate interfaces). On the 1280x1024 screen, after going into full-screen mode in the browser, the page is barely readable if the full height is displayed. If the text is expanded to full width, the words are easy to read, but vertical scrolling of two-column displays is always awkward. I usually give up and print out PDF files of any length.
As an aside, I once wrote a page display system that allowed scrolling multiple columns, the text moving from one column to the next. It sounds very strange, but I found it quite easy to get used to. PDF is stuck firmly in 'page-description' mode though, which makes that sort of thing difficult to accomplish.
--Th
Thanks to Bob Bollander that suggested this was worth a post.
