| <[ back
]
Article
level — Z3950 Plug-In
This is an SFX plug-in that does
a real-time search of your catalog,
parses your journal holdings, and makes
a determination of local print availability
for a journal article directly on the
SFX server.
Since it is somewhat system
dependent, I currently have scripts
for Innopac and Voyager catalogs, with
more to come.
Download
Each .zip file contains a test script
and a plug-in. The test script has
the .pl extension and the module has
the .pm extension. For example: chameleon_innopac.pl
(test script) and chameleon_innopac.pm
(plug-in).
Questions about the
script and plug-in
What is a plug-in?
Plug-ins are Perl modules that
SFX can use as a sort
of "dynamic threshold" for a variety
of different targets. Ex Libris provides
basic plug-ins for title-level searches
of your catalog for both Aleph
and Z3950-compliant catalog systems.
But you can create and use your own
plug-ins for many other purposes.
Plug-ins are described in more detail
in the SFX
documentation.
Will this plug-in
work for me? It depends. The plug-in has to be able to parse and
make sense out of your journal holdings. Clearly, the idiosyncrasy of holding statements from
institution to institution makes a one-size-fits-all
approach simply impossible.
However, many instituions use a similar
pattern, which I will describe here
as the common
holding pattern. If you write
your holdings like these examples:
1:1(1970)-10:12(1979), 12:1(1981)-
vol. 1 iss. 1 (1970) - vol. 10 (1979),
vol. 12(1981) - to the present
v.1 (1970: Jan) - v.12 (1979: Dec)
. . . or some other variation like
these, the plug-in will most likely
recognize your pattern. The real key
is to have (a) the year inside of parentheses,
and (b) dashes and commas separating
each group of ranges. If you have something
like that, you're golden!
If you do use the common holding pattern,
the
plug-in should work more or less out-of-the-box
if you also (a) have one of the catalog
systems described above, and (b) place
your holding information in holding
records, rather than in the bib record.
If you express your holdings in a
different way, or you put holdings
in the bib record, or have a system
not included already, see the next
two points below.
What if I have a
different catalog system, like Aleph?
I'm hoping to make (or
have others contribute)
working plug-ins for other systems.
What
if my holdings are different from
the common holding pattern?
The module simply looks for patterns
(regular expressions).
It is not at all impossible to re-write
the regular expressions to account
for a different pattern, or to look
for the information in the bib record
rather than the holding record (or
both places), or any number of other
factors that make your holdings unique.
If your holdings are different,
find someone at your institution who
can write (or can learn to write) Perl
regular expressions, and then
share your work with the rest of
us. Send
them to me, and I'll post them here.
The key is consistency. As long as
your statements are consistent, it's
relatively easy to parse and make sense
out of them, no matter how they are
written.
What if my holdings
are not consistent?
Don't worry, no one's holdings are
totally consistent. The plug-in is
purposely designed to be forgiving,
covering a multitude of sins -- hence
the reason why it only attempts to
get down to the year level, rather
than shoot for the moon with actual
volumes and issues.
The real problem is if you have more
than one method for how you holdings
have been expressed -- most likely
because you changed schemes
sometime in the past, but still
have records that were never converted
to the new scheme. It is rather difficult
to write regular expressions to account
for both formats.
If you have no consistent scheme at
all for expressing your holdings,
you've got bigger problems. Go take
care of those first and deal with
this later. :-)
What is the test script?
If you want to give this thing a go,
first download the appropriate test
script. This will allow you to try
out the plug-in without having to
create a new catalog target in SFX.
It also gives you some idea of how
the plug-in works by printing out
its processes to the terminal screen.
This makes troubleshooting much easier.
Once you download the file, edit it's
Z3950 server information so that it
points to your catalog's Z3950 server.
FTP the test script to your SFX server.
For testing purposes it can go almost
anywhere, but I like to keep it in the
[your_instance]/lib/Parsers/PlugIn
directory, since that is where the plug-in
must ultimately live.
Telnet over to your SFX server, and
make your way to that same directory,
using:
sx
cd lib/Parsers/PlugIn
Type:
perl chameleon_innopac.pl
. . . or whatever the script is called.
This will invoke the Perl interpreter
which will get the script running. The
script itself will then ask you for
an issn and year. Type those in, and
see what it does. Hopefully you'll see
something like this typical
print out.
It's a bit cryptic, but makes more
sense if you understand how
it works.
What is the functional
plug-in?
The test script is obviously just
for testing purposes. Your users won't
actually see all that -- they won't
see anything at all except a link to
the catalog if it finds a match. The
functional plug-in is the real deal,
the thing you will want to test next
after the test script.
Once you download the plug-in (it's
the .pm file), edit
the file's Z3950 server information
so that it points to your catalog's
Z3950 server.
FTP the file to the [your_instance]/modules/parsers/PlugIn directory. In the SFX Web admin interface,
create a new local_catalog_testing target
based on your current catalog
target. In the threshold field type in:
$obj->need('ISSN') && $obj->plugIn(chameleon_innopac)
.
. . or whatever the module is called.
Note that you don't include
the .pm extention here.
If you are
already live with SFX, you may not
want to show this new link to the world.
You can include
a threshold that only allows your
IP address to see the target. Yours
would look like this:
$obj->iprange('38.103.63.62')
(This
assumes that your institution doesn't
assign you a new IP address each time
you log-in, or at least DHCP is not
too quick to assign you a new one.
We get reassigned our previous IP address
as long as we log back in within a
week, so I find this threshold useful.)
Will I need to make changes to the
module?
Yes.
Besides tweaking it for your institution's
holding statement patterns, there
is another major component that the
script does not account for: rolling
statements like "Latest year only"
or "Latest 2 years." You can use the $YEAR variable
in the scripts to do some of this
work, and there is a decent example
in the code.
It is here more than anywhere else
that you will probably want to get
your catalog "cleaned-up" to standardize
the myriad ways staff might express
such statements.
How
it works
(1) A user clicks on an SFX button,
sending to your SFX server an ISSN and
a year (among other information).
(2) The main SFX program will pass
that information to this "Chameleon"
plug-in, which will in turn query your
catalog based on the ISSN. If found,
the catalog will return one or more
records. By requesting the records in
'OPAC' format, most catalog systems
will also attach holding records together
with the bibliographic record.
(3) The Plug-in will extract the summary
holding information, boil-down the
holding statements into a series of
date ranges, and then compare the
article's publication year against
the ranges. If the publication date
falls between any one of the date ranges,
it will return a '1' to the main SFX
program, instructing it to show a link
to the catalog. If not, it returns
a '0', telling the program not to show
the link.
|
