Andreas Haugstrup Pedersen | solitude.dk

This is a very long entry. Don't say I didn't warn you.

On both the videoblogging group and the Show in a Box (SIAB) working group the question of How do we best present video on the internet? has come up multiple times over the past 3-5 months. It is a vital question for the average videoblogger who wants to improve his or her site and especially for groups like Show in a Box which are trying to create software and designs that help present videos in their best light.

However, the discussions on those lists are mixing together three separate issues to answer the question of how to best present video on blogs. I will outline the three issues below and attempt to explain why it is important to solve these separately.

One for the bookmarks is microformats.org. In the words of Eric Meyer:

It's primarily a community site, a place where people interested in microformats can congregate and share ideas. It's also a central point from which new microformats can be created and advanced. There are pointers to mailing lists, an IRC channel, a weblog, and more.

Microformats are more than a little bit exciting. They are the a semantic web today, instead of the Semantic Web sometime in the future.

Last week Steve Garfield complained to the videoblogging group. He was tired of filling out profiles on community websites:

Then I got an invitation to try out Yahoo! 360, yet another of the same community, with yet another profile to fill out. On that one I just put in my website link and told them to go over there to see my info.

In his reply Joshua Kinberg hits to nail on the head:

Why should you need any more of an online profile than your blog. Afterall, that is probably the best and fullest representation of your digital self. You should be able to simply put in your blog URL in a lot of these things and already be registered. Or, for that matter, these services could already know you by crawling your blog and autodiscovering what you've already decided to share about yourself.

By combining technology already available this would be not-so-hard to do. You only need to solve three problems (two small, one large):

1. The first issue is that you need a way to link your blog's URL to a document with your profile. Since blogs are written in HTML we'll just use the mechanism provided: The rel attribute on links. A value of profile would be appropriate. Add this to a HTML Meta Profile For Blogs and you're all set. This step can be skipped if you can (and want to) embed your profile information directly on the blog's front page.

2. The next step is saving the actual data. FOAF is one option, but FOAF is just too complicated for something simple like this. In my lastest post I mentioned hCards which seem like a perfect start. You can save basic information about yourself.

   I haven't read the vCard RFC, but I'm sure more fields are needed — It shouldn't be hard to extend the hCard specification with more fields though. For example it would be useful to have a way to include links to other places where you have a profile available. So you'd include a list of links to your Yahoo 360 profile, your Orkut profile etc. in your main blog profile.

   The advantage of using something like hCard is that the information can be directly embedded into any webpage — either your blog's front page, or a seperate document.

3. The last problem is the hard part: Community websites must be able to import these profiles.

Another part of a scenario like this is the privacy issues. It would be very easy to “steal” the profile of someone else. And of course a lot of people might not feel good about giving corporations free reign to mine their personal data.

For a while now I've been trying to keep an eye at the Technorati Developers' Wiki, it's all Tantek Çelik's fault. Time after time he just seems to come up with new and interesting ways to push HTML further. It's an inspiration to follow, and I think Tantek and cronies will keep leading the way in getting the most out of HTML. I think HTML has a lot more potential than people give it credit for, and if more companies were like Technorati we'd all be in a better place with less weird XML formats.

If you're new to all of this, and want to see how you can take a greater advantage of the opportunities HTML give you I present this reading list:

