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 <hough...@oclc.org> wrote: >> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of >> Jonathan Rochkind >> Sent: Friday, March 27, 2009 6:09 PM >> To: CODE4LIB@LISTSERV.ND.EDU >> 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. >
