The thread below was forwarded to me from the NGC4LIB mailing list.
May I draw to your attention the work of the NISO/EDItEUR Joint Working
Party for the Exchange of Serials Subscription Information?
The JWP has been working on ONIX for Serials message formats, which would
seem to fill some of the needs that are discussed below. In particular,
the ONIX for Serials Coverage statement is designed to be a
machine-parsable XML structure for transmitting holdings or coverage
information. This structure has been developed with input from libraries,
publishers, subscription agents, online information providers and vendors
of library systems.
There is some background information at
http://www.niso.org/news/SerialsExchange.html, and very complete
information about the ONIX for Serials messages at
http://www.editeur.org/onixserials.html.
EDItEUR welcomes feedback on the ONIX for Serials formats. Some of the
messages are still in the pilot stage, and organizations are encourages to
review and test them. Please send comments, questions and suggestions to
EDItEUR at brian_at_bic.org.uk.
Yours,
Kathy Klemperer (for EDItEUR)
>---------- Forwarded message ----------
>Date: Fri, 14 Sep 2007 10:00:53 +0100
>From: "Stephens, Owen" <o.stephens_at_IMPERIAL.AC.UK>
>Reply-To: Next generation catalogs for libraries
><NGC4LIB_at_listserv.nd.edu>
>To: NGC4LIB_at_listserv.nd.edu
>Subject: Re: [NGC4LIB] Link resolvers as loosely coupled systems for
> holdings?
>
>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
================================
Katharina Klemperer, MLS
Library and Information Systems Consulting
37 Minuteman Rd.
Acton, MA 01720 USA
office: 978-266-1776
mobile: 978-590-6021
kathy.klemperer_at_verizon.net
Received on Wed Sep 19 2007 - 14:52:06 EDT