How do you store lots of content items for building into a flexible, browse-able web site? Having lots of content, you will want some index pages to explore the content by subject, by type of content, by project, by freshness and so on. You could make these index pages or menus by hand, the way I do it here on this site at this stage of its development. But this won't work for large amounts of content, or for the kinds of real people I know.
One approach is to put metadata on all the content objects, and have a machine query them. So I could label this post with a date and a content type 'blog post', to allow it to show up in the blog, and with a subject — Content Management I guess — to allow it to show up in a subject-based view.
It would be good if the same content could appear in both places, but wrapped differently. When you read the weblog you want to see what it is close to it in time, while when using the site as an authoritative reference on matters to do with content, you want to see all the words of wisdom on the same topic. The navigation should adapt to context in which you use the content. Using metadata allows us to show these kinds of proximity relationships, but at the cost of having to maintain indexes of all the metadata (indexes are required as you do not want to open up each record and have a peek inside every time you generate a page).
I think using metadata to drive a site is a valuable approach, and I am still keen to "Udell has an XPath based search on his weblog" walk Jon Udell's XPath, with metadata-rich XHTML content using an indexed repository.
But at work, we have a project where content handling needs to be added to an existing framework. Full metadata indexing, and introducing a new query language are best avoided. I am thinking about an approach that uses paths, as used in hierarchical file systems. Each content item would have one or more paths which may correspond to a file system somewhere, but would more likely not.
For this post, two paths would be /blog/2004/05/24/ContentOrganisation and /subject/ContentManagement/ContentOrganisation, a third might be /SelfImportance/SelfReferential/ContentOrganisation.
So the /subject page can take an argument for the subject, and look for paths beginning with /subject/$subject/, and blog pages can work the same way. This approach means we need only maintain one metadata index, for path. There is some loss in flexibility, not least of which is the requirement that the categorization is done before you build a new index page. But it would still be possible to look for all the content items with certain properties and add a path using a batch process, and to allow editorial people to add paths to existing items.