Re: [videoblogging] question

On Thu, 16 Sep 2004 11:54:26 -0400 (EDT), Lucas Gonze <lgonze@…>

>> I'll type up a reply later. I think we're talking past each other.
> I hope we're not! I spent a stupidly long time absorbing your writing
> and
> generating a non-stupid response.

Okay, not completely past each other, but with a different focus at least.

> In the end I don't think I articulated
> my main point, which was something about the pressing need to gain the
> benefits of hypertext for these non-hypertext objects we're working with
> here.

Yes, that's at the core of it. The problem isn't that movies aren't
hypertext, the problem is to make movies hypermedia. But this is also
where we're talking past each other. There are two different 'problems'.

One is that audio/movies created right now aren't hypermedia. You can't
put links in your mp3 files. You *can* put links into your quicktime
movies, but people aren't *doing* it. So at least quicktime movies (and
SMIL presentations) are hypermedia, but noone except Adrian Miles and his
cronies are taking advantage of it.

The way I read your entry that's the problem you're trying to solve with
the HTML extension… ?

The trouble is that it's an overly complex solution. You would need to
wrap an HTML document around all your video content. This is bad compared
to the alternative (having links embedded directly in the video file).

The video has an URL, but by getting the URL you can't see which sites the
video are making references to. In order to get those you would need to
find the HTML document with the response:to links, and to find that you
need to be able to have a link inside the video file anyway. No, the links
should be inside the video/audio file – this isn't a job for HTML
documents or pingbacks (since pingbacks handle incoming links only, not
outgoing links).

The other problem is incoming links – the tapping on the shoulder. This is
the problem pingbacks are meant to solve – and I'm having trouble seeing
how a reponse:to structure would solve this issue. Or at least how it can
solve the problem well.

The problem is that without pingbacks it's impossible to take an URL and
get a list of incoming links (other sites that refer to our URL). A
response:to structure wouldn't solve this, because a response:to is just
another outgoing link (an outgoing link with a special meaning, but still
an outgoing link). You can't take an URL and see who is linking to that
URL, you can only see that this URL is a response to something else. You
can see that this *is* a comment, not who is *commenting*.

With pingbacks it's different. You can take an URL (of an mp3 or a
quicktime file or an HTML document) and then get a list of incoming links.

You mention the two other ways solve this problem with incoming links:
Referrers and Technorati. Referrers are bad because the signal to noise
ratio is obscene. It's a very unreliable way of finding incoming links.
You can read about that at: <>

Technorati is cool and all, but it's also worse than pingbacks for one
simple reason: It's a centralized system. Pingbacks are distributed and
that makes them faster and more flexible (and less subject to failure).
Technorati has to contain all "pingbacks" for the entire internet and
that's expensive, slow and time consuming. Pingback servers are only
recording pingbacks from their own resources and that's faster (and if it
fails it doesn't take down the whole house).

You mention that pingbacks take too much work for the user, but I
disagree. It is (or will be) transparent for the user. Only in my simple
tests users are required to manually send pingbacks to the people they are
linking to. In reality this will be automatic. Take WordPress for example:
When you post a new entry WordPress finds all your outgoing links and
sends pingbacks for you. Total transparency.

The same should (will be) true for audio and video content. When you post
a new audio/video file you blogging system should extract all outgoing
links in your audio/video file and send off pingbacks to those URLs.

Your blogging system should of course assign the permalink to the actual
audio/video file, and not the containing HTML. Unless your post is mixed
media (text and video together. Like most of Lisa Harper's posts where the
video shouldn't stand alone). Only then we'll have a hypermedia network.

Until we get that there is a temporary solution. There are two issues: 1)
We need to extract links to pingback and 2) We need a way to tell that a
video entry is a video entry and not an HTML entry (nor a mixed media

1) Is solved by putting all your outgoing links in the description of the
video entry. That way your blogging system will see them (because it
cannot yet extract links from a quicktime file) and send off pingbacks.

2) Is solved by the <link rel="alternate"> I proposed in my blog entry.
That way any computer who is trying to find videos will know that this
HTML is really just an alternate version of the video file (thus it can
safely reported as a video entry instead of an HTML entry).
Mixed media entries should be reported as what they are – HTML with
embedded audio/video content. They shouldn't be automatically included in
playlists for example because the playlist would not contain all the
information of the entry (it would only contain the audio/video and not
the text).

That's why I think we're talking past each other. I'm trying to solve the
last problem, not the first. I see the first problem as being a problem
that should be solved by those who create audio/video formats. They should
allow for links to be made (and if they're good for a way for computers to
extract those links, just as you can look for <a href=""> in an HTML

> …When it came to audio, my answer was playlists…

Don't confuse playlists with a hypermedia system. Playlists are cool
because they allow you to save a path through a hypermedia system, but
playlists don't make a hypermedia system.

You tricked me into replying before supper, and man am I hungry now.

– Andreas

Personal: <>
File Thingie – PHP File Manager <>