 |
 |
Hi everybody, If you don't use Serial Solutions 360 Link, you can ignore this. If you use 360 Link's API, have you noticed that the behavior has changed in the last week or so (I think I first noticed last Friday when our build started breaking)? What's happening is that it's duplicating results (mostly) in /ssopenurl:openURLResponse/ssopenurl:results/ssopenurl:result. I say "mostly" because, while these are definitely referring to the same article, the metadata is slightly different in each result (one may have an ISSN, for example, or a variant publisher string). These differences are inconsistent enough to make it non-trivial to just simply de-dupe the results. Some examples: http://df7sm3xp4s.openurl.xml.serialssolutions.com/openurlxml?version=1.0&url_ver=Z39.88-2004&rft_id=info:doi/10.1038/256495a0 (from the University of Kent) http://cm7ly9cu9w.openurl.xml.serialssolutions.com/openurlxml?version=1.0&url_ver=Z39.88-2004&rft_id=10.1001/jama.1989.03430200052010 (from Brunel University) http://su8bj7jh4j.openurl.xml.serialssolutions.com/openurlxml?version=1.0&url_ver=Z39.88-2004&rft_id=10.1126/science.337.6100.1279 (from Virginia Tech) But it's not totally consistent. See: http://cm7ly9cu9w.openurl.xml.serialssolutions.com/openurlxml?version=1.0&url_ver=Z39.88-2004&rft_id=10.1017/S0261143007001250 or http://df7sm3xp4s.openurl.xml.serialssolutions.com/openurlxml?version=1.0&url_ver=Z39.88-2004&rft_id=10.1037/0003-066X.59.1.29 which only have one result each. Anyway, I'm not privy to any SerSols' mailing lists or anything (we just use the API to determine whether or not a customer holds a requested item electronically), so is there a known problem with SerSols' knowledgebase? Before I start hacking in some heuristics to dedupe these things, I'd like to know if Serials Solutions is planning on fixing this. These are major titles that it's appearing on (my examples are Nature, JAMA, and Science), so I can't really ignore it. Thanks, -Ross.