Andreas Haugstrup Pedersen | solitude.dk

Through Lucas Gonze I saw Tim Berners-Lee's Links and Law. Lucas pulls out this quote:

A normal hypertext link does NOT necessarily imply that

• One document endorses the other; or that
• One document is created by the same person as the other, or that
• One document is to be considered part of another.

This is important. I agree that normal links has no implied meaning or relation. Lucas uses this as argument as to why playlist creators should not be scolded for linking directly to media objects instead of the encapsulating. I think he leaves out the most important thing. In the very next section Berners-Lee writes:

Images, embedded objects, and background sounds and images are by default to be considered part of the document.

Embedded objects are a part of the document. This is also true for blog entries where links marked with rel="enclosure" carries with it meaning (links marked with the rel attribute have meaning, they are not regular links). They carry the meaning that the destination of the link is a part of the current document — just as if it had been an embedded object.

And people should respect that relationship and not link directly to the media object. Links should point to the blog entry permalink. By extension of the rule that normal links carry no meaning blogging engine must not add any media object linked as enclosures in a feed.

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.

A while ago Jon Froda and I talked briefly about decentralized reader tagging of content. It's a new method of tagging that differs from the two widespread tagging methods. First there is del.icio.us style tagging, a centralized service where anyone can tag any web resource. I like del.icio.us, but it's not the answer to everything. One issue is that it's centralized (everything lies in one place), and at times it is a weakness that any web resource can be tagged. At the other end of the spectrum we find Technorati style tagging. Here it is the author or creator of a web resource who can tag his own content. The advantage is that it is decentralized (the tags are embedded directly into each web page), the disadvantage is that only the author can tag content (this is of course also an advantage).

What we talked about was to combine these two styles by making a system where anyone could tag a web resource in a decentralized manner. Fortunately a couple of people have beat us to it.

First Jon points to Feedster's implementation. It works by appending a form at the bottom of each blog post where anyone can enter a tag for that blog post. It succeeds in lowering the barrier of entry, but it's still a centralized service in the sense that Feedster is sitting on all the tags. A much more fun example comes from the BBC. The prototype allows any visitor to a page to tag any web page at the BBC (it's a prototype so it doesn't work on the BBC website). For the user it's pretty much the same experience as the Feedster solution, but the difference is that the data is not stored on some centralized server. Each website collects their own tags. In an ideal world these reader-submitted tags would also be marked with rel="tag" so they would be picked up by services like Technorati.

This is an interesting new way of tagging. I coubt it's very useful for websites like this blog — with only one author I can tag my content better than my readers, when it comes to just categorizing content on this one website. For larger websites with lots of different content from different authors I think this could actually come to good use. Having the readers of a website categorize the content could lead to some pretty cool results. It differs from del.icio.us because it's easy to do (no account necessary), and more importantly because it's focused on just one website. Where del.icio.us is out to tag the whole web, this system is only out to categorize one website. The BBC is a perfect example where this could work wonders. Wikipedia is another.

For a straight-up, decentralized del.icio.us style tagging see xFolk. It's a XHTML microformat, and it's just been released in version 0.4. It looks very promising, I'd certainly like to see services like del.icio.us take advantage of the format as an export/import format at least.

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.

Lucas Gonze sees a paradox in web audio/video:

Web audio/video is special because there is a clash at the level of meaning. Hypertext has its own sense of time, and when it has to run on a schedule there is a conceptual meltdown. Imagine an endless series of web pages, each of which let you linger and click on stuff for one minute before transporting you to another web page. Imagine that each page is made up of sub-elements that linger for 30 seconds, and the sub-elements are made up of sub-sub-elements that linger for 15 seconds. No matter what you try to click on, by the time the mouse goes down it isn't there any more. That is web audio/video. That is hypertext playlists. It is incredible and wonderful, but also gibberish.

And he's right that it's gibberish. I don't agree that there's necessarily a paradox in web audio/video. There is an underlying assumption in the above that audio/video has to run on a schedule and that the act of consuming audio/video is a passive one. That's not how the web works so of course there's a meltdown when you try to run the web as a passive medium. It ceases to be the web, because the one thing that characterizes the web over previous media is that it's an interactive one rather than a passive one.

A playlist of videos is not a video equivalent of hypertext. You can use a playlist as a way of recording a path travelled through a hyper-structure, but it's not a hyper-structure in itself. Of course there's a meltdown when you think that a playlist is hypervideo, and of course that's not how hypervideo works.

