It's an excellent point. The resolver's knowledgebase needs to know
which issn a vendor has bundled content under, and ideally will be
able to access that content no matter the issn/eissn in the OpenURL
metadata. I'm thinking of a particular vendor that uses issn in the
url syntax, but without a knowledge, it's hard to predict which issn
is the one they use!
On Feb 29, 2008, at 8:38 AM, Kyle Banerjee wrote:
> I agree; issn is not an identifier for an article. But in general, a
> resolver should be smart enough to know what serial is meant even if a
> variant issn is supplied.
> To prevent multiple searches, the resolver has to know how a title is
> referenced in the target source. This requires precalculation using a
> service or data file like xISBN that included ISSNs. However, it is
> important to keep in mind that sources such as the library catalog
> sometimes require multiple ISSNs to retrieve all holdings data unless
> this information is combined before it is loaded into the resolver
> Between cataloging rules that influence how serials are issued
> (specifically, the practice known as "successive entry cataloging"
> which spreads individual titles across multiple records because of
> piddly variations in issues) and things that occur at the publishing
> end of things, many journals are known by multiple ISSNs. Practices
> like these are not user friendly -- even reference librarians don't
> seem to understand them -- so database providers typically combine all
> the issues so they can be considered part of one unit. Vendor provided
> data about such titles will likely include only one of these ISSNs
> (most likely, the most recent one, but that is not guaranteed).
> Unlike vendors, catalogers can be counted on to spread the holdings
> statements across multiple records and ISSNs if the cataloging rules
> so prescribe. This may sound like cataloging minutia, but this dynamic
> affects a number of very popular titles. Resolving only one ISSN could
> easily lead people to think an issue they need is not available when
> it is on hand.
> Kyle Banerjee
> Digital Services Program Manager
> Orbis Cascade Alliance
> [log in to unmask] / 541.359.9599