- From: Craig A. Finseth <fin@finseth.com>
- Date: Wed, 30 Dec 1998 14:44:49 -0600 (CST)
- To: www-tv@w3.org
WWW-TV URI/URL/URN Usages
1998-12-17
Please send general comments on this document to the www-tv@w3.org
mailing list. Specific comments can be sent directly to me at
craig@finseth.com.
- Craig A. Finseth, editor
------------------------------------------------------------
This document presents a list of ways in which UR*s can be used in a
television context. The examples were contributed by a variety of
people.
Please keep these general notes in mind when reading the examples:
- RFC 2396 documents the terms URI, URN, and URL. We use that
document as a base. This document will use the string "UR*" to refer
to all three.
- Consider each example as representing the class of similar cases.
In particular, if your favorite example isn't on the list, ask
yourself if it has the same UR* requirements as another that is on the
list.
- Some of the examples contain sample UR*s. Those samples that
contain schemes that are not already standardized (such as http:,
ftp:, etc.) should be considered as examples to aid understanding.
- You can assume that the receiver will know how to deal with already
standard UR*s such as http:, ftp:, mailto:, file:, etc. (Note that
this statement is "know how to" and not "be able to:" see the next
section.)
- Not all people will agree with all of the listed suggestions.
That's ok: at this stage, we're just brainstorming.
- All uses of trademarks in these descriptions are for illustrative
purposes only. There is no intent to assert that the trademark holders
actually do or do not intend to carry out any of the suggested
activities.
- The term "EPG" means "electronic program guide."
- This document will use the term "channel" to refer to what some
protocols refer to as a "virtual channel." A channel refers to
content addressible by a number.
The environment is television. In this environment, you have a
receiver that picks up one or more signals and deal with them. (We'll
use the term "receiver" to denote the box or module that does the
work.) Things to keep in mind:
* The receiver may have only one source of signal, or it may have
many. Typically, inputs can come from:
- over-the-air antenna (NTSC, ATSC, DVB, potentially other formats)
- cable feed (potentially a variety of formats)
- satellite feed (again, a variety of formats)
in any combination.
* The receiver may (and usually will) have some sort of video out
and/or an imaging device (picture tube/LCD/whatever). The receiver
may be able to display images from multiple sources (e.g.,
picture-in-picture). In some special cases such as a portable
stock-ticker type device, the receiver may not be able to decode the
"normal" audio/video image.
* The receiver may be stand alone, or it may be connected to some form
of "back channel." The back channel may be proprietary or
general-purpose (e.g., a network connection). The channel may be in
the form of a phone line, DSL, cable modem, general LAN connection, etc.
------------------------------------------------------------
Examples
These cases were distilled from the contributions. The original
messages are included later.
The requirements are to...
1. Be able to refer to the audio/video image. Example using HTML are:
<body src="tv:">
...
</body
which places the "live" image as a background and:
...
<table>
<tr><td>Upper left</td><td><img src="tv:"></td></tr>
<tr><td>Lower left</td><td>Lower right</td></tr>
</table>
which does a "picture-in-picture" type display with the image in the
upper-right corner.
2. Be able to include queries into the receiver in a
technology-independent manner (ie not relying on specific ATSC, DVB,
etc SI fields), such as:
tv://?program=X-Files [ This is one way a possible UR*
could be used to locate programs. ]
or:
bid://abc.com/?lang=Spanish [ Show the Spanish version of the
channel title/description. ]
3. Provide for technology-specific tuning, such as:
tv://echostar:100 [ Tune to channel 100 on the
EchoStar system. ]
tv://atsc:7.2 [ Tune to ATSC channel 7.2. ]
tv://ntsc:4 [ Tune to NTSC channel 4. ]
4. Provide for network-specific tuning, such as:
bid://abc.com [ Tune to the local ABC affiliate. ]
5. Be able to uniquely address authored streaming content (video
and/or audio) in a globally unique, network-independent, and
transmitter-independent manner, such as:
bid://cocacola.com/new_ad_campaign/12
6. Be able to name discrete data content (as opposed to streaming
video and audio) being broadcast by a network, and *not* available via
the Internet with any known scheme (ie HTTP or FTP), and provide a
globally unique reference to it:
bid://abc.com/nightly_news/tonights_tv_enhancement.html
7. Be able to name standard web content that is *also* being made
available and delivered via some tv data broadcast to local cache:
http://www.wsj.com/headlines.html
[ Note: this item is included for completeness. In fact, we support
for this is already part of the http: standard and we don't have to do
anything. ]
8. Be able to reference an application, both for inter-process
communcations purposes and to provide a default Base URI for contained
UR*s.
9. Be the target of a trigger encoded into the line 21 of the VBI
(which is must carry for broadcasters) of a TV show that loads up a
"jump page" of enhanced tv content that supplements the television
program. In general, be the target of any trigger.
10. It is the year 2002. Fox is broadcasting a World Cup game from
South Korea in both analog and digital formats, with the broadcast
reaching North America, Europe, Africa, Asia, Latin America,
Australia, etc., through a wide variety of local affiliates and
re-broadcast operators. Fox wishes to put a hyperlink to the
broadcast on its web site, so that users of Internet-connected TV
receivers all over the world with the right software (perhaps native,
perhaps downloaded) can click on the hyperlink and have their
receivers tune to the broadcast (or set a reminder for the broadcast,
if the game is not currently on).
11. In the same situation as (10) above, the broadcast is
data-enhanced, with a data carousel module or an encapsulated IP
datagram containing a file which gives up-to-the-second statistics on
goals scored, fouls committed, corner kicks taken, shots at goal,
shots on goal, etc. Fox wants to put a URI on their web site which
references this file, allowing applications on Internet-connected TV
receivers all over the world to get to the file and display it in
nifty ways.
12. In the same broadcast situation as (10) and (11) above, Fox wants
to put hyperlinks to the program and/or data in other data files being
broadcast on the same Fox channel and in other Fox channels, so that
receivers can set reminders for the upcoming game and/or data file.
13. Paramount Productions wants to put on its web site a generic
hyperlink to Star Trek episodes and/or movies. A user of an
Internet-connected TV receiver with the right software can click on
this hyperlink, and the receiver will give the user a mini-EPG showing
the Star Trek episodes and/or movies which the receiver can receive
now or in the near future. The user can then select a current show for
viewing or a future show to set a reminder. This link will identify
_any_ Star Trek-related information: episodes from the Original
Series, the Next Generation, Deep Space 9, etc., as well as movies,
specials, or any other similar material.
14. In the same situation as in (13) above, the producer wants to put
on its web site a hyperlink to the Star Trek: Deep Space Nine series,
and have the mini-EPG show only the current and upcoming episodes of
this series.
15. In the same situation as in (14) above, the producer wants to put
on its web site a hyperlink to each of the episodes which have been
filmed of the Star Trek: Deep Space Nine series. By clicking on one of
these hyperlinks, the user can see a mini-EPG showing the current and
upcoming showings of this specific episode.
16. A local broadcast station is having a promotion in connection with
their weekly broadcasts of Star Trek: Deep Space Nine. It wants to put
a hyperlink on its web site which viewers in its local viewing area
can click on to tune to, or set a reminder for, its broadcast of this
week's episode.
17. A large network, e.g., Fox, wants to put on its website a generic
invitation to watch a particlular one of its channels, with a
hyperlink which viewers anywhere in the world where the network
broadcasts can click on in order to tune to that channel.
18. A local affiliate of the network mentioned in (17) above wants to
put a hyperlink on its web site which viewers in its viewing area can
click on to tune to a particular one of its channels. (It may be
broadcasting multiple virtual channels in the same physical broadcast
band, in the case of a digital broadcast).
19. It is common these days for multiple cable channels to be owned by
the same parent corporation. In the future this may be increasingly
true for terrestrial broadcast as well. In such a situation, consider
the case where the parent corporation wants its multiple channels to
be able to advertise each other, with hyperlinks allowing the user of
a receiver with the right software to click on such an advertisement
appearing in one channel and have the receiver automatically switch to
the advertised channel, or set a reminder to an upcoming show in the
advertised channel.
20. In the same situation as in (19) above, suppose a single
application can operate with the data of any of multiple different
data services broadcast on different channels, for example a ticker
application which can display many different categories of ticker
information. The provider of these multiple different data services
provides along with each service an index which the viewer can use to
select the data service(s) of interest. The application uses the URI
associated with each service in the index to tune to the service(s)
selected by the viewer.
21. The NFL wishes to help people watch the superbowl. It distributes
e-mail (to people who have signed up for such a service) containing a
UR* which they can click on to have their receiver look up when the
SuperBowl is on. Some of the e-mail is sent via the Internet and some
is sent via an "e-mail" channel and received on a TV receiver.
22. Some global brand (Coca Cola for the sake of argument, with the
normal trademark note), wishes to place a URI (maybe as a datagram) in
to be broadcast with the program and displayed as a pop-up, linking to
one or more of:
a) a web-cast infomercial on their site
b) Informercial broadcast separately, for example the previous night,
and locally stored on the receiver's memory.
c) Infomercial broadcast on a separate advertising channel
d) infomercial available on a VOD (or NVOD) channel
23. A sponsor wishes to identify data describing their logo (perhaps
animated) for inclusion in the program guide.
24. A content creator (such as an advertising agency or production
studio) needs to be able to assemble and test a commercial, program or
other material including all UR* references, then be able to
distribute a final tape (whatever) for airing over a variety of
transports (ATSC, DVB, etc.). The point here is that when the UR*s
are locked down, the distribution format(s) is(are) not known.
25. With the advent of powerful computers and software such as Adobe
AfterEffects, just about anyone can become a content creator. Thus,
the naming mechanism must scale to the tens of millions of authors: it
must be globally unique.
26. In the case where a receiver can obtain the same material from two
different sources (e.g., over-the-air and cable), the UR* scheme must
provide mechanisms to:
a) allow the receiver to determine that, in fact, the same material is
being received from both sources (and it can thus use either), or
b) even though the material may appear to be the same, it really is not
and so substitution is not permissible.
In other words, the UR* must not force solutions in this area.
Rather, it must provide the content creators and/or broadcasters the
tools to make the correct distinctions.
27. Some broadcasters may elect to transmit some material in advance
of usage (as opposed to in "real time"). The UR* mechanism should
allow receivers that have such "pre-cached" material to make use of it
while other receivers use the "real time" version from the _same_
reference in the running application . (The pre-cached version may be
pre-rendered for speed or may be transmitted at a higher resolution.)
28. The UR* mechanism should facilitate the recording of a program
with all video, audio, and data streams and subsequent playback.
29. Given (28) the source space of UR*s should be large enough that
UR*s need not be reused. (Since you can't tell when a live data
stream is goign to be mixed with the playback of a previously recorded
one.)
In summary, UR*s reference things transmitted down the broadcast
stream(s). The things that they can reference are one or more
instances of:
a) the tuner output
b) a transmission multiplex
c) a (virtual) channel
d) an event
e) an application
d) data used by an application
...
------------------------------------------------------------
Here are the original messages that the above cases were distilled
from. Messages have been edited to include only the actual examples.
Message-Id: <3.0.5.32.19981215104654.00858db0@cts.com>
Date: Tue, 15 Dec 1998 10:46:54 -0800
From: "Michael A. Dolan" <miked@tbt.com>
Per our telecon this morning, please add the following tv: URI application
scenarios to the official list. Note that the URI examples are meant to
further explain the scenarios by example, and are *not* necessarily meant
as a proposed syntax, or even that all these should be the same URI scheme.
1. Given the use of an HTML-like presentation language, place a tv screen
in an rendering frame, such as:
<IMG SRC=tv:>
2. Provide (1) above, but in addition specify a query mechanism into the
receiver EPG in a technology-independent manner (ie not relying on specific
ATSC, DVB, etc SI fields), such as:
tv://?program=X-Files
3. Provide (1) above, but permit network-specific tuning, such as:
tv://echostar:100
4. Provide (1) above, but permit physical layer tuning, such as:
tv://atsc:7.2
5. Provide (1) above, but be able to uniquely address authored streaming
content (video and/or audio) in a globally unique, network-independent, and
transmitter-independent manner, such as (stealing Craig's example):
bid://www.cocacola.com/new_ad_campaign/12
6. Reference discrete web content (as opposed to streaming video and audio)
being broadcast by a network, and *not* available via the internet with any
known scheme (ie HTTP or FTP), and provide a globally unique reference to it:
bid://abc.com/nightly_news/tonights_tv_enhancement.html
7. Reference standard web content that is *also* being made available and
delivered via some tv data broadcast to local cache:
http://www.wsj.com/headlines.html
Maybe some of these can be combined in a design, and maybe not. For now, I
would prefer that they remain separate scenarios in our list while we sort
through them.
...
--------------------
Message-ID: <315D19FF1819D1118A7E00805F856446E583B7@mail.sonypictures.com>
From: "Chambers, Tim" <tchambers@sonypictures.com>
Date: Tue, 15 Dec 1998 18:57:59 -0800
...
It would be a trigger encoded into the line21 of the VBI (which is must
carry for broadcasters) of a tv show that loads up a "jump page" of
enhanced tv content that supplements the television program.
...
--------------------
Message-ID: <36779BCB.5ACA02DC@philabs.research.philips.com>
Date: Wed, 16 Dec 1998 06:38:51 -0500
From: Aninda DasGupta <add@philabs.research.philips.com>
...
The other two possible uses of URLs are:
- announcement of a future TV show. Placing such announcements on
Web sites and within EPG data carried in broadcast TV content.
- association/binding of "channels" (NTSC channels/frequencies, or MPEG
program within a transport stream) with references to such channels.
- references to any broadcast "object" (data item, video program, etc.)
from anywhere (web pages, broadcast streams, databases...).
This use is truly the universal resource identification function of
URIs, and in many ways a generalization of all uses of URIs that
people have mentioned to me.
...
--------------------
Message-ID: <315D19FF1819D1118A7E00805F856446E583BA@mail.sonypictures.com>
From: "Chambers, Tim" <tchambers@sonypictures.com>
Date: Wed, 16 Dec 1998 09:49:11 -0800
Thanks, this is an example of a project that we're currently working on.
To answer these questions below:
Building with todays tv systems in mind, we are not relying on the
ability to send data on all the lines of the VBI to send URI triggers
*and* web data, which would be the ideal. So we are currently NOT
sending anything but a URI trigger with the TV signal.
This is because the VBI is often stripped out as the signal moves from
the television network (or cable provider) to the local distributor.
There is no clarity over who has the "rights" to the VBI. As I work for
a company that is the copyright holder to many great TV brands, we like
to think that the same way we provide the "traditional content" of the
show, we should be providing the "enhanced content."
Anyway, a solution of sorts to the VBI issue is that line21 has been
deemed "must carry" by the FCC, with the idea of sending closed
captioning there. Thus we send the URI trigger down line21 along with
the captioning, which would send the set top box user to a "enhanced tv
jump page" that is an normal HTML page on our servers. For all of this,
we are planning to use the modem-line backchannel that the set top box
would support.
The ideal would be that a section of the VBI, or later, of the MPEG
stream becomes fully standardized for sending additional data, and that
there are guarantees that this area could not be removed. If that were
the case, we would send everything through the television signal.
...
--------------------
Message-ID: <3677F69C.57503ACE@lgerca.com>
Date: Wed, 16 Dec 1998 13:06:20 -0500
From: Gomer Thomas <gomer@lgerca.com>
...
Actually, I think the kinds of specifics about carriage of URIs in VBI lines
or MPEG tables which Tim is providing are exactly the kinds of specifics
which are needed in a use case. The whole point of a use case is to
understand from a user value perspective what the real requirements are
(where the "user" may be a content producer, a broadcaster, a re-broadcaster,
a receiver manufacturer, and/or a consumer). This requires as much specifics
as possible about context.
I think you have a number of good use cases in mind yourself, but I wonder if
you can provide a little more detail, so that we can truly see what the
business/user/technology context is:
(a) Announcement on a Web site of a future TV show -- Is this the Web site of
a local broadcast affiliate directing viewers to its own broadcast? Is this
the Web site of a national or international network directing viewers to any
local broadcast of its network feed? Is this the Web site of the producer of
the TV show directing viewers to any broadcast of its show by any network or
affiliate? Specific examples would be useful. Is this a WBGH Web site? CNN
Web site? Turner news Web site? MGM Web site?
(b) Announcement within EPG data of a future TV show -- Do you mean the
announcement is in the entry in the EIT or in the ETM (in the ETT) for the
future TV show itself? If not, what assumptions are there about co-location
of the event for which the ETM contains the announcement and the event for
the future TV show? Are they in the same virtual channel? in the same
transport stream? no assumptions? Or does the announcement appear in some way
in the VCT (using some possible future descriptor designed to contain such
announcements)?
(c) Association/binding of "channels" -- Where did the references come from?
What was the business motivation of the source?
(d) References to a broadcast "object" from anywhere -- This sounds to me
like it is clumping together a large number of individual use cases into a
single summary case. I fear a lot of useful insight has been lost in the
aggregation.
This may all sound like it is nit-picking, but the point is that without such
detail one can easily interpret each of the cases in many different ways
leading to many different requirements, some much less stringent than
others.
...
--------------------
Message-ID: <3677FBFA.923D03A4@lgerca.com>
Date: Wed, 16 Dec 1998 13:29:14 -0500
From: Gomer Thomas <gomer@lgerca.com>
...
As I understand it, you are now sending an "http:" URI, which refers to a
resource on a Web server in the usual way. Thus, for your current operations
you do not need a TV URI scheme at all; the already standardized "http:"
scheme works just fine. However, a key feature of that scheme which you are
taking advantage of is that the same URI can be included in line 21
regardless of which local broadcast affiliate or cable provider is carrying
your program. It does not need to be modified to remain valid.
As I understand it, in the future you would like to be able to refer in the
same way to a resource contained in the broadcast stream. I interpret that
to mean -- and correct me if I am wrong -- that (a) you would very much like
to preserve this property that the URI does not have to be modified for each
local affiliate or cable operator who carries your program, (b) you would
like the syntax of the URI to be as similar to the syntax of an "http:" URI
as possible, and (c) in fact, it would be useful to be able to use exactly
the same URI to refer to either an HTML page on a Web server or an HTML page
included in the broadcast, so receivers with a back channel could retrieve
it one way and receivers without one could retrieve it the other.
I am assuming that in your case the actual HTML page would always be
contained in the same channel as the trigger. Please correct me if that is
an incorrect assumption.
A lot of these details may seem pretty picayune, but they are essential to
gain a full understanding of the requirements on syntax and universality of
binding of any broadcast TV URI scheme.
...
Message-ID: <367810B9.A272963@lgerca.com>
Date: Wed, 16 Dec 1998 14:57:45 -0500
From: Gomer Thomas <gomer@lgerca.com>
...
(1) It is the year 2002. Fox is broadcasting a World Cup game from South
Korea in both analog and digital formats, with the broadcast reaching
North America, Europe, Africa, Asia, Latin America, Australia, etc.,
through a wide variety of local affiliates and re-broadcast operators.
Fox wishes to put a hyperlink to the broadcast on its web site, so that
users of Internet-connected TV receivers all over the world with the
right software (perhaps native, perhaps downloaded) can click on the
hyperlink and have their receivers tune to the broadcast (or set a
reminder for the broadcast, if the game is not currently on).
(2) In the same situation as (1) above, the broadcast is data-enhanced,
with a data carousel module or an encapsulated IP datagram containing a
file which gives up-to-the-second statistics on goals scored, fouls
committed, corner kicks taken, shots at goal, shots on goal, etc. Fox
wants to put a URI on their web site which references this file,
allowing applications on Internet-connected TV receivers all over the
world to get to the file and display it in nifty ways.
(3) In the same broadcast situation as (1) and (2) above, Fox wants to
put hyperlinks to the program and/or data in other data files being
broadcast on the same Fox channel and in other Fox channels, so that
receivers can set reminders for the upcoming game and/or data file.
(4) Paramount Productions wants to put on its web site a generic
hyperlink to Star Trek episodes and/or movies. A user of an
Internet-connected TV receiver with the right software can click on this
hyperlink, and the receiver will give the user a mini-EPG showing the
Star Trek episodes and/or movies which the receiver can receive now or
in the near future. The user can then select a current show for viewing
or a future show to set a reminder.
(5) In the same situation as in (4) above, the producer wants to put on
its web site a hyperlink to the Star Trek: Deep Space Nine series, and
have the mini-EPG show only the current and upcoming episodes of this
series.
(6) In the same situation as in (3) above, the producer wants to put on
its web site a hyperlink to each of the episodes which have been filmed
of the Star Trek: Deep Space Nine series. By clicking on one of these
hyperlinks, the user can see a mini-EPG showing the current and upcoming
showings of this specific episode.
(7) A local broadcast station is having a promotion in connection with
their weekly broadcasts of Star Trek: Deep Space Nine. It wants to put a
hyperlink on its web site which viewers in its local viewing area can
click on to tune to, or set a reminder for, its broadcast of this week's
episode.
(8) A large network, e.g., Fox, wants to put on its website a generic
invitation to watch a particlular one of its channels, with a hyperlink
which viewers anywhere in the world where the network broadcasts can
click on in order to tune to that channel.
(9) A local affiliate of the network mentioned in (8) above wants to put
a hyperlink on its web site which viewers in its viewing area can click
on to tune to a particular one of its channels. (It may be broadcasting
multiple virtual channels in the same physical broadcast band, in the
case of a digital broadcast).
(10) It is common these days for multiple cable channels to be owned by
the same parent corporation. In the future this may be increasingly true
for terrestrial broadcast as well. In such a situation, consider the
case where the parent corporation wants its multiple channels to be able
to advertise each other, with hyperlinks allowing the user of a receiver
with the right software to click on such an advertisement appearing in
one channel and have the receiver automatically switch to the advertised
channel, or set a reminder to an upcoming show in the advertised
channel.
(11) In the same situation as in (10) above, suppose a single
application can operate with the data of any of multiple different data
services broadcast on different channels, for example a ticker
application which can display many different categories of ticker
information. The provider of these multiple different data services
provides along with each service an index which the viewer can use to
select the data service(s) of interest. The application uses the URI
associated with each service in the index to tune to the service(s)
selected by the viewer.
...
--------------------
Message-Id: <199812162157.WAA22688@www45.inria.fr>
From: Philipp Hoschka <ph@w3.org>
Date: Wed, 16 Dec 1998 22:57:53 +0100
...
1) Include current TV picture in HTML page
a) Where does HTML page come from ?
a1) Web page is stored on Web
-> URI should be globally unique
a2) Web page exists in broadcast channel only
-> URI must be unique within broadcast channel
a11) Web page transmitted in same channel as
TV picture
a12) TV picture comes from different channel
-> need to name the other channel
b) How is TV picture transmitted ?
a) analog broadcast
b) digital broadcast
b1) ATSC
b2) DVB
b3) ARIB (seperaate system ?)
2) Include object (e.g. applet) transmitted in TV broadcast
in HTML page
a) HTML page is transmitted in broadcast
- analog transmission
- digital transmission
- DVB
- ATSC
- ARIB
b) HTML stored on Web
is this a practical case ?
maybe for "hybrid applications" (like hybrid DVB, hybrid CD-ROM),
but i'm not sure the same business model (if there is one) applies
here
3) Include particular TV program in Web (StarTrek sequel 100)
-> requires naming
-> is this in scope ?
-> can this be
4) Include current IP multicast channel in Web page
-> similar to TV, since this is also a broadcast resource
...
--------------------
Message-ID: <3678FCB5.F4F50E7A@lgerca.com>
Date: Thu, 17 Dec 1998 07:44:37 -0500
From: Gomer Thomas <gomer@lgerca.com>
...
Here are some additional contributions to the use cases, from Jack Lang.
Jack Lang wrote:
> Some additional examples you may want to consider:
>
> In your example (2) some global brand (Coca Cola for the sake of argument,
> with the normal trademark note), wishes to place a URI (maybe as a datagram)
> in to be broadcast with the program and displayed as a pop-up, linking to
> one or some of:
>
> a) a web-cast infomercial on their site
> b) Informercial broadcast separately, for example the previous night, and
> locally stored on the STB's disc
> c) Infomercial broadcast on a separate advertising channel
> d) infomercial available on a VOD (or NVOD) channel
>
> 2) They also wish this link placed on the sponsorship logo in the EPG. The
> sponsorship logo may be animated.
...
Received on Wednesday, 30 December 1998 15:44:51 UTC