Interesting! Thanks. I didn't know you could use purl on a
pattern-redirect basis like that.
Ross Singer wrote:
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.
