 |
 |
>> 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