Incidentally, this "what do you do with an identified article of
interest, after you've already identified it as of interest" question is
what my Umlaut software is focused on. And Umlaut can be used with
Summon (at least if you run your own front end--and quite likely even if
you run the standard SerSol hosted front end, since it's designed to
work with a link resolver, which Umlaut is). As well as with various
other software.
One shortcoming though is that Umlaut can really only do this on an
individual article basis, essentially on an article (or book or other
citation) 'detail' page. This is both because of the architecture of
Umlaut, and the architecture of the software used for 'search' that we'd
want to integrate with Umlaut. Even hosted Summon will likely give you
a way to click per-hit, and get an Umlaut page -- but probably won't
give you a way to add info to the results list page itself. And even if
it did, the nature of what Umlaut is doing (and the other software it
has to interact with to do it) makes it hard to do it quickly and
efficiently enough to do it for multiple articles at a time.
But in general, I'm of course not dis-interested, but I think Umlaut is
potentially very useful software for just this issue -- regardless of
where the user does a search (Library catalog, licensed database, free
web resources), delivering them to licensed full text,
institution-specific services, and licensed related content about items
of interest identified. That's what Umlaut is for. Here are some example
Umlaut pages as deployed at my institution:
http://findit.library.jhu.edu/go/117878
http://findit.library.jhu.edu/go/118223
http://findit.library.jhu.edu/go/54757
Jonathan
Karen Coyle wrote:
> Eric Lease Morgan wrote:
>
>> Finally, after creating the index, either through Summon or something
>> else, go beyond the service where you limit yourself to search and
>> find. The next step is to provide services against the returned items.
>> Figure out ways to make the content more useful. "Save the time of
>> reader" through compare & contrast, print, save, trace citation, trace
>> idea, make word cloud, graph, translate, summarize, rate, rank,
>> review, annotate, etc. [5]
>>
>>
>
> Exactly, and this is where I think we still aren't putting enough
> energy. Searching is not the hard part (takes lots of hardware, perhaps,
> and a bunch of contracts, but it's essentially mechanical). What is
> hard, and is also IMO more useful, is to create navigation of documents
> and evaluative tools. I rarely come across something new and interesting
> by doing a search. It's what I do with the result set, and where the
> data can take me, that really matters. So a service like Summon can take
> care of that mechanical part and save libraries the effort, but it's not
> a "solution" -- it's a search. Nothing to sneeze at, but we should see
> it as a foundation, not a full edifice.
>
> kc
>
>
Received on Fri Jun 19 2009 - 15:26:41 EDT