CIO Insight has posted the results of a survey of CIOs about which web apps they use "personally":

Video over the web	54%
Wikis	49
Blogs	48
RSS (Really Simple Syndication)	47
Podcasts	39
Social networking (e.g., tagging, social bookmarks, community sites such as del.icio.us, LinkedIn, Technorati)	33

Isn't that interesting? Statistically speaking, wikis, blogs and RSS work out to be about the same.

Shire News Network, one of our podcasters has been nominated as Weblog Awards Finalist. Click on the image to give them a vote!

There's a discussion on podcasting university lectures over at Slashdot. I had a discussion with a friend that works at Memorial about this very topic several weeks ago and it's probably worth looking into in a deeper way. The gist of the idea is:

• set up microphone(s) in every lecture hall
• record each lecture (obviously!)
• students, instead of taking notes (or only notes), would record the time of a particular interesting or salient comment
• students could then easily go back and re-hear a particular part of the lecture at their leisure

Tagging and microformats aspect:

• tagging provides a natural way to classify podcasts. That is, instead of coming up with a set of silios to dump podcasts into, each podcast would be tagged with many words as appropriate. For example: "physics P320 2006 william_smith 2006-09-05T10:00".
• If something like the BlogMatrix Platform was used (ahem), faceted tags would provide an even more powerful classification system: "subject:physics course:P320 year:2006 by:william_smith date:2006-09-05 time:10:00". Using faceted tags allows one to do queries like "what podcasts are available in physics in 2006".
• In either case, the whole recording and tagging process could pretty well be automated by tapping into a class schedules, minimizing the manual work needed to be done. This brings a whole microformat (hCalendar) aspect to the project.

Social media and student blogs:

• Students should be able to bookmark online and comment upon their favorite parts of podcasts
• These bookmarks obviously need to be retrievalable; my belief is that student blogs may be the best place to record this information (that is, collapse social bookmarking and tagging applications)
• These bookmarks will need to be able to do deltas into a podcast
• Collecting all these bookmarks across all students (and potentially across time) will provide collective intelligence/data mining/insight into what is really import in the lecture

Random-access media:

• Bandwidth doesn't come for free: it isn't cost-effective for students to have to download the entire lecture to hear a three minute clip
• Streaming media players could be a solution to this problem
  
• Something like a Flash MP3 player could potentially do "random access" to the right place in a lecture

Security:

• The discussion on Slashdot is centered around "security" -- that is, allowing only certain people to listen to podcasts
• I don't believe it's the place of the vendor (i.e. me) to dictate requirements to a client; however, the later potential requirements -- barcode scanning for attendence, for example -- seems crazy
• Restricting access to a subset of students (and professors) seems fairly straight forward, if a student profile can be retrieved from an LDAP directory

We at BlogMatrix find this project because these are exactly the types of "organizational collabrative" applications that we'd like to see BlogMatrix being used to create.

DeWitt Clinton has a good article about why you -- i.e. "we" -- should use Atom over RSS:

If you’re a human then you’ll probably have no problems spotting that the first one is plain text, the second one is XML-escaped HTML, and the third is HTML wrapped in an XML CDATA section. If presented in a web browser, in a HTML <div/> tag perhaps, then a human will have no trouble interpreting the content.

But if you’re a computer, it isn’t quite that easy. To a computer, the contents of a RSS <description/> element are opaque. The best a computer can do with it is hope to render it for a human to interpret.

...

What if you added semantic microformat markup to your HTML? If you’re using an opaque data format, then you may as well have spared yourself the effort, as no client will know it’s there.

Or what if you wanted to put some other structured data in your syndicated content feed? Geospacial data, perhaps. Product data. Or perhaps Google’s GData format. If it’s syndicated over RSS, no one will ever know.

So the problem is that the RSS syndication format is that it is lossy. Lossy insofar as information you had when writing the data is lost when it is passed over the wire.

...

My recommendation to application developers today is to use Atom 1.0, not RSS, as the basis for your content syndication.

Alas, commenter Kosso finds the key problem with using Atom: 

Does Atom support enclosures. And multiple ones at that?
If so, I would look at creating a toolset to podcast in both formats.

However, that does not mean feeds won’t be broken. So many publishing tool are broken. RSS is ’simpler’ than atom.

...

I don’t want to fan a feed war, but I want to judge by trying to build a feed publishing tool which works.

BlogMatrix will always have a podcasting component (i.e. adding attachments to posts) and that means until Apple's iTunes accepts Atom feeds, well, RSS it is. Afterwards ...