Re: URI way-back machine

Not really, it's not much about the service, but about making an
exception in semantics of URI.
Anyway I am having second thoughts about this idea, because it really is
a hack and is diverging from RDF's concept of URIs as just identifiers.

Hausenblas, Michael wrote:
> 
> Like the Internet Archive [1]?
> 
> Cheers,
>             Michael
> 
> [1] http://www.archive.org/
> 
> -- http://sw-app.org/mic.xhtml#i
> Sent from my iPhone
> 
> On 20 Sep 2009, at 03:01, "Jiří Procházka" <ojirio@gmail.com> wrote:
> 
>> Hi, I have an idea for an interesting web service (sort of)...
>> We all know every URI stops working as expected one sad day and we want
>> to get the functionality they offered at some point in past.
>> This is a way to connect REST applications with web archives/caches.
>>
>> Somebody would provide a domain which would serve for the purpose of
>> representing URIs of other domains at some point in time. This should be
>> someone reputable who will not want to use the domain later for other
>> purposes and can offer the longest ownership of it (purl.org?).
>>
>> For example URI: http://time.purl.org/iso8601/2008-08-29/http/purl.org
>> (http://time.purl.org/[timeFunction]/[timeFunctionArgument]/[schema]/[theRestOfTheURI])
>>
>> would translate into: http://purl.org on day 2008-08-29
>>
>> This translating and attempt to fetch the data from past would be done
>> by the client applications, the web service on time.purl.org would just
>> redirect clients who are unaware of the mechanism to the translated URI
>> so even though they did not get the desired content from the past, they
>> still try to get what is at the URI in present.
>>
>> The use of time function would enable various formats of time and
>> choosing methods, or even an argument-less function for getting list of
>> all version the mechanism is able to fetch. In fact this can be used not
>> only for retrieval of content from past, but any actions which require
>> the wrapped URI to work as normal when the mechanism is not supported.
>>
>> Of course the web service could provide the mechanism too so no change
>> is needed in the client applications (but applications could override
>> it), but this would limit the choice of time functions to those provided
>> by the service, though some standardization would be good.
>>
>> I know it's a hack but useful one IMHO.
>> What do you think?
>>
>> Best regards,
>> Jiri Prochazka
>>