URL maintenance in WebPAC (Innopac)

[Dave Binkley]

Darryl:

When I was at Simon Fraser we (ie Jack Rogers) had III generate a report of items
with 856's which I passed through a perl script for cleaning and formatting, and
then on to a shareware link checker on a Solaris box.  It worked fine, but the
link checker we were running was so slow that the job didn't complete overnight.
I'm not sure if they ever replaced the link checker with a more efficient one.

Would make a lot more sense if the ILS did it's own link validation.

Dave

Darryl Friesen wrote:

> > How are you maintaining the integrity of your OPAC's links (if applicable,
> > in the 856 field) to journal titles? (Btw, we're using Innopac's WebPAC.)
>
> Right now, we're not.
>
> > Sheryl Dwinell's comment hits the mark: "It would be nice if our catalog
> > vendors could develop some methodology for checking links within the
> > database rather than having up jump through all these hoops to do so."
>
> Sure would.
>
> One of the (future) projects on my list is URL validation.  I haven't started
> yet so I can't really say how it's going to turn out, but my thinking so far
> is to use something like Expect (on our Unix machine) to automate the process
> of doing a create list of records with 856 fields, selecting some useful data
> from that list, FTPing the results back to the unix machine, then having a
> program (Perl script using the LWP modules) check the links and create a some
> kind of status report.
>
> As a somewhat related project, we're planning on building a database of
> resources (local and remote databases, ejournals, pathfinders etc) from which
> we can automate the generation of many of our current web pages.  For
> resources such as E-Journals, I'd like to see the 856 in the catalog point not
> to the actual resource, but to some intermediary "page" -- either a static
> page generated from the above database, or a live database query (somewhat
> similar in concept to a PURL, I guess, in that the URL in the 856 should never
> have to change; all changes occur in the resource database).  This has the
> added advantage of allowing us to provide additional information to our
> patrons (like notes on the resource's coverage, information about vendor
> restrictions, such as username/passwords, IP restrictions  etc) before they
> get there.
>
> As I said, neither of these projects are currently more than incoherent
> scribbling on my white board.
>
> - Darryl
>
>   ----------------------------------------------------------------------
>    Darryl Friesen, B.Sc., Programmer/Analyst    Darryl.Friesen at usask.ca
>    Consulting & Development                     http://gollum.usask.ca/
>    Department of Computing Services                 163 Murray Building
>    University of Saskatchewan                              Main Library
>   ----------------------------------------------------------------------
>   "The Truth Is Out There"

--
Dave Binkley
Systems Librarian, Trent University
1600 West Bank Drive, Peterborough, Ontario
CANADA   K9J 7B8
dbinkley at trentu.ca
Tel: 705 748 1682    Fax: 705 748 1315