I am really puzzled by the use of these non-standard "inflexions" as a means of qualifying an HTTP request. Why not use the HTTP Accept header, like everyone else? On 9 December 2014 at 07:59, John A. Kunze <[log in to unmask]> wrote: > Any Apache server (not Tomcat) can handle the '?' and '??' cases with a > few rewrite rules to transform them into typical CGI-like query strings. > > # Detect ? and ?? inflections and map to typical CGI-style parameters. > # One question mark case: ? -> ?show=brief&as=anvl/erc > RewriteCond %{THE_REQUEST} \? > RewriteCond %{QUERY_STRING} ^$ > RewriteRule ^(.*)$ "$1?show=brief&as=anvl/erc" > > # Two question mark case: ?? -> ?show=support&as=anvl/erc > RewriteCond %{QUERY_STRING} ^\?$ > RewriteRule ^(.*)$ "$1?show=support&as=anvl/erc" > > So if your architecture supports query strings of the form > > ?name1=value1&name2=value2&... > > it can support ARK inflections. > > I don't believe that the ARK spec and HTTP URIs are fully compatible >> ideas. >> > > True. A '?' by itself has no meaning in the URI spec, which means it's > also an opportunity to do something intuitive and important with an > unused portion of the "instruction space" (of strings that start out > looking like URLs). Any URLs (not just ARKs) could support this. > > The THUMP spec (where inflections really live) will be modified to > require an extra HTTP response header to indicate that the server is > responding to an inflection and not to a standard URI query string. > This could help in the '??' case, which actually could be interpreted > as a valid URI query string. > > -John > > > > --- On Mon, 8 Dec 2014, Ethan Gruber wrote: > >> Thanks for the info. I'm glad I'm not the only person struggling with >> this. >> I'm not entirely sure my architecture will allow me to append question >> marks in this way (two question marks is probably feasible, but it doesn't >> appear that one is). I don't believe that the ARK spec and HTTP URIs are >> fully compatible ideas. Hopefully some clearer request parameter or >> content >> negotiation standards emerge. >> >> Ethan >> >> On Sat, Dec 6, 2014 at 10:23 AM, Phillips, Mark <[log in to unmask]> >> wrote: >> >> Ethan, >>> >>> As Mark mentioned we have implemented the ARK inflections of ? and ?? >>> with >>> our systems. >>> >>> I remember the single ? being a bit of a problem to implement in our >>> system stack (Apache/mod_python/Django) and from what I can tell isn't >>> possible with (Apache/mod_wsgi/Django) at all. >>> >>> The ?? inflection wasn't really a problem for us on either of the >>> systems. >>> >>> From conversations I've had with implementors of ARK, the issues around >>> supporting the ? and ?? inflections don't seem to be related to the >>> frameworks issues as other issues like commitment to identifiers, the >>> fact >>> that ARKs are being used in a redirection based system like Handles, or >>> the >>> challenges of accessing the item metadata for items elsewhere in their >>> system. >>> >>> I think having a standard set of request parameters or other url >>> conventions could be beneficial to the implementation of these features >>> by >>> others. >>> >>> Mark >>> ________________________________________ >>> From: Code for Libraries <[log in to unmask]> on behalf of >>> [log in to unmask] <[log in to unmask]> >>> Sent: Saturday, December 6, 2014 8:23 AM >>> To: [log in to unmask] >>> Subject: Re: [CODE4LIB] Functional Archival Resource Keys >>> >>> This brief exchange on Twitter seems relevant: >>> >>> https://twitter.com/abrennr/status/296948733147508737 >>> >>> On Fri, Dec 5, 2014 at 12:50 PM, Mark A. Matienzo < >>> [log in to unmask] >>> >>>> >>>> wrote: >>> >>> 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 >>>>> >>>>> >>>> >>> >>> >>> -- >>> Tod Robbins >>> Digital Asset Manager, MLIS >>> todrobbins.com | @todrobbins <http://www.twitter.com/#!/todrobbins> >>> >>>