Jonathan,
Here are a couple of samples of what we are doing. In essence it uses
the Aleph api to pull metadata that is needed to determine which map to
show, such as call number, collection code, sublibrary, etc.:
http://www.library.nd.edu/eresources/getit/getit.cgi?doc_num=002237500
http://www.library.nd.edu/eresources/getit/getit.cgi?doc_num=001875072
You can see that we are providing thumbnails which can be expanded by
clicking on the link below them to see the full map. For our main
library, we have floor maps, for many of our branches, we only have a
campus map to the library - most of the branch libraries are on the
smaller size, one or two floors.
We haven't quite decided on the final shape of this yet - we're hoping
to launch in a few weeks and we are collecting feedback as we speak.
The service will likely be enabled from a button in our catalog called
"get it" or something similar - you can see the supplementary services
on the menu. The maps are actually provided from a simple api to the
getit service, so integrating this into something like Ross' Umlaut
project would be relatively easy. Ross is always doing interesting things!
Here's a sample output of the api:
http://www.library.nd.edu/eresources/stacks/stacks.cgi?call_number=QA%2076.73%20.P22%20T57%202001&function=xml
You'll notice that it provides a URL to the map as well as to the image
(this is what we use for the thumbnail).
I agree with your thoughts about the link resolver and its position in
academic research tools. One of our next steps will be to see how
something like this can interface with our link resolver (we have SFX).
Again, the tricky part is that to get the correct map, we need the call
number, the sublibrary, e.g. main, engineering, etc., and a collection
code - the citation indexes don't provide any of these things - they are
only in the catalog, so we would likely need to investigate a mash-up
tool like Ross' Umlaut that would pull the data from the catalog in
advance. All of this data we can grab from the Aleph api because it is
pretty robust.
Some of the flash projects out there that people have been sending to
the list look really nice! We'll have to think about those for the future.
Regards,
--Mark
Mark Dehmlow
Electronic Services Librarian
Electronic Resources and Serials
Access Department
115A Hesburgh Library | mdehmlow_at_nd.edu
University of Notre Dame | voice: (574) 631-3092
Notre Dame, IN 46556 | fax: (574) 631-6772
Jonathan Rochkind wrote:
> Mark, that sounds interesting. Does it deliver an actual graphical map
> to the user, or just textual directions?
>
> Many of those 'experimental' services you talk about are in fact similar
> (or identical) to services included in Ross Singer's Umlaut link
> resolver front end, which I am now working on too for adoption here at
> Hopkins. (http://umlaut.library.gatech.edu/umlaut ; and
> http://www.oclc.org/research/announcements/features/umlaut-about.htm )
>
> To me, it makes some intuitive sense to house these functions inside the
> link resolver, as the link resolver can be thought of as the list of
> 'what can I do with/about this known citation'. It is increasingly the
> first point-of-contact a user has with library systems, from the outside
> world, for a known citation. For instance, Google Scholar and
> worldcat.org will both direct users to your link resolver for citations
> for known item _books_ (ie monographs), not just article citations.
>
> Regardless of where the functionality is housed in a technical sense, I
> think those kind of services need to be available both from the link
> resolver menu AND from the catalog. The way I hope to do this is
> essentially by putting parts of the Umlaut link resolver menu on catalog
> pages.
>
> Ross Singer did a great job with starting up Umlaut, I'm trying to help
> lay some good foundations to make Umlaut something which can be easily
> adopted by other libraries, with somewhat lower tech expertise/resources
> than the 'early adopters' (or Ross, the original inventer!) needed.
>
> Jonathan
>
> Mark Dehmlow wrote:
>> At Notre Dame, we've managed to link people to the floor level - it's a
>> start, at least they don't have to go to another URL to find the floor.
>> Doing this at the shelf level is a bit of a different creature. We hope
>> to go live with this in a couple of weeks. It's tied to a service we
>> are calling "Get It" at the moment. It includes links that pre-fill
>> document delivery requests for faculty, and some experimental services
>> with reviews from Amazon and looking up the author in Open WorldCat.
>>
>> The Map/LC parsing had some nuances, but was manageable. Essentially
>> we're just looking at a simple MySQL database and some PERL scripts.
>> The trickiest part was incorporating all of our different locations,
>> such as branch libraries. So the script can just take a call number and
>> find something in the main library or it can take a call number and a
>> separate library location. We also had to accommodate the situation
>> where a single item might be available from multiple libraries (e.g.
>> main library, engineering, etc.) This happens often enough. So the
>> script can take multiple queries in a single URL.
>>
>> I am happy to share what we've done offline if anyone is interested.
>>
>> Regards,
>>
>> Mark Dehmlow
>> Electronic Services Librarian
>>
>> Electronic Resources and Serials
>> Access Department
>>
>> 115A Hesburgh Library | mdehmlow_at_nd.edu
>> University of Notre Dame | voice: (574) 631-3092
>> Notre Dame, IN 46556 | fax: (574) 631-6772
>>
>>
>>
>>
>>
>>
>> Joe Ryan wrote:
>>> Hello,
>>>
>>> We are considering building a dynamic book stack map application,
>>> linked
>>> to our catalog, that would show a color-coded map of what region of the
>>> stacks a given book is in.
>>>
>>> I am writing to see if anyone here has seen or developed any dynamic
>>> map
>>> applications used for library stacks. I'd like to see some examples for
>>> some inspiration, and I'd like to hear about any experiences that
>>> you've
>>> all had when building these applications.
>>>
>>> Thank you,
>>> Joe
>>>
>>> --
>>> Joseph Ryan
>>> Digital Projects Librarian
>>> NCSU Libraries
>>> (919) 513-0346
>>> joseph_ryan_at_ncsu.edu
>>>
>>
>
> --
> Jonathan Rochkind
> Digital Services Software Engineer
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886
> rochkind (at) jhu.edu
>
Received on Sun Aug 12 2007 - 13:31:26 EDT