This is another comment on the need / use for a permalink URI to the RSS (or other standard) format of a blog post.

I have been mentioning this for a while, and more recently in response to the effort started by Sam Ruby to define a well formed log entry, which is now pretty jamming. Here is the Road Map to this effort.

In Sam's post today on Linkage, with the subsequent comments, there is an interesting discussion on blog entry identification through URIs and internal post identifiers. Sam's post suggests:

Now let's standardize and simplify. A well formed blog entry will have two universal resource identifiers (URI's) associated with it. One, a permaLink, will identify the preferred external "name" for this blog entry. The other, a postId, will identify the preferred internal "name".

In the comments, it is more clear that one intention with this is exposing an identifier for blog posts that is independent of URIs, to account for when URIs change and, I guess, permalinks not being absolutely identifying enough.

With the iCite net, these issue are being addressed a couple ways. One, there is iCNS which basically provides a permanent URI scheme. With iCNS, iCite links get updated when URIs change. So, this is effectively an "internal" (i.e., not URI) identifier, but it is managed in a DNS like way—it is not just internal relative to the site / server / software.

Another iCite feature is the ability to translate a (perma) link type URI to the internal identifier. In other words, if more than one URI points to the same post, the iCite container tracks this and can translate.

The main thing interesting to me about an internal post identifier would be if that were connected to a standard way to get at the post content and metadata, e.g., something like the RSS representation of the full post.

Permalinks point to the contextual presentation of a blog post. But, I think there needs to be a second permalink to the blog post data in some relatively straightforward data interchange format like a RSS.

With the iCite net, all links can effectively have two URIs: one for the contextual presentation of the content, and one for the data representation. The plan is that, from either URI, the other URI can be auto-discovered. And, with regards to the data representation, iCites support different data formats: so the data representation URI is basically to a format agnostic gateway through which different formats can be requested (one verbose XML format will be the default).

For the well formed log entry, I think an internal identifier is necessary if the post needs indicate how it can be accessed through an XML-RPC or SOAP API that can't translate the permalink back to the post id. (I posted some comments on these issues in May in REST and RPC, addressibility questions and More RPC addressibility ideas.)

In other words, if the post is permalink URI accessible and is going to be accessed via a URI, that permalink URI should be sufficient. If it is going to be accessed through a non-URI protocol, then it needs either some kind of post ID or the interface needs to be able to translate a permalink URI to whatever internal identifier.

Personally, I would like to see the two URIs being contextual presentation and internal data representation URIs, and assert that non-URI interfaces can take a permalink URI parameter and translate it to an internal ID. I think internal IDs like this really should be private.

Beyond this, if the ID scheme is meant to be a public and more permanent form of identification than permalinks, I think it best if those IDs are defined in relation to a DNS-like system. Otherwise, they IDs are still relative to site / server / software and I think it is questionable do what degree they are more durable than permalinks.