W3C home > Mailing lists > Public > www-tag@w3.org > November 2010

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

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Tue, 2 Nov 2010 19:32:57 -0400
Message-ID: <AANLkTin3oCgdFD5DZFkm+KsM8UJJaUHyAvDr6wL08uxv@mail.gmail.com>
To: "Jonathan A Rees (CC)" <jar@creativecommons.org>
Cc: Reto Bachmann-Gmür <reto@gmuer.ch>, Larry Masinter <masinter@adobe.com>, "www-tag@w3.org" <www-tag@w3.org>
On Tue, Nov 2, 2010 at 7:14 PM, Jonathan A Rees (CC)
<jar@creativecommons.org> wrote:
> I don't suggest handling the pathological cases. I just meant that the currently implicit assumption of non-pathology ought to be surfaced somewhere in the document.
> Jonathan.

I concur.

> -- apologies for brevity / using handheld gizmo --
> On Nov 2, 2010, at 15:35, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
>> On Tue, Nov 2, 2010 at 3:19 PM, Jonathan Rees <jar@creativecommons.org> wrote:
>>> There are two possible sources of instability, the URI -> resource
>>> mapping and the resource -> representation relationship. To be useful
>>> in the way that Larry wants it to be (e.g. for citation), DURI has to
>>> nail down *both* of these. The DURI names not the original resource,
>>> but a checkpoint of the original resource - a second resource whose
>>> representations are, and always will be, the representations that the
>>> original resource had at the given time.
>>> (using AWWW terminology here.)
>> If you are dealing with pathological cases, such as a URI that changes
>> what resource it identifies over time, then you have other things to
>> worry about. For example, if protocol is not followed the the
>> different representations might not be of the same resource. In that
>> case the citation would be of a particular representation (not
>> captured by the duri).
>> I think if you are going to handle such pathological cases, then
>> explanation and motivation has to be in the earlier section of the
>> document, where one would read about scope.
>> -Alan
Received on Tuesday, 2 November 2010 23:33:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:08 UTC