Stephens, Owen wrote:
> 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.
There are several, yes. I am particularly enamored of the new ONIX
standard for Serials Coverage. While it is originally intended/presented
as a standard for 'electronic' serials coverage, to my reading it would
work wonderfully well for any medium of serial coverage. Certainly much
better than what most of us have now. It _does_ cover 'missing issues'
and such, don't think because it's called 'electronic' it only takes the
broad-stroke approach that most of our link resolver software takes.
Here's a blog post I wrote about the ONIX standard:
http://bibwild.wordpress.com/2007/06/21/onix-for-serials-coverage/
Meanwhile, there are several other standards efforts going on too, as
well as the existing standards (Z39.71; MARC Holdings), which have not
served us very well so far.
Jonathan
> 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
>
>
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
Received on Fri Sep 14 2007 - 07:54:18 EDT