Re: URI way-back machine

I've decided this *will* happen, it is just a matter of when. (This is  
the URI equivalent of the Internet Archive, but is definitely not the  
Internet Archive; maybe the Internet Archive will provide it someday  
for other URIs, the way it now provides it, sort of, for URLs.)

Time passes on the web just as it does in the real world, and the  
meaning and/or application of URIs on the web likewise will evolve  
(SKOS, anyone?), no matter how hard the 'authority' for a URI tries to  
freeze it.  The dissection of web URIs to divine their intended/ 
effective meaning at a given time will inevitably be required.

Some URI services are anticipating this (to some degree) and  
associating an indication of time with (or in) the URIs themselves  
(apologies to the opaque URI fans), enabling the services to respond  
in the future with specific metadata about that URI at any time in the  
past. As I have an accounting bias ("keep everything!"), I think all  
URI services should do this, but that's for another day/decade.

Not sure how it will be implemented, but when it is, maybe you'll be  
able to say you were the first one to document the idea!

John


On Sep 19, 2009, at 6:54 PM, Jiří Procházka 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
>


---------------
John Graybeal
Marine Metadata Interoperability Project: http://marinemetadata.org
graybeal@marinemetadata.org

Received on Sunday, 27 September 2009 18:48:51 UTC