On it's own a playlist is just a way to sort nodes. It doesn't foster hypervideo because the individual parts of a playlist hasn't changed. If I can't navigate with links from the video I haven't gained anything — it's just regular video collected by someone. There's no interactivity, I'm still a passive recipient. For hypervideo to work I have to be able to go from each node to another node that relates to it. In a playlist I can only move forward and back. The text equivalent would be if each webpage only had two links on it, back and forward, and no one was allowed to link to me.

And one last thing:

Imagine that each page is made up of sub-elements that linger for 30 seconds, and the sub-elements are made up of sub-sub-elements that linger for 15 seconds. No matter what you try to click on, by the time the mouse goes down it isn't there any more. That is web audio/video.

Not giving the recipient a chance to act on links is just poor authorship. This is the text equivalent of making links that are too hard to hit (eg. this link: .). It's stupid so why do it? Just because some people can't make links properly you shouldn't disregard the concept. Links in video should probably appear for at least several seconds to give recipients an opportunity to read the link, understand the context of the link and make a decision on whether to click the link or not.

I'm not after Lucas or anything. I'm quoting him so much because he has a very good weblog. We have different perspectives so naturally I don't agree with him always.

…and the Max Power way. As Homer Simpson beautifully put it:

Homer:

There are three ways to do things: the right way, the wrong way, and the Max Power way!

Bart:

Isn't that just the wrong way?

Homer:

Yeah, but faster!

Eric Rice notices that his syndication traffic has surpassed his normal traffic and notes:

Right now, Steve Gillmor is reading this and smirking at me. He believes the HTML page model is, or will be, dead. I'm not totally opposed to all aspects of that idea, however it seems to me that to get the same user experience to show up in RSS feeds, feed programs need to become browser v.2.... so are we just rebuillding the web?

And he is right. Not only would you be reinventing HTML, you would be doing it worse than Max Power. It would be the wrong way, but slower. And let me tell you this: Solving a problem worse than Homer Simpson is a pretty awful way of solving an idea.

No matter how deep into the RSS can do friggin' anything camp you are, you have to admit that HTML handles hypertext a truckload better than RSS will ever do. That's because HTML was designed to handle hypertext and RSS was designed to handle syndication of said hypertext. HTML has had over 10 years to develope a markup language to handle hypertext, RSS has spent exactly zero seconds trying to solve the issue of handling hypertext (it handles syndication pretty well though).

For RSS to replace HTML it would need to become HTML, with added syndication features. That's solving the problem the wrong way slowly (why the hell would you ever want to reinvent HTML from scratch like that). It's making a relatively simple problem very complex — just like American voting machines.

I already have a seamless integration between the syndication (RSS) and content (HTML) working quite nicely. RSS is integrated into my webrowser so I don't notice when I switch from RSS to HTML and back. If the problem is that you want the content show up in it's glory look at the permalink and load the damn page automatically.

With that said there's one more simple reason that RSS can't replace HTML. You can't archive RSS very well (or at all). How do you link to an item in a feed? Oh, right — you can't. How's that for killing conversations on the web. Even if you could link to an item the item would disappear once the item is pushed off the end of the feed.

Are you going to say that you'll just split the items into different files and save them where people can link to them? Maybe you'll also add the ability to link and quote. Congratulations, you just re-inveted HTML with different element names. You all can take your RSS-can-do-anything statements and shove them up your… Think before acting, people. What would be easier? Adding syndication features to HTML (like RSS is doing currently) or adding all of HTML to RSS? Yes, that's a rhetorical question.

The syntagmatic is the ordering through time (and space) of ‘units’ so that a meaningful discourse is produced. The canonical, and usual, example of this is, of course, common language. As the paradigmatic is not particularly necessary, or evident, in cinema, so too is this the case in hypertext, nodes can be joined in various ways and there is not, strictly speaking, the need for a formal grammar in hypertext to ensure the production of meaning.

A long time ago I got referred to Adrian Miles' “Hypertext Syntagmas: Cinematic Narration With Links”. It has been lying alone in my bookmark folder for so long because Miles, like most other English-speaking academics, have a sadistic fascination with long words. Something I, as someone who has English only as a second language, get very frustrated with.

However, I have spent a good half hour reading and clicking through the hypertext this evening. It is a very interesting text, and I find it very liberating to make my own way through the text. At the same time I would imagine it would get frustrating to use the text as a curriculum for a lecture since no two readers would have read the exact same text. But then again, that's the whole point.