1. What Are Microformats? — Introductionary article (via Tantek's Thoughts).
2. Microformats — Design Principles
3. Xhtml Meta Data Profiles. Microformat for presenting HTML Meta Profiles.
4. XHTML Friends Network, describing your social relations through HTML.
5. hCard, vCards described in HTML. Opens up for interesting ways of sharing personal data (more on that later).
6. HTML Meta Profile For Blogs. My own pet project for giving blogs stronger meta data.

The first article has a good point that I have been putting forward more than once (because it aggrevates me):

Still, some gray areas remain. For example, is RSS a microformat? It seems to bear at least some of the characteristics of one, but on the other hand, a directed subset of XHTML could easily fulfill a similar role in a much more microformat-ish way.

Exactly! RSS should never have been “invented”, the need simply isn't there. With a tiny bit of extra meta data in your HTML it would be possible to simply use your blog's front page as it's RSS feed. It's just so&hellip stupid that I have to maintain a seperate RSS file with the exact same information as my blog front page when the two could be merged so easily.

When I began blogging again back in April last year I contemplated making this blog multilingual. Since some topics are only relevant to those who either speak Danish or who live in Denmark it would make sense to blog in two languages. Eventually I decided against going multilingual because it was too cumbersome to maintain, and none of the available blogging systems handled multilingual content very well (or at all).

With a bit of luck that's changing. Morgan Doocy and Chris Waigl are developing a plugin to Wordpress that will allow multilingual blogging to be handled with ease. They are looking for comments, and while talking to Chris in the #wordpress IRC channel I promised I'd give some (of course that was days ago now). Between the two of them they seem to have most things covered already. Chris has a call for comments, and Morgan has a description of the features implemented and planned.

1. If there are multiple versions of the same entry the permalinks should be linked together. This sounds obvious, but to me it's very important. It's already planned for the plugin with <link>-elements, which is good. Links that are used to switch languages in a blog entry should be marked correctly with rel="alternate" too of course. Not that I'll ever be writing the same blog entry in two languages. I'm much too lazy for that kind of work. It'll be very important for those who will have software that's trying to get meaning out of gibberish (like Technorati.

2. What's more important to me is the ability to hide entries not written in a language the visitor understands. Stephanie Booth had a feature a long time ago where I could click a link to hide all her French entries (or English whenever I wanted the self-mulitation that is trying to guess my way through French). I liked that.

3. Which leads me to my last point. Chris and Stephanie have descriptions in English when they write in a different language (and vice versa), and I see that this is a feature of the plugin to-be. It's very frustrating for me to see a description in English of something that looks interesting and then not being able to read the actual blog entry. I would much rather pretend that the entry didn't exist in that case (hence my wish to hide entries). Unless the entry has multiple versions of course.

I'll be following the developement of the multilingual plugin with much interest. It could be the killer feature that makes me switch to Wordpress. That says a lot considering the amount of hacked together goodness I have running right now.

The whole weblog world is talking about Google's invention of using rel="nofollow" to combat comment spam. The rel-attribute seems to be all the rage recently, and I like that. It's the most underused part of the HTML specification. Adding metadata to links is just plain cool. It was also slightly amusing to see the amount of commenters in the Slashdot thread who wondered if this was valid HTML. For a allegedly nerdy crowd you'd think they'd read the HTML specification.

The first thing I noticed was the lack of a profile to accompany the new value for rel. I was talking with Firas on #wordpress about this, and Mark Nottingham noticed it as well. Profiles are not just icing on the cake, they are an important part of making things work ‘right’. Without a profile you have ambiguity. You wouldn't know if someone using rel="nofollow" is using it in the sense that Google is using it, or if they are using it in some other way. Linking to a dictionary of keywords in a profile removes that ambiguity. Frankly, I'm a little disappointed in Google in this regard (of course nofollow could be added to a blog profile).

Having thrown my proposal for a Meta Data Profile For Blogs up for comments, I'm looking for meta data I've missed. At the same time it's important for me to keep it as simple as possible — adding too many options for meta data in the profile would only ensure that it would never be used in it's entirety. So I'm putting two more types of meta data here for discussion, and not in the profile itself (yet).

via

Via is a link-type. It can be used to give credit to a website:

Thanks to <a href="http://momentshowing.net/" rel="via">Jay</a> I found out about ourmedia.org.

keywords, categories or tags

Keywords, categories or tags are all synonyms for the same thing. I haven't decided on which name I think is best. They all describe the same meta data property for the meta-element. It's a comma separated list of keywords that relate to the current document. This could be categories from your blogging software, and it would allow for Flickr-like tagging of blog entries. I'm considering the tags name because it signals a more laissez faire attitude towards the amount of keywords used.

I plan on implementing keywords/categories/tags on this weblog. I've been wanting to add categories for a while to solve archiving trouble (it really doesn't make a lot of sense to archive based on publishing date alone), and I might as well employ a meta-element since I am already using HTML files as my archives. Thanks to Peter and Ryan for mentioning tagging blog entries (in relation to Me-tv playlists).

After a skimming through the notes from “Can your website be your API?” I realized that the most simple way to mark a citation to another document is to use the <cite>-element:

There are some nice <cite title="Conference XYZ: Discussing Cats"> <a href="notes.html">notes from the conference</a></cite>.

This seems much neater than using a rel-attribute on the link itself, but at the same time you loose out on the use of the reverse relation (the rev-attribute) because there is no <reversecite>-element. I can't decide, the main point of including the cite relation in my work in progress was because of the reverse relationship which can be used in a list of trackback/pingbacks.

I've written before on why guessing when including files as enclosures is bad, but I would like elaborate a bit. To paraphrase my previous entry guessing is bad because the wrong files will be tagged as enclosures which results in muddy data (and likely confusion). In addition having only the enclosures marked in the RSS feed ensures that it's only possible to extract the enclosures while the blog entries are present in the feed — thus you will loose this very important information after the entry is pushed off the end of the feed.

What annoys me the most is that the current practice of guessing limits me in what I can and cannot link to. I can't link directly to media files because Me-Tv and services like it will display the media file as the primary content, even if I only linked to the file in a side comment. For example I can't write:

Peter, Kenyatta, Josh, Jay and Mica were <a href="http://poorbuthappy.com/ease/video/metv.mov">hanging out</a>. It looked like they had a lot of fun talking about Me-Tv.

Likewise Feedster will add the media file as an enclosure and assume that I am the owner of said media file. Following that line of thought the guessing actually limits how audio/video and weblogs can interact instead of opening up new possibilities — audio/video is marked as something seperate from the weblog, not as a part of it.

That was my primary goal with writing the HTML Meta Profile For Blogs. It gives authors a way of tagging files that should be considered enclosures. The advatanges are multiple.

1. The information about which files are enclosures are saved permanently with the blog entry, not only temporarily in the feed.
2. There is no muddy data since only the files the author has marked as enclosures will be treated as such.
3. As a result you can link to any kind of file without having to worry about it being presented as the main content of your blog post.

Of course changes would still be needed in the user interface of blogging systems to make it easy for non-HTML savvy authors to mark files as enclosures.

It all began when the videobloggers started to go crazy due to RSS and content aggregation. Enclosures in RSS are great, but if the same information isn't saved directly in the HTML of the blog post it's also pretty useless. This is because quickly the item will get pushed off the feed and then you have lost your knowledge of what is enclosures and what are just normal links. Furthermore it's a problem because your feed contains way more valuable information than the blog post itself (the disadvantages should be obvious).

I proposed the use of the rel-attribute with values of alternate or enclosure back in October. I kept working along those lines because as I thought about it I realized that weblogs as a genre have more special link relations and metadata needs than just enclosures. Like permalinks, comments and ping/trackbacks.

The result is a proposal for a HTML Meta Profile For Blogs. It didn't take long to write the proposal — the time was spent on updating all my blog entries to follow this profile. As an example to show what can be done. You can see this on the monthly archive pages where I now include a list of citations and enclosures along with an excerpt of each entry. This is done by scanning each entry for instances of rel="enclosure" and rel="cite" (along with q and blockquote elements).

The advantages to using a profile like this are many. First off there is no need to change the underlying database of a blogging system because everything is stored in the HTML. That way only the blogging system UI has to be changed to enable enclosures. In the same way it can be used to optimize how trackbacks and pingbacks are handled (by only pinging rel="cite" links by default). Services like Technorati would also be able to automatically extract data from blogs in a much more precise manner. It would for example be able to know the difference between a blog front page and the permalinks.

That's where the real value is: Other services would be able to scan each blog for metadata without having to rely on guessing (this is inaccurate at best, harmful at worst). RSS is terrible for things like that, both due to the fact that it doesn't have the rich ways of describing content like HTML, and because RSS isn't archived.

I'd love to hear comments on this profile. Have I missed something? Would you implement it?