Re: URI Requirements

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

Let's step back for a moment and consider what we're actually talking

We'll use the EPG for these types of URLs:

- The Coke commercial tied in with this special showing of "Friends".
- All "Gilligan's Island" episodes in the schedule.

(See document to be posted for full examples.)

The conceptual purpose is to locate information in the EPG.  The
results will be as good as the guide data (as you correctly point out)
but, by definition, this is the best data avaiable.

   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.

As people get more used to EPGs in all modes (not just satellite and
advanced cable), they will rely on it more and it will thus get better
(or our complaint lines will fill up!).

Also, as people rely on the ratings information more, there will be a
stronger incentive to create systems that track better.

But, you're right overall, if the EPG data is broken, this part of the
system won't work.

But if the data is broken, it doesn't matter whether the data is
wrapped in an EPG protocol or some other protocol: it will still be

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

All of the above notwithstanding, we still have the SDT and other
"real time" protocols for actually carrying the "live" information:
these are at the requisite resolution and (presumably) the requisite


Received on Tuesday, 17 November 1998 12:03:11 UTC