AW: URI Requirements

This is the point:

"If we really want to solve the problem, we would develop a system that puts
a continuous trigger signal in the video feed so that we can ID at any time
exactly what is on, where we are in it, and so forth." 

This "timeline" (or say "songline") should be addressable at any time 
with content. So there should be a mechanism to connect the content to the "timeline", the " continuous trigger signal in the video feed".
On one side there is the "timeline" with "timeline ID Space" and on the other side there is the content with "content ID Space". Or in other words, the timeline should be able to have time as content as well.
To be continued

Henning
 


-----Ursprüngliche Nachricht-----
Von:	Davis, Rob - MTVN [SMTP:rob@mtvmail.com]
Gesendet am:	Dienstag, 17. November 1998 14:57
An:	Ted Wugofski; 'fin@finseth.com'; 'gadams@spyglass.com'
Cc:	'tenkate@natlab.research.philips.com'; 'www-tv@w3.org'; DASE E2E Team (E-mail)
Betreff:	RE: URI Requirements



Excuse me for jumping in midstream. I hope you all find my comments useful.
I've been lurking for awhile and figured it is time to add a broadcaster's
point of view. I work with convergence projects at MTV Networks. Of course,
opinions expressed are my own and do not represent MTV Networks in way,
shape, form or electron.

Craig is right on the money about the EPG being an unreliable guide. Due to
variations in broadcasting (like the fact that only a few networks actually
start shows exactly on the hour, some slip up to three minutes from the
advertised times), the only way to get the real deal on what is on air is
from the library management system (LMS) used by the broadcaster. EPG's do
take into account slippage, emergency interruptions and other common events.

Using the EPG is equivalent to doing nothing at all.

Of course, the EPG doesn't tell you the one thing everyone will need to
know, which is "When is the commercial break?" The reality of the TV
business world is that some resources we send during content may not be
appropriate for use during commercials, and some commercials may require
their own resources. Therefore, whatever system we use for resource ID must
also consider the commercials as "segments."


What is comes down to is that all broadcasters need a direct an accurate
connection between on-air and the resources being sent. Right now that data
exists at the head-end in real time.

If we really want to solve the problem, we would develop a system that puts
a continuous trigger signal in the video feed so that we can ID at any time
exactly what is on, where we are in it, and so forth. 

Without that, the LMS is as good as it gets.


Any thoughts?



Opinions expressed are my own and do not represent MTV Networks in way,
shape, form or electron.


R o b   D a v i s 
Executive Producer  
of Convergence Applications
M T V   N e t w o r k s 
phone: (212) 846-7515 / /  fax: (212) 846-6497
e-mail: rob@mtvmail.com <mailto:rob@mtvmail.com> 

	-----Original Message-----
	From:	Ted Wugofski [SMTP:Ted.Wugofski@otmp.com]
	Sent:	Monday, November 16, 1998 10:55 PM
	To:	'fin@finseth.com'; 'gadams@spyglass.com'
	Cc:	'tenkate@natlab.research.philips.com'; 'www-tv@w3.org'; DASE
E2E Team (E-mail)
	Subject:	RE: URI Requirements

	Craig,

	I strongly disagree with a solution that requires using the EPG data
for
	resolving a resource.  My real-world experience is that the EPG data
is
	not accurate enough for resolving "mission critical" resources
(seeing
	what is on TV tonight is different from autonomous operations). 

	While I do not have objective measurements of the inaccuracy of
existing
	EPG data solutions, I frequently find movies in the EPG that do not
	correlate with what is on the screen and when programming is delayed
	(due to press conferences, football games, etc.) I have *never* seen
a
	satellite (much less downloadable) EPG get corrected.

	Craig, the solution I see being suggested is a good start, but the
	date/time part of the solution needs to come from somewhere else.
The
	EPG does not support the level of accuracy I think is necessary and
it
	was not designed for the level of granularity we will probably need
for
	resource identification (i.e., a segment of an event).

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



	> -----Original Message-----
	> From: Craig A. Finseth [mailto:fin@finseth.com]
	> Sent: Monday, November 16, 1998 11:01 AM
	> To: gadams@spyglass.com
	> Cc: tenkate@natlab.research.philips.com; www-tv@w3.org
	> Subject: Re: URI Requirements
	> 
	> 
	>    1.	Under your recent URI requirements document, you have:
	> 
	> 			   Given a URI, it must be possible for 
	> a receiver
	>    to determine the time period(s) within which the resource can
be
	>    retrieved from the (also resolved) location. 
	> 
	> 	   Do you intend by this that the information to resolve
such a
	>    determination should be present in the URI directly? Or that in
	>    combination with some unspecified higher-level-protocol, 
	> e.g., SAP, SDP,
	>    etc., the URI may be used as a key to resolve such a
determination?
	> 
	> 	   If you mean the former, then this requirement goes beyond
the
	>    standard semantics of, say, HTTP URLs, which have no 
	> intrinsic temporal
	>    validity outside of the scope of querying an origin 
	> server, etc., for
	>    the resource and being informed it is no longer present, etc.
	> 
	> I would suggest that this requirement is an attempt to reconcile
the
	> differences between the nature of TV broadcasting (programs on a
	> schedule) with the web.
	> 
	> The approach that makes sense to me is to use an outside protocol
(the
	> EPG data) to resolve the date/time issues.
	> 
	>    2.	Regarding:
	> 
	> 		   A URI should be resolvable under any of the
following
	>    network access conditions: 
	> 		   ...
	>    In HTTP's interpretation of URIs, other resource variation axes
are
	>    provided as well: language, content-encoding, etc. Do you 
	> envision these
	>    applying in this context? What other variation axes do you 
	> anticipate?
	> 
	> Most transfer protocols provide some mechanism to carry the header
	> information.  Thus, whatever versions (as named by headers) the
	> broadcaster desires can be sent.
	> 
	> Unlike the regular web, there is no negotiation phase: the
broadcaster
	> makes the sole determination (based on indirect information such
as
	> customer surveys) of what to send.
	> 
	> Bandwidth and cost factors will also come into play (:-).
	> 
	> Craig
	> 
	>  << File: Ted~Wugofski~(E-mail).vcf >>

Received on Tuesday, 17 November 1998 11:57:35 UTC