Re: "tdb" and "duri" URI schemes...

Larry Masinter wrote:
> If you want diffs:
> 
> http://tools.ietf.org/rfcdiff/?url1=http://tools.ietf.org/id/draft-masinter-dated-uri-07.txt&url2=http://lists.w3.org/Archives/Public/www-tag/2010Nov/att-0025/duri.txt

Thanks :)

> I was convinced by the complexity argument that the <embeddedURI> should not
> allow an (encoded) fragment identifier, but I suppose I could go back and reconsider?

please do, cutting the fragments is a bit like saying you can't have a 
name which end in R.

I've been through a number of use-cases this evening, and in each case I 
keep coming back to the following:

   duri:<timestamp>:<URI>
   tdb:<URI>

Where URI is URI as per RFC3986, with optional query string, and 
optional fragment (encoded or not).

Where duri: is as defined

Where tdb: provides semantic indirection, and where <URI> can obviously 
be a duri: too.

This way it's both forwards and backwards compatible, and caters for 
every use case both seen and unseen.

<tdb:A>
   the thing described by <A>

<duri:2010:A>
   the resource that was identified by <A> as of 2010

<tdb:duri:2010:A>
   the thing described by the resource that was identified by <A> as of 2010

<duri:2010:tdb:A>
   the resource that was identified by the thing described by <A> as of 2010

duri provides temporal, tdb provides semantic indirection, if you want 
them both, use them both.

seems cleaner than the current mix of:
    <tdb:2010:A>
    <duri:2010:A>
    <tdb:1996:duri:2010:A>
    <duri:2010:tdb:1996:A>

Best,

Nathan

Received on Friday, 5 November 2010 00:13:16 UTC