I wasn't making an argument particularly for standards to solve all the problems of recording serials holdings, but rather wondering if there was common ground between vendors for forming a standard for recording holdings in a machine parsable format. No doubt this wouldn't give us perfect systems, but it would tackle the issue that Ross raised about the risk of putting print holdings into current Link resolvers.
I would agree that there are certain problems that are not going to go away (and believe me I in no way over estimate the ability of Content Providers to give us good data - that was one of the real benefits of outsourcing electronic journals data to other people - we didn't have to deal with the vagueries of reports from Content Providers any more).
I wonder how good our machine parsable holdings have to be? In general the broad brush approach of stating a holding (we have everything published in this journal since 1985) works quite well for e-journals. Although there can be 'missing issues' this is less likely with e-journals, so, if you record 'everything since 1985' in general there isn't the need to add exceptions to that.
On the other hand with local holdings of print journals, I guess missing issues are going to be slighly more common, and perhaps this increases the need to deal with easily stating exceptions, missing issues, etc. But I think there are some questions to be answered here about value for money.
We've also got to be realistic about the information we get from OpenURLs - this is not always complete, and especially with odd issues/supplements etc. can be problematic. By far the best indicator is the year of publication, as we can easily say 'if it was published anywhere in this journal, during this year, it is available', and this can also easily be measured automatically, and the amount of metadata needed is minimal. Of course, I'd be naïve to think this solved all our problems - I'm just trying to think around the realities of the environment we are working in. Even if we have some way of stating exceptions (everything since 1985 except vol 22, issue 3, in 1990), then will the metadata we get from an OpenURL be good enough to measure this?
I know I keep posing questions at the end of these discursive emails, but I still don't feel that we've got to the bottom of where we should be going here:
Do people agree that we should be trying to express holdings in a machine parsable format? (I know that I've got a yes from Ross and Jonathan on this - so perhaps I should be asking, does anyone disagree, and if so, why?)
How specific does the machine parsable bit need to be? (just thinking here, as a compromise could we have a broad brush machine parsable statement, and a more detailed human parsable statement where we want to be completely, 100%, accurate?)
I'm still interested in the fact that some sites have gone to some length to be able to bring 'print' holdings into their link resolvers menus by writing code etc. rather than putting the print holdings directly into the link resolver - although I take the point that in MFHD you can express the exact details of your holdings more accurately, is it really less work for us, and our users, for us to grab this holdings data from our ILS on the fly, rather than duplicate data entry in the two relevant systems? (Witness the work and difficulties described in getting print holdings into the Umlaut menu - wouldn't it have been easier (possibly cheaper?) to just enter the details in the link resolver?)
One of the ingenious things about link resolvers is that they recognise most of the time the user isn't interested to know if we have some parts of a journal, but whether we have the part they are looking for at that moment. Perhaps in our print holdings we have sacrificed functionality (for the user) for completeness?
Owen
-----Original Message-----
From: Next generation catalogs for libraries [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Eric Hellman
Sent: 12 September 2007 17:48
To: NGC4LIB_at_listserv.nd.edu
Subject: Re: [NGC4LIB] Link resolvers as loosely coupled systems for holdings?
On Sep 12, 2007, at 4:41 AM, Stephens, Owen wrote:
> Is there any uniformity to how existing commerical link resolvers
> handle
> this? Do they (as with SFX) generally work on a broad brush
> approach or
> do any of them make serious attempts to tackle the issues (excuse the
> pun) of missing issues and extra supplements etc. (and how much detail
> is required in a holdings statement?) Are there any standards either
> inside or outside the library sphere that we should be looking at?
> (Anyone familiar with ONIX for Serials - does any of this cover this
> area?)
Owen,
There are lots of issues associated with, for example, missing issues
and supplements, and a great variation among vendors. For example,
there is a popular vendor that doesn't even try to consider journal
enumerations in their knowledgebase, let alone consider supplements
and missing issues.
Knowledgebase vendors like us are to some extent at the mercy of
content providers to provide accurate holdings statements. A common
problem is that a supplement has no representation online, or perhaps
an ejournal which the provider represents as having fulltext online
has only the abstract of supplements online. Less common is the case
where a supplement (either print or electronic) contains only
abstracts of a conference and the abstract gets indexed as if there
is fulltext somewhere. In this case, the link server has performed
perfectly but there is user disappointment. Content providers often
do not report that the e-Version is missing supplements. When
supplements are present, they often link differently than non-
supplements. We strive to make these links work where ever possible
(I'm sure other vendors do the same) but there are some provider
sites that handle supplement linking poorly- we do the best that we
can. Supplements also tend to have non-standard page and issue
numbering which can lead to a higher incidence of transcription error
in the indexing and citation information chain.
Missing issues can strain the representational ability of
knowledgebases- in ours these are handle using multiple records for
continuous spans, but the more serious difficulty is that sometimes
new issues are not sequentially mounted due to provider production
flows. This can result in an issue being missing one week and found
the next. Provider process quality is not always as good as you might
hope (always seems to be humans in the chain, and dang if they don't
sometimes do stupid things) and sometimes issues get missed.
Standards are designed to help, but it is a mistake to look to
standards to solve your problems, especially the hard ones. A vendor
that relies completely on standards for interoperability is a vendor
who does a lot of blaming other people for not following or
implementing standards. More important in the world of electronic
information is the engineering of the the support process and
infrastructure. Problems in linking of electronic information will
ALWAYS occur, so vendors need to build their systems to efficiently
capture problems, fix the problems, and to implement the fixes. Take
a look at the tools you use that don't work as well as you would
like. Chances are, there will be no way for an end-user to report a
problem. Do you think that's a coincidence?
Eric
Received on Fri Sep 14 2007 - 03:00:02 EDT