I’m not commenting on whether inflections are good, bad, or ugly, but simply looking at this from the perspective of real-world hurdles, unexpected interactions, and implementation challenges that are going to be run into by the selection of an existing reserved character as an inflection indicator. It looks like we disagree on the concept that “no one is using it” as it has a clearly defined role in the URI specification, and it is not uncommon to use “?”’s as a cache-busting mechanism when clearly no one intends to fetch an object’s metadata when they do so.
Taking a step back, this seems like a false economy vs a more expressive and human-friendly mechanism for defining access to metadata and policy for the object in question.
There are a number of different approaches that could be taken to achieve the stated goals of ARK without overloading the purpose of an existing defined reserved character, and I think that the project would be doing itself a favor by exploring the alternatives to find an approach that does not have the potential to slow adoption due to technical and political reasons.
--
Andrew Anderson, Director of Development, Library and Information Resources Network, Inc.
http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes
On Dec 10, 2014, at 14:28, John Kunze <[log in to unmask]> wrote:
> I don't know the precise constraints you're working under, but Henry
> Thompson of the W3C TAG (Technical Architecture Group) has advocated for
> consideration of the ARK approach to the TAG's meetings.
>
> The terminal '?' is sort of a no-brainer, but clearly it stretches the URI
> spec; on the plus side, it's ripe for definition since no one else is using
> it. It was Jonathan Rees (also of the W3C TAG) who pointed out the need
> for an additional response header, just in case some service actually was
> responding query strings that overlapped with inflections.
>
> Just to be clear, the ARKs don't own the inflections concept (in fact the
> ARK scheme is unusual in not "owning" things, such as a resolver). If you
> think inflections are a good/bad idea for ARKs, chances are you'll think
> the same for other kinds of identifiers. As Clifford Lynch once said, the
> '?' inflection should work for all URLs.
>
> On Tue, Dec 9, 2014 at 10:09 PM, Andrew Anderson <[log in to unmask]> wrote:
>
>> RFC and expectation violations make my brain hurt.
>>
>> Overloading an operator that has a clearly defined role in HTTP URIs (
>> https://tools.ietf.org/html/rfc7230#section-2.7.1) creates the potential
>> for /so/ many unexpected interactions between browsers (
>> https://code.google.com/p/chromium/issues/detail?id=108690), HTTP caches,
>> URL rewriting servers, etc. that implementations, adopters, and users are
>> going to be playing a long game of whack-a-mole working around them.
>>
>> The proposal is already carving out a URI namespace in the form of “ark:”:
>>
>> http://ark.cdlib.org/ark:/13030/tf5p30086k?
>>
>> So why not take advantage of the fact that any system processing the
>> “ark:” namespace is already going to have to be a custom application and
>> adopt a RESTful path to communicate the service requested instead?
>>
>> http://ark.cdlib.org/ark:metadata/13030/tf5p30086k
>> http://ark.cdlib.org/ark:policy/13030/tf5p30086k
>>
>> If a web services style implementation is undesired, what about creating
>> another reserved character or overload a character that is already used in
>> URIs but not part of the HTTP URI specification, “!"?
>>
>> Or, if a standard approach for HTTP header implementation were proposed
>> and adopted, it is not unreasonable to imagine that browsers might adopt
>> methods that would allow the average user access to the inflections without
>> jumping through hoops once adoption reaches critical mass.
>>
>> There are many approaches and techniques that could be employed here that
>> would not require overloading “?” in HTTP URIs that there really is no
>> excuse for trying to do so.
>>
>> --
>> Andrew Anderson, Director of Development, Library and Information
>> Resources Network, Inc.
>> http://www.lirn.net/ | http://www.twitter.com/LIRNnotes |
>> http://www.facebook.com/LIRNnotes
>>
>> On Dec 9, 2014, at 9:25, Ethan Gruber <[log in to unmask]> wrote:
>>
>>> 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>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>
