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