Well, I can understand the view of how correctly self-describing content could (one day) become content that’s self-managing (in the way that content in mashups is, or on the semantic web.) But I don’t think I’d want a browser to take over the role of the delivery tier of the content I want to push out in a very specific, targeted manner (which is usually the goal of a web CMS.)

It’s actually quite ironic I’d have to defend that to a content management vendor!

I think there is a lot of common ground between us. Your post was very similar to my experiences in similar projects.

You are wrong about how much a browser will be able to find in a video file, see for example this spec. Because the browser is extensible with javascript it will be able to use this metadata. A DAM system should be adding information to the EXIF about the workflow, not just about the shutter speed.

You are right that we do need to know more about the content, that the really basic stuff of author and creation date is not sufficient. Google actually shows how much information there is just in simple links though, but adding more structure to them will help a lot more.

First off, Kas didn’t actually say to keep the metadata in a separate repository or file — just keep it separated, logically. I think whether or not it’s better to keep the metadata in the same file, or to have it separated out “physically” is an interesting discussion, and a case can be made for both. But it’s rather besides the point he’s making.

At any rate, your post moves on about halfway through, and I’m having difficulty in understanding what you’re saying there. You must be taking a very technical viewpoint, because, yes, everything on the web is linked, and that’s the web’s inherent coherence; and yes, resources on the web describe themselves. And certainly, those links infer important metadata, which needs to be managed.

But if that’s your point, the problem with it is exactly what both Kas and I were talking about in our blog posts today. This kind of metadata is very technical: it’s only there to allow a browser to render the pages. It’s largely devoid of meaning, per se, and not at all sufficient to effectively manage the content itself. For that, you need a lot more meaningful metadata than the 1/20th shutter time gleaned from EXIF, or the that’s in the HTML of this blog.

As the amount of content explodes, and becomes ever more complex (tell me, what kind of metadata will a browser be able to extract from a video file?), we will need a lot more, and much better metadata to do anything meaningful with it. Being able to track the link from one URI to another URI won’t be enough. And where the metadata is, is of lesser concern. As long as it can be read along with what it describes.

But like I said, I may have completely misunderstood what you were trying to say here