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
-----
Ted Wugofski
Over the Moon Productions
(a wholly-owned subsidiary of Gateway)



> -----Original Message-----
> From: Henning Timcke [mailto:henning.timcke@werft22.com]
> Sent: Wednesday, November 04, 1998 8:44 PM
> To: 'Simon Gibbs'; Warner ten Kate; www-tv@w3.org
> Subject: AW: URL: Background and Requirements
> 
> 
> On what protocols those other URL's would be used ?
> Henning
> 
> -----Ursprüngliche Nachricht-----
> Von:	Simon Gibbs [SMTP:simon@arch.sel.sony.com]
> Gesendet am:	Mittwoch, 4. November 1998 22:58
> An:	Warner ten Kate; www-tv@w3.org
> 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
> 
> 
> 
> 
>