Re: [videoblogging] question

On Thu, 16 Sep 2004, Andreas Haugstrup wrote:
> > 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'.

I think that I don't know the difference between hypertext and hypermedia.
Can you enlighten me?

> 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 general algorithm I'm using is say that you want to publish a document
containing an assertion that FOO is a response to BAR. I picked HTML as
the most trivial way to do that.

> 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).

Well, here I think there's no answer that really grabs me. Requiring
Quicktime parsers all over the place just to find out this simple issue of
what the video is responding to is a tough path to take. I appreciate the
reason why you're thinking of including metadata with the file itself, but
at the same time I believe that needing to parse each and every potential
wrapper format is very very unlikely to work.

> 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*.

Sure you can. You search on response:to="URL of my video", then view the
HTML of the page containing that link.

> 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: <>

But pingbacks have no better noise (read "spam") control than referrer
logging. There's no s/n problem right now because there's so little
actual usage.

> 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).

Well, any search engine can do the job. Google, Feedster, etc. The data
remains decentralized, it's only the access points (like Technorati) that
are centralized.

> 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
> entry).
> 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).

This is an interesting solution. I'm sort of buzzed at the idea of
considering the HTML and video different representations of the same
resource. At the same time I don't yet buy it, since I doubt that in
reality the video and HTML will really represent the same resource.

That said, there's an insight there, which is why I generated so much text

– L

> 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
> document).
> > …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 <>
> Yahoo! Groups Links