I'm stopping my reading for tonight since I have other work to do before bed. If you want to start where I ended you can enjoy the fine node called “link metastructures”. Or if you're a wimp you can begin with the introduction.

I tested a first version of a video commenting system last week. As I'm writing this nine people have uploaded their own video comment to my original video. But as I've said before I'm a bigger fan of a distributed hyper-structure than a centralised linear structure like my first video commenting system. Just for fun I'll see if everyone can get the best of both worlds with version two. My goal with this text is to make a case for pingbacks and how they can be used to create a video commenting system.

All About the Links

The World Wide Web is a chaotic network of documents linked together by… well, links. If we have a random document (b) the connections would look like this:

There will be a series of documents (a) that have links to our document. And our document will itself contain links to other documents (c). With the web and our browsers work right now it's only possible to move right in the model. You start at a document where you can follow links to other documents, but you can't see which documents are referencing the one you're reading. I can't help wondering why this is has not been a part of the web forever. Only by going left in the model you can get an overview of a topic, and only then you can enable ‘conversations’ between documents.

Trackbacks and Pingbacks

That's where trackbacks/pingbacks enter into the picture. With trackbacks/pingbacks it is possible to contact a document (b) and recieve a list of documents (a) that have links to it. This is effectively a distributed comments system.

I'll focus on pingbacks for one simple reason: Trackbacks only works with HTML pages, pingbacks work with any kind of file. Since we are talking about creating a video comment system it only makes sense to talk about pingbacks.

Fortunately the pingback system is so simple that it should be a crime. Whenever you create or edit a document (eg. when you post a new entry to your blog) you send off small messages to the documents you're linking to. The messages are then picked up by the server of that document where they'll sit and wait to be retrieved.

In the perfect world your browser would then be able to display all the documents that link to the one you're reading in a sidebar (or whatever). In the real world only a very small fraction of servers support the pingback system, and an even smaller fraction of these support the part of the system that makes this possible. I have to start somewhere, and history shows that if you create a demand from users the people who run the servers/create the software will get up to speed.

That's all that's need really. If all servers and all software that create web documents supports the pingback system it is trivial to make a small piece of software that takes any document, retrieves a list of referencing documents and outputs a list of links. If you had this for all documents you would be able to go both right and left in the model above.

Rich Media Makes an Entrance

Out of the box pingbacks work just as well with audio and video files as it does with text documents. There are things to consider of course. If one of the goals is to make playlists of these files they must be able to stand alone without a containing HTML file. Our media players don't display HTML pages, nor should they. Therefore all relevant metadata must be saved in the rich media file itself. Otherwise it can't be displayed to the listener/viewer.

I have tried to figure out how to extract metadata from Quicktime files, but so far I've not been succesfull. It must be doable though. In my perfect world I would be able to save at least:

• Title
• Author
• Length
• Still frame (in the case of video)

In the real world audio and video files are more often than not contained in HTML documents. It's much easier for the readers/listeners/viewers that way. They only need one program open: Their browser. If we are just making links from (b) back to (a) in the model above this doesn't matter. However for an automated video commenting system to work well it would be really useful not only to know that a reference exists, but also know what type of reference it is (text, audio or video). If you don't know what type of file you're fetching it's not possible to collect all video comments in a playlist for example.

If all files stood alone this wouldn't be a problem. Whenever a file is sent over the web a bunch of so-called headers precede the actual file. One such header (Content-Type) tells you what type of file is being sent, so it's very easy to distinguish video comments from text comments and vice versa. But if a reference is a video file contained within an html document there are issues. A model with the referencing document in the middle looks like this:

Suddenly there are two documents (one text, one video). The easiest way out of this problem is to treat the documents as alternate versions of the same document instead of two seperate documents. For that to work there needs to be links between the HTML document and the video file. The goal is that when you retrieve the HTML document you would know that an alternate video version exists (and vice versa). In HTML this is easy. You just add the following in the <head> section: <link rel="Alternate" type="video/quicktime" href="http://www.yourdomain.com/path/to/video.mov" />

