> I just happened to notice that the self, next and last links in the
> Atom feed [1] are pointing at the wrong place:
-- Thanks for catching this.  They've been fixed.

As for the increasingly slow response, we'll have to look into it.  We've known about it for a while now, but we've not had the opportunity to exploer some other options.  (I just now took another look at the code and do not see any obvious inefficiencies with it so I've always assumed this would require probably a fair amount of testing to correct.)

Happily, for subjects one must only go back fewer than 30 pages before hitting resources that would be in the latest bulk download.  Names, on the other hand, is entirely separate matter (you'd have to request a page north of 5500).  One of the reasons I want to update the bulk downloads.

Thanks again for the catch.

Yours,

Kevin



> -----Original Message-----
> From: LC Linked Data Service Discussion List
> [mailto:[log in to unmask]] On Behalf Of Ed Summers
> Sent: Friday, November 02, 2012 9:54 AM
> To: [log in to unmask]
> Subject: [ID.LOC.GOV] paging urls in atom feed broken
> 
> I just happened to notice that the self, next and last links in the
> Atom feed [1] are pointing at the wrong place:
> 
> <feed xmlns="http://www.w3.org/2005/Atom">
>   <title>Library of Congress Subject Headings</title>
>   <link href="http://id.loc.gov/subjects/feed/1" rel="self"/>
>   <link href="http://id.loc.gov/subjects/feed/2" rel="next"/>
>   <link href="http://id.loc.gov/subjects/feed/4117" rel="last"/>
>   <id>info:lc/authorities/subjects/feed</id>
>   ...
> </feed>
> 
> should instead look like:
> 
> <feed xmlns="http://www.w3.org/2005/Atom">
>   <title>Library of Congress Subject Headings</title>
>   <link href="http://id.loc.gov/authorities/subjects/feed/1"
> rel="self"/>
>   <link href="http://id.loc.gov/authorities/subjects/feed/2"
> rel="next"/>
>   <link href="http://id.loc.gov/authorities/subjects/feed/4117"
> rel="last"/>
>   <id>info:lc/authorities/subjects/feed</id>
>   ...
> </feed>
> 
> The same seems to be the case for the LCNAF feed [2] as well. Since I'm
> on the subject, I've noticed that digging back in time seems to take
> longer the further you go.
> 
> ed@taylor:~$ time curl --silent
> http://id.loc.gov/authorities/subjects/feed/501/ > /dev/null
> real	0m3.193s
> user	0m0.004s
> sys	0m0.008s
> 
> ed@taylor:~$ time curl --silent
> http://id.loc.gov/authorities/subjects/feed/1001/ > /dev/null
> real	0m12.031s
> user	0m0.008s
> sys	0m0.004s
> 
> ed@taylor:~$ time curl --silent
> http://id.loc.gov/authorities/subjects/feed/1501/ > /dev/null
> real	0m15.623s
> user	0m0.004s
> sys	0m0.008s
> 
> ed@taylor:~$ time curl --silent
> http://id.loc.gov/authorities/subjects/feed/2001/ > /dev/null
> real	0m22.023s
> user	0m0.012s
> sys	0m0.004s
> 
> ed@taylor:~$ time curl --silent
> http://id.loc.gov/authorities/subjects/feed/2501/ > /dev/null
> real	0m24.492s
> user	0m0.004s
> sys	0m0.008s
> 
> ed@taylor:~$ time curl --silent
> http://id.loc.gov/authorities/subjects/feed/3001/ > /dev/null
> real	0m27.716s
> user	0m0.008s
> sys	0m0.008s
> 
> ed@taylor:~$ time curl --silent
> http://id.loc.gov/authorities/subjects/feed/3501/ > /dev/null
> real	0m46.800s
> user	0m0.008s
> sys	0m0.008s
> 
> ed@taylor:~$ time curl --silent
> http://id.loc.gov/authorities/subjects/feed/4001/ |less
> real	0m1.225s
> user	0m0.008s
> sys	0m0.012s
> 
> I'm not sure if some optimizations can be made there. I guess the
> silver lining is that Varnish appears to be caching the result, so it's
> just the first person to request the URL that has to pay the price.
> 
> //Ed
> 
> [1] http://id.loc.gov/authorities/subjects/feed/1
> [2] http://id.loc.gov/authorities/names/feed/1