 |
 |
So, in a what is probably a vain attempt to put this debate to rest, I created a partial redirect PURL for sudoc: http://purl.org/NET/sudoc/ If you pass it any urlencoded sudoc string, you'll be redirected to the GPO's Aleph catalog that searches the sudoc field for that string. http://purl.org/NET/sudoc/E%202.11/3:EL%202 should take you to: http://catalog.gpo.gov/F/?func=find-c&ccl_term=GVD%3DE%202.11/3:EL%202 There, Jonathan, you have a dereferenceable URI structure that you A) don't have to worry about pointing at something misleading B) don't have to maintain (although I'll be happy to add whoever as a maintainer to this PURL) If the GPO ever has a better alternative, we just point the PURL at it in the future. -Ross. On Fri, Mar 27, 2009 at 6:41 PM, Houghton,Andrew <[log in to unmask]> wrote: >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of >> Jonathan Rochkind >> Sent: Friday, March 27, 2009 6:09 PM >> To: [log in to unmask] >> Subject: Re: [CODE4LIB] registering info: uris? >> >> If GPO had a system where I could resolve Sudoc identifiers, then this >> whole problem would be solved right there, I wouldn't need to go any >> further, I'd just use the http URI's associated with that system as >> identifiers! This whole problem statement is because GPO does not >> provide any persistent URIs for sudoc's in the first place, right? > > With a little Googling how about this: > > sudoc: E 2.11/3:EL 2 > <http://catalog.gpo.gov/F/FIBJ8T23DNC33L6KEDYR7Q8Q3MF6BI9H7Q5XPG4KB3N57HX35X-17544?func=scan&scan_code=SUD&scan_start=E+2.11%2F3%3AEL+2> > > looks like the param scan_start= holds the sudoc number. Sure it gives you other > results, but its might work for your purposes. > > Seems like they are creating bad HTTP responses since Fiddler throws an protocol > violation because they do not end the HTTP headers with CR,LF,CR,LF and instead > use LF,LF... > > > Andy. >