How do authors use TV URLs? (was RE: URL: Background and Requirements)

From: Ted Wugofski (
Date: Thu, Nov 05 1998

Message-ID: <>
From: Ted Wugofski <>
To: "''" <>
Date: Thu, 5 Nov 1998 10:11:07 -0600
Subject: How do authors use TV URLs? (was RE: URL: Background and Requirements)

Has someone documented "who" will use these URLs.  I was under the
impression that URLs would be specified by humans.

In the WWW today, a content author links to a known resource on the
Internet through a URI.  Carrying this over to television, this says
that an interactive content author links to a known resource in the
television transport through a URI.  Yes, it may also point to the
Internet, but that is well understood.

If this is true, I have a hard time imagining a content developer being
able to specify a URL that references another stream prior to encoding
and multiplexing.  None of the addressing information is available when
I originally authored the content.

Even if the addressing information was known a priori, it would be
invalid when the program is rebroadcast at a later time or in a
different transport.

To get around this, I would have to encode something symbolic (a logical
URL) that gets modified once everything is encoded, the multiplex is
created, and all of the identifiers specified.  Then I would need
something that would either map this logical URL to the real resource at
run-time, or transcode the content with the proper URLs (physical URLs).

What am I missing here?

I can't imagine a usable and reuseable URI scheme (for a television
transport) unless there is a level of indirection.  In other words, the
URI points to the table and RDF is used to "find" the particular
transport, stream, and packet.

Ted Wugofski
Over the Moon Productions
(a wholly-owned subsidiary of Gateway)

> -----Original Message-----
> From: Henning Timcke []
> Sent: Wednesday, November 04, 1998 8:44 PM
> To: 'Simon Gibbs'; Warner ten Kate;
> Subject: AW: URL: Background and Requirements
> On what protocols those other URL's would be used ?
> Henning
> -----Ursprüngliche Nachricht-----
> Von:	Simon Gibbs []
> Gesendet am:	Mittwoch, 4. November 1998 22:58
> An:	Warner ten Kate;
> Betreff:	Re: URL: Background and Requirements
> Warner ten Kate wrote:
> > I agree that the content stored on your local disc is at
> > another location than the original one. How do we inform
> > the application document using that content about the change ?
> >
> > I think we need both an URL scheme which points to a specific
> > location, as some additional scheme which creates a level of
> > indirection and enables to solve the type of problems I described.
> >
> > [Expanding the caching strategy, as described by Glenn Adams,
> > to persistent storage (VCR) is interesting, and generates,
> > a kind of implicit level of indirection: first look at your
> > VCR than in the broadcast stream. There is, however, not a way
> > to manage explicitly that 'indirection' scheme. For example,
> > I am not sure how it expands if multiple storage media (camcorder)
> > connected to an in-home network are involved. What are the 
> (implicit)
> > precedence rules ? Are all devices on the network to be checked
> > if they contain the data requested (non-expired) ? Does it imply
> > that during the original broadcast my user agent also has to check
> > all my local storage devices at the in-home network ?]
> >
> Perhaps it helps to think of three different "families" of 
> URLs.In particular:
> 1) broadcast URLs
>    refer to assets obtained from broadcast streams,
>    if such a URL is embedded in a broadcast stream
>    and if the resource it refers to is in the
>    same stream (ignoring for the moment whether this
>    means elementary stream or transport stream) then
>    the URL should still be resolvable if the stream is
>    time-shifted (ie, recorded and played back)
> 2) home network URLs
>    refer to assets stored on such things as CD/MD/DVD
>    discs, AV servers, STB flash
>    these assets may be copies of those in broadcast
>    streams, purchased on storage media, downloaded
>    from the Web, etc.
> 3) "normal" URLs - http:// and others currently in use
> Simon