I'm using a few applications in Tomcat, so inflections are much more
difficult to implement than content negotiation. I can probably tweak the
Apache settings to do a proxypass for inflections by modifying the examples
above.

I agree with Conal, though. Inflections are puzzling at best and bad
architecture at worst, and the sooner the community puts forward a more
standard solution, the better.

On Mon, Dec 8, 2014 at 7:21 PM, John Kunze <[log in to unmask]> wrote:

> Just as a URL permits an ordinary user with a web browser to get to an
> object, inflections permit an ordinary user to see metadata (without curl
> or code).
>
> There's nothing to prevent a server from supporting both the HTTP Accept
> header (content negotiation) and inflections.  If you can do the one, the
> other should be pretty easy.
>
> On Mon, Dec 8, 2014 at 4:01 PM, Conal Tuohy <[log in to unmask]> wrote:
>
> > 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>
> > >>>
> > >>>
> >
>