A blog is a stream of conscious. To some degree, so is an rss feed. If you are browsing it in rss then your reader will more than likely allow you to limit which articles you wish to see based on their tags or other information gleaned from the rss feed. For example, you can use feed://https://krypted.com//feed to access this page without graphics, which looks at the rss feed rather than the richer media content, including the css and other elements that cause graphics and the such to appear on the site.
You can then limit your results to any field that is specified in the index.rss file. In this case, you may choose to say, limit to the articles which I have tagged with Xsan. To do so, you would append a ? to indicate that you are searching for content, followed by the field that you will be searching which is in this case the word tag. Then you need to specify what you are searching for; for example, tag=xsan would limit the results to only articles which have been tagged as being about Xsan. Searches are literal, presenting a good argument why spaces and special characters should not be used when tagging assets.
You can then perform compound searches. To search for content that matches two different tags you would use an ampersand (&) to delimit the searches. For example, you could do feed://https://krypted.com//feed?tag=xsan&tag=unix which would search for all articles tagged as Xsan and Unix.
A number of solutions are based on the concept of an rss (or at least atom) feed. For example, Podcast Producer submits data to the weblog services of Mac OS X which can then be viewed as a feed rather than using the nice graphical interface that Apple provides (which is by the way very fast). You can also use rss with Final Cut Server (with a lot of tinkering) and with WordPress and a number of other popular sites. While I used the example of tag= above, this is not specified as part of the RFC spec for rss and so might not work across all rss engines, although it does work with weblog and WordPress, the CMS that this site is built on. Twitter and a number of other sites rely on and foster rss as part of their architecture and APIs.
The rss feed option therefore opens up endless possibilities for flexible integration between solutions by parsing feeds and even aggregating multiple feeds. In companies, this can allow you to have a news feed that is integrated into, for example, a SharePoint server. This might be useful if you have an announcement that has been tagged for only specific offices. Each staff member might have a feed in their portal splash page that only displays items tagged for their office, their position title or even their department. I would assume that a new national medical record solution will be a feed and each doctor that a patient visits will view those records in a feed (it’s lightweight and can have links to actual files such as x-rays, scanned/signed insurance forms, etc). In educational institutions this opens up the possibility of aggregating feeds from multiple Mac OS X Servers running Podcast Producer or the wiki+blog services into a course management solution, such as Moodle, Blackboard or D2L.
Aggregation will more than likely have a resounding impact on how we access and how we ultimately find relevant content. You can subscribe to a Twitter feed, to YouTube, Digg and limit your results to those that match patterns that are consistent with what you are interested in displaying. But aggregation of content when it is not appropriate or not acceptable can lead to issues with digital rights. This is one of the key aspects of what the Associated Press has a problem with right now. One solution they have come up with is to inject information into feeds which then can help track potential aggregators (which is according to their acceptable use policy, against the law). Other organizations want you to use their RSS feeds, but to only show the first paragraph or so of content, linking to the original site for the full article. They are saying yes, please link to our content so that we can have more subscribers, but please do not display our entire articles, or if you do please pay us a royalty for having done so.
If you own all of the content though, digital rights of the assets (aka articles) is not an issue. But whose job is it to make sure that you own all of the assets. How do you track which of those assets are yours? How do you limit the content that is appropriate for each user in your organization so as not to incur massive quantities of white noise, but still give the power to inform users and readily access content? These are all questions that creators of a lot of data will be asking (if they are not already) and there is no magic answer to any of these questions. The key though, is to think of the questions and how they relate to you.