For this to be 100% effective the video file would have to include a similar mechanism. For the time being no such mechanism exists. Instead anyone who posts their videos contained in HTML documents (that's probably 100% of all videobloggers) must ensure that pingbacks go to their HTML document and not directly to their video file! Then each HTML document must have the <link>-element so that it's possible for an automated service to find the alternate video content.

In fact, by using this <link>-element it would be possible to use trackbacks as well as pingbacks. Using the <link>-element should be seen as a patch-solution and not the real deal as it adds quite a bit of overhead (the HTML document would have to be fetched far more time than it would be viewed). On the other hand it is a nice compromise.

This is the point where I go to bed instead of finishing the piece. I thought I would be able to finish tonight, but I'm way too tired and I have to get up in the morning. Tomorrow I will finish up with all the good stuff: Automating the link gathering (ie. how to fetch all the videos), possible uses (like audio and video playlists) as well as a quick guide on how to turn pingbacks on.

Possible Uses For All This

The most obvious use for pingbacks is to simply show a list of webpages that link to the current one right there on the page — just like normal comments. Unlike normal comments visitors will have to follow links to read what people have to say. This encourages longer, more thought out comments than the quick fire-and-forget comments fields. A simple, first implementation would look like a list of Trackbacks (with the exception that not a lot of metadata (like author and an excerpt)can be displayed about videos at this point). Since all browsers have sidebars of one kind of another it would be a nice browser feature of the list of pingbacks would be displayed in the browser instead of on the page.

The next step would be to include information on what type of comment is being listed. For example a small icon could be displayed next to each comment.

And that's where the playlists come into the picture. When you know who have sent a pingback, and you know what kind of content the pingback is, you can easily make a playlist. You could either do this on your own server (if you have access to a programming language) or on a site like videoblogging.info. The process could go like this:

1. Enter an URL into a form field (or click a button in your browser).
2. Choose which kind of reply you want:
   • HTML page with a list of links (with filters on text, audio and video).
   • Playlist of video comments.
   • Playlist of audio comments.
3. Click the ‘Go!’ button.
4. Wait for the server to fetch a list of comments for you.
5. Sit back and enjoy your video playlist (if that's what you requested).

The format of the playlist needs to be somewhat standardized. For audio files I'm pretty sure M3U can be played by most players. For video SMIL is the obvious choice. If you wish to share your playlist with others it would also be trivial to server each playlist in the XSPF format for easy integration with services like WebJay.

It is the process of gathering links, sniffing for the content-type and finally creating playlists I'm working on implementing right now. The programming itself is not hard (school is just taking time away from sitting at the computer). The hard part is that currently there is not many pingback enabled websites and thus I hardly have any data to test with. Most importantly I don't have any audio/video comments to test my system with. More people need to pingback enable their websites.

Enabling Pingbacks

You need to have two things to enable pingbacks. First you need to send out a notice with every document that it's pingback enabled, then you need a pingback server to save all the pingbacks you'll recieve.

The first part is the easy part. You have two options: Either to send out a custom HTTP header, or — with HTML documents — use a <link>-element. If you are on your own domain you can most likely add the HTTP header easily. It should look like this: X-Pingback: http://www.yourdomain.com/path/to/pingback/server/ This header should be sent out with every pingback enabled document.

If you for some reason can't send out the HTTP header you can use the <link>-element. Since this can only be applied in HTML documents it's less usefull than than the HTTP header. The link element must look exactly like this: <link rel="pingback" href="http://yourdomain.com/path/to/pingback/server/" />, or if you are not using XHTML: <link rel="pingback" href="http://yourdomain.com/path/to/pingback/server/">

If you are not on your own server (if you're using TypePad for example), you need to lobby your provider to enable pingbacks (and probably to provide a pingback server as well). The pingback specification as well as the information on pingback.extensions.getPingbacks(url) contains all the technical information. In addition to that you need to be able to add the <head> section: <link rel="Alternate" type="video/quicktime" href="http://www.yourdomain.com/path/to/video.mov"> code to your video entries.

Pingback Servers

Pingback servers require more work. If you're lucky you're using Wordpress as your blogging tool. Wordpress already has a pingback server included. There is only one problem with the Wordpress pingback server. It doesn't include support for the pingback.extensions.getPingbacks(url) function. This is crucial if you want to make playlists of video comments. I doubt it would be hard to write a plugin for Wordpress to add this function, but I don't have any experience with Wordpress so I can't write it myself.

If you're not running Wordpress, but you are a videoblogger I can help you out. As a part of my research I'm writing a pingback server, and I can provide pingback services for any videoblogger who wants it (I hope). So if you want to try all this out, but can't get your own pingback server up and running contact me and we'll talk.

If you're on a hosted service it doesn't make sense for me to run your pingback server. If your provider can be lobbied into enabling pingbacks for your documents they can be lobbied into providing a pingback server.