How do authors use TV URLs? (was RE: URL: Background and Requirements)
From: Ted Wugofski (Ted.Wugofski@OTMP.com)
Date: Thu, Nov 05 1998
Message-ID: <c=US%a=_%p=OTMP%l=MOON1-981105161107Z-750@moon1.otmp.com>
From: Ted Wugofski <Ted.Wugofski@OTMP.com>
To: "'www-tv@w3.org'" <www-tv@w3.org>
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
-----
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
>
>
>
>
>