 |
 |
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 > knowledgebase. > > 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 > -- > ---------------------------------------------------------- > Kyle Banerjee > Digital Services Program Manager > Orbis Cascade Alliance > [log in to unmask] / 541.359.9599