On Tue, May 12, 2009 at 5:51 PM, Tim Bray <Tim.Bray@sun.com> wrote:

On May 12, 2009, at 2:36 AM, Sam Johnston wrote:

1) Are we also talking about using IRIs or URIs only ?

There was some discussion about this before with Ben Black - Atom IDs are not meant to be dereferenceable

That is not correct. Their primary purpose is to act as unique identifiers, but the normative text (properly) sets no expectation about whether they should be usable for dereference. Many people feel that dereferenceable identifiers are generally speaking of higher value and are predisposed to use "http:" everywhere. This is one reason it's usually wrong to micromanage users' choice of URI schemes. -Tim

Sorry I didn't mean "must not be", rather "are not necessarily". Normally I would agree to leave users to do as they want here, and perhaps there is still some value in this (provided they follow some scheme to ensure global uniqueness, likely based on randomness and/or internet domains) but UUID URNs seem both simpler and safer. They're trivial to generate concurrently (even disconnected) and without having to maintain a central register or sequence.

Most importantly they don't reveal sensitive information (such as the number of resources), don't break when they appear in multiple places (conversely a http:// URL would appear as two resources) and they can be trivially migrated and merged (e.g. migrating between providers without having to rename/remap resources and links which could be a very expensive operation for a large collection).

Definitely worth considering in more detail, but we do know we can get the resource from "/<uuid>" and we can always make this explicit with rel="self" links.

Sam