Time [was Re: Where are we?]

From: Michael A. Dolan (miked@tbt.com)
Date: Mon, Oct 11 1999


Message-Id: <3.0.5.32.19991011073530.009f3c10@cts.com>
Date: Mon, 11 Oct 1999 07:35:30 -0700
To: <www-tv@w3c.org>
From: "Michael A. Dolan" <miked@tbt.com>
Subject: Time [was Re: Where are we?]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 01:13 PM 10/10/99 +0200, Harald Tveit Alvestrand wrote:
>At 11:57 10.10.99 +0100, Jack Lang wrote:
>>Harald:
>>
>>Unfortunately the slot has been delayed by ten minutes, as the 
earlier news
>>program was extended.
>
>and in that case, the currently popular ShowView scheme breaks too.
>IMNSHO, the Right Thing to do, architecturally, is to establish two 
>orthogonal name spaces:
>
>- TV transmission stream and time slot
>- Information content, such as "series episode" or "today's news"
>
>Then it's possible to build an association service that is able to 
transmit 
>things like:
>
>   content://international.syndicates.com/TheLucyShow/Episode497/ 
will be
>   transmitted on tv-
channel://bbc1.bbc.co.uk/19990422:2200+0000:30min

The binding of program to service is likely to be done outside of URI 
scheme(s), as in the SI information of the transport.  So having 
pairs of URI's like this will not add to the object identification if 
what you really want is the program (as opposed to the service at the 
above times).  I think these are unrelated, but independently useful, 
schemes.

Also, as Jack pointed out, time is a very slippery animal, and the 
above time usage, while not totally un-useful, is a hint at best.  Is 
the above in UTC or someone's local time?  What final emission 
station service does this identify?  This is important since even 
though BBC sent it out on its satellite at 2200 UTC, the broadcaster 
had their favorite cooking show on at the time, and thus time-delayed 
it for your local area, or perhaps dropped it entirely.  So, this URI 
says, at best, "if you receive BBC1 locally, you may find something 
of interest at 2200 UTC".

>I think that's where we should end up; but since there's no 
consensus (that 
>I can hear) in this group that we should go straight there, we 
should just 
>make sure we don't block the possibility of ending up there.
>
>I think that's where we should end up; but since there's no 
consensus (that 
>I can hear) in this group that we should go straight there, we 
should just 
>make sure we don't block the possibility of ending up there.

I've always thought time may be useful, just not nearly as much as 
everyone thinks.

	Mike

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBOAH1sSl9dIG/haQGEQKmKwCffe0oap78z4MlK+D16YdQFX77XIgAoNVW
+zxqBx3oL6tRmQxO5G+x312w
=8uER
-----END PGP SIGNATURE-----

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122