 |
 |
Hi Ethan, I'm hoping Mark Phillips or one of his colleagues from UNT will respond, but they have implemented ARK inflections. For example, compare: http://texashistory.unt.edu/ark:/67531/metapth5828/ http://texashistory.unt.edu/ark:/67531/metapth5828/? http://texashistory.unt.edu/ark:/67531/metapth5828/?? In particular, the challenges posed by inflections are described in this DC2014 paper [0] by Sébastien Peyrard and Jean-Philippe Tramoni from the BNF and John A. Kunze from CDL. [0] http://dcpapers.dublincore.org/pubs/article/view/3704/1927 Cheers, Mark -- Mark A. Matienzo <[log in to unmask]> Director of Technology, Digital Public Library of America On Fri, Dec 5, 2014 at 2:36 PM, Ethan Gruber <[log in to unmask]> wrote: > I was recently reading the wikipedia article for Archival Resource Keys > (ARKs, http://en.wikipedia.org/wiki/Archival_Resource_Key), and there was > a > bit of functionality that a resource is supposed to deliver that we don't > in our system, nor do any other systems that I've seen that implement ARK > URIs. > > From the article: > > "An ARK contains the label *ark:* after the URL's hostname, which sets the > expectation that, when submitted to a web browser, the URL terminated by > '?' returns a brief metadata record, and the URL terminated by '??' returns > metadata that includes a commitment statement from the current service > provider." > > Looking at the official documentation ( > https://confluence.ucop.edu/display/Curation/ARK), they provided an > example > of http://ark.cdlib.org/ark:/13030/tf5p30086k? which is supposed to return > something called an Electronic Resource Citation, but it doesn't work. > Probably because, and correct me if I'm wrong, using question marks in a > URL in this way doesn't really work in HTTP. > > So, has anyone successfully implemented this? Is it even worth it? I'm not > sure I can even implement this in my own architecture. > > Maybe it would be better to recommend a standard set of request parameters > that actually work in REST? > > Ethan >