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

Almost all of the use cases for tdb I can think of need a timestamp,
even when the description isn't varying (such as with data:).

And duri with data: doesn't make sense to me.


Larry
--
http://larry.masinter.net


-----Original Message-----
From: Nathan [mailto:nathan@webr3.org] 
Sent: Thursday, November 04, 2010 5:12 PM
To: Larry Masinter
Cc: Graham Klyne; Jonathan Rees; www-tag@w3.org
Subject: 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 08:27:33 UTC