Friday, February 6, 2015

Link Resolution Quirk in ATSM Journals (Resolved)

ATSM have fixed this issue (see postscript)
No great drama here, just thought this might interest people who get frustrated with Link Resolvers but don't know who to blame.

This issue reported by a staff member who, using Summon, got a 360 Link to:

Zhang, F., Guo, S., & Wang, B. (2014). Experimental research on cohesive sediment deposition and consolidation based on settlement column system. Geotechnical Testing Journal, 37(3), 20130054. doi:10.1520/GTJ20130054
Which demanded payment (add to Cart and pay $25.) for an article we have subscription access to:
Our sub was active in 360 and you can browse to the article from the eJournal portal and get access. What the heck is going on?

What's Going On?

360 Link resolves to:
so it's clearly going through EZproxy.
Browsing from the ejournal portal you get this URL:
i.e. SUBSCRIPTION in the exact same path inserted after the domain name.

So why the different URLs for the same article?  I'm assuming the ATSM platform has been set up so that objects in the SUBSCRIPTION directory get an IP range check to see if you have access.  But for public access to abstract and sales they have cloned everything but the PDF into a DIGITAL_LIBRARY folder in root and have set up the DOI to point at that rather than have the DOI point at IP restricted pages.
From previous experience 360 Link DOI via CrossRef overide any OpenURL 2 publisher conversion scripts that 360 Link might have.

So ASTM's solution is pragmatic and unsophisticated - and hamstrings our users coming from any source other than the journal TOC.

I've submitted a request to Proquest for any workaround they can implement. I thought maybe parsing the DOI and inserting the SUBSCRIPTION folder in the path - but that assumes that 360 Link plays any role in handing the DOI link back to the client. I guess another option is for Proquest to add ATSM to their list of IEDL publishers.

If only there was only one publisher platform for ejournals.


I noticed in my endless rechecking of red flagged jobs for follow up that ASTM have fixed this issue by coding a check of the requester's IP address and if it matches a subscriber prompting the user whether they wish to access the full text under that subscription:
The subscriber name in our case looks like it's come from a very old registration with OCLC/NLA but that's a job for another day.

It works the same via the link resolver as it does just doing a straight resolution (so the 360 Link helper frame isn't causing an iframe conflicts).

I don't know if logging a request through Proquest had any impact as neither Proquest or ASTM have contacted me. But happy to close the job.