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>
>>>
>>>
|