W3C home > Mailing lists > Public > www-tag@w3.org > February 2011

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

From: Larry Masinter <masinter@adobe.com>
Date: Fri, 18 Feb 2011 15:55:33 -0800
To: David Booth <david@dbooth.org>
CC: Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D05A00B2921@nambxv01a.corp.adobe.com>
(This is relevant to the TAG discussion on persistence, too)

Just going through old mail about this document, now version -08. Your comments were made on -07. I did take your comments into account in doing -08, but I'm not sure I acknowledged them or responded directly to you before.

The question still is whether any of this discussion belongs in the document itself. 

> I like the idea of adding a timestamp or cryptographic hash (as Sandro Hawke has suggested) to a URI, as a way of indicating which instance of a URI declaration was used when the URI was minted.  

Just some background:

I don't like the concepts of "URI declration" "owner" and "authority" in the (Semantic) Web Architecture, as described in


and I think "minting" carries more weight and implication of uniqueness than it needs:

I would write the lifecycle as:

0. Resource comes into being
1. Someone (Party A) makes up ("mints") a URI to identify the resource
   (This 'someone' doesn't have to be an 'owner' or have any relationship to the resource)
2. Party A then communicates this URI to party B ('uses the URI in a statement')
3. Party B  reads the statement and attempts to 'resolve' the URI [determine/
             contact/interact with] the resource

Communication is achieved when B's understanding  of what A meant matches what A's expectation of what B's understanding would be. Communication fails to the degree that A expects too much (e.g., expects domain names to last forever when they don't) or when B doesn't behave as expected or as is conventional (by, for example, trusting a malicious proxy to look up the URI for them.)

Standards are agreements between parties about what communication means; a good standard is one for which, when communicating parties follow the standard, communication matches expectation.

Note that there is no "URI declaration" or "owner" or "authority", and the act of "minting" requires no permissions. A can say whatever A wants to B, but if they both follow the URI standard and the URI scheme standard, they get the level of interoperability expected. 

> However, I do not  believe there is any need to define a new URI scheme to do this.

I'm not 100% sure we _need_ a new URI scheme, but I've talked about this one for long enough that it's useful to have a stable document describing it and be done.

I think the utility of new schemes is to give A more flexibility about what it can say to B.

> Instead, the same objectives can be obtained to greater advantage by leveraging http URIs using techniques described at http://dbooth.org/2006/urn2http/ 

I don't think your methods handle the case where there is a really large time delay between step 2 and step 3, or between step 3 and step  4 -- long enough for any "responsibility" to be forgotten. In fact, it would seem to lesson communication rather than improve it.

> Your premise seems to be that the institutional process of registering a new URI scheme makes URIs that were minted under that scheme are inherently more "persistent" than URIs that were minted with the http scheme,

No, I don't agree with that premise, and I don't see anything like that stated in the my document, so I don't accept your characterization.

>  which uses an authority component whose owner may change over time.  But I don't think this is true.  Rather, tdb URIs simply abdicate all responsibility for persistence.

I think "responsibility" is a time-varying function that eventually peters out: a party is responsible for something for a given period of time. "Perpetual care agreements" aren't really "perpetual": "perpetual care" is itself an administrative function and the agreement has a time lapse, even if it isn't explicit. There are no (permanent) "owners" or "authorities"; there are organizations or groups that have administrative control over particular network resources. And URI schemes don't have a "responsibility", so "tdb" and "duri" can't abdicate it.

If A tells B  "http://larry.masinter.net" then A is giving B less information  than if A tells B "duri:2011:http://larry.masinter.net". With the raw URI, A can expect B to just connect the "latest version" of that web resource, while with the date involved, there might be some expectation that B would try to look back.

> The document at
> http://tools.ietf.org/html/draft-masinter-dated-uri-07  does not define what it means by "persistence", 

-08 now has an  informative reference to  http://www.ietf.org/rfc/rfc1737.txt.

> but presumably it refers
> to the future ability by a URI consumer to determine the description (or
> "URI declaration") that the URI owner published when the URI was minted,
> as described in "The URI Lifecycle in Semantic Web Architecture":
> http://dbooth.org/2009/lifecycle/ 

(see comments on lifecylce above)

> URI owner.  This is the person or social entity that has the authority to establish an association between a URI and a resource, as defined in AWWW.  Normally it is the owner of the domain from which the URI is minted, however, the owner may delegate minting authority for all or portions of a URI space.

 " This means that the URI consumer must be able to do two things: (1) locate a candidate URI declaration; and (2) verify that the candidate is the correct candidate, i.e., that it corresponds to the timestamp specified in the URI.  Note that these two steps are needed regardless of whether the URI is based on the domain name authority."

As for the network effect:  First, I think this probably belongs as an "experimental" RFC; that is, I don't expect it to be significant. And I don't see what network effect you get from using a well-known domain name like "t-d-b.org" that you don't get from using a new URI scheme.  

Received on Friday, 18 February 2011 23:56:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:30 GMT