- From: Hausenblas, Michael <michael.hausenblas@deri.org>
- Date: Sun, 20 Sep 2009 07:57:17 +0100
- To: Jiří Procházka <ojirio@gmail.com>
- Cc: <semantic-web@w3.org>
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 >
Received on Sunday, 20 September 2009 06:57:28 UTC