- From: Nathan <nathan@webr3.org>
- Date: Fri, 05 Nov 2010 00:12:05 +0000
- To: Larry Masinter <masinter@adobe.com>
- CC: Graham Klyne <GK-lists@ninebynine.org>, Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org" <www-tag@w3.org>
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