Re: [videoblogging] question

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

i obviously have no clue here…
but how about enclosures…
im researching how to make my posts show enclosures for the future when RSS
aggregators need to read the video only in the RSS feed so it knows what to
download overnight…
can this be used somehow with video comments?

Quoting Andreas Haugstrup <videoblog@…>:

> I'm going to cut away my own words in this reply. I hope people can still
> follow the thread.
>
> On Thu, 16 Sep 2004 13:29:40 -0400 (EDT), Lucas Gonze <lgonze@…>
> wrote:
>
> > On Thu, 16 Sep 2004, Andreas Haugstrup wrote:
> > I think that I don't know the difference between hypertext and
> > hypermedia.
> > Can you enlighten me?
>
> Adrian probably has some nice definitions at hand, but I'll have to do
> with Wikipedia. Hypertext is just a subset of hypermedia. See:
> <http://en.wikipedia.org/wiki/Hypertext>
> <http://en.wikipedia.org/wiki/Hypermedia>
>
> Hypermedia in the sense of video and audio would mean that the audio/video
> would have the "hyper" qualities of hypertext (ie. linking).
>
> > 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.
>
> Relying on HTML when we are talking audio and video content is something I
> don't like to do. If nothing else the because you run into the permalink
> trouble. You would have one URL for the HTML and one for the video. And
> how do you find the correct video in the HTML file? It's best just to get
> rid of the wrapper all together (ie. assign the permalink directly to the
> video file).
>
> > 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.
>
> But think of the possibilities! The data would be located along with all
> the other metadata at the begining of a file so you would only need to
> fetch the first couple of kilobytes of a video. It would be no different
> than fetching an HTML file.
>
> > 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.
>
> You need that for text also. The difference is that there is only one
> format of text (HTML). I would love to have everyone use SMIL for example
> as it would make parsing files for links just as easy as it is with HTML.
> So all that's needed is one common format to present audio and video
> hypermedia. W3C says it's SMIL, but hardly anyone is using it.
>
> > Sure you can. You search on response:to="URL of my video", then view
the
> > HTML of the page containing that link.
>
> And that's the problem in a nutshell. A response:to solution would be a
> waste of computing power, time and money on an immense scale.
>
> With pingbacks you simple ask the URL to return a list of incoming links.
> It's simple and easy. The workload is on the content creator since he has
> to send pingbacks whenever he creates new content. For the person this
> would only costs a little bit of time, and whatever bandwidth it costs to
> send the small pingback packages.
>
> With a response:to solution you would have to seach *the entire world wide
> web* every time you wanted to see incoming links to an URL. The workload
> is on whoever requests the list (or whoever he asks to compile the links
> [eg. Google]). Compared to the work required to send pingbacks this
> requires a vast amount of power. Only the big players with factory halls
> filled with servers would be able to handle this.
>
> Each document on the world wide web is only created once, so the
> time/energy it requires to send pingbacks is not really anything worth
> talking about. But requesting a list of links is likely to happen many
> many times more, and that's why it's such a complete waste to search
> through every single URL everytime someone asks for such a list.
>
> > 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.
>
> Yeah, they do. Pingbacks are requested from the author of a document.
> Already there they are better (no webmail system referers, not useless
> referers like URLs without a required query string, no duplicates [eg.
> with and without a trailing slash]).
>
> > 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.
>
> But with pingbacks *everyone* can be an accesspoint. With solutions like
> response:to or technorati only big players can be an accesspoint. I can't
> make a system that finds incoming links in a response:to system, but I can
> take advantage of pingbacks in a second.
>
> > 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.
>
> I thought about that for a long time. It works on paper, no doubt about
> that. You only add the <link> if the HTML presentation and the video file
> contains the same information. On the other hand I don't think authors are
> aware of the differences between HTML and video file being the same
> resource, and an HTML file with a video file embedded. Because the
> difference seems insignificant when you glance over it, but it has far
> reaching consequences.
>
> – Andreas
>
> —
> Personal: <http://www.solitude.dk>
> File Thingie – PHP File Manager <http://www.solitude.dk/filethingie/>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>


Jay Dedman
Manhattan Neighborhood Network
537 West 59th
NY NY 10019
212 757 2670 ext.312
www.mnn.org