broadcast-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (roaceltrocba)
Line 1: Line 1:
bolitaracla
= Brainstorming for a Broadcast Microformat =
= Brainstorming for a Broadcast Microformat =



Revision as of 18:57, 3 January 2009

bolitaracla

Brainstorming for a Broadcast Microformat

This is a brainstorm for Internet radio and TV streams i.e real-time streams corresponding to radio and TV stations rather than individual items or collections of content (as currently proposed for hAudio).

The scope could also encompass broadcast radio and TV if this is considered to be useful in an Internet context.

Examples can be found here broadcast-examples

Contributors

The Problem

The web provides an alternative transmission medium for radio and TV stations, enabling these to reach a global audience. New Internet-only services have also appeared. A large number of services are now available and there are many web-based directories listing Internet radio and TV stations under various categories. These directories have to be maintained by hand because the information cannot easily be collected automatically from web sites. The information these directories provide is not easily extracted by web browsers and devices such as Internet Radios.

Elements that come up often in practice

The metadata is either general information (e.g. station name) or technical information (e.g. bandwidth)

General information

  • Station name (could use hCard's "organization-unit")
  • Broadcaster (could use hCard's "organization-name")
  • Description (could also be hCard's "note")
  • Image URL (logo) (could use hCard's "logo")
  • Category (genre) (could use hCard's "category")
  • Language (used by the station rather than for the description)
  • Location (could use hCard's "adr" & children)
  • Station website (could use hCard's "url")
  • Station email (could use hCard's "e-mail")
  • AM/FM frequency (could use "measure" microformat)
  • Rating (hReview?)
  • "Now playing" information (could use hAudio and hVideo)
  • Schedule information (could use hCalendar)

Technical information

  • stream URL - the direct URL of the stream (.wma, .ra, etc) or the stream's metafile (.asx, .ram, etc)
  • player URL - the URL of a webpage with an embedded media player which plays the stream
  • bandwidth (could use the "measure" microformat)
  • codec (MIME types may be of use here)
  • delivery - optional. unicast | multicast

Issues

  • Some way is needed to distinguish between radio and TV stations (Most examples don't explicitly distinguish between them).

Possible approaches

New microformat

Define a broadcast microformat.

As with hAudio we could consider splitting content information from format information i.e. define a stream format microformat:

  • hStream (hstream)
    • type optional. MIME type using the "type" attribute of the <a> element
    • bitrate optional. using measure
    • delivery optional. unicast | multicast

Example:

   <a class="hstream" type="audio/vnd.rn-realaudio" href="http://www.bbc.co.uk/radio1/realaudio/media/r1live.ram">
   Real Audio (<abbr class="bitrate hmeasure" title="196608 bit/s">192 Kbps</abbr>, <span class="delivery">multicast</span>)</a>

Extend scope of hAudio and hVideo

Depending on the degree of overlap between the required metadata fields it may be practical to extend the scope of the proposed hAudio and hVideo microformats. However, it would not be beneficial to the development process, or to end-users, if this adds additional complexity.

Use RDF

The potential number of publishers of this information seems fairly small. (Broadcast licences aren't handed out like candy, but sold for enormous amounts of money to, in practice, a fairly small number of organisations.) Most of the publishers are going to be well-financed either by government or commercial interests, so are likely to have large web publishing teams of experienced designers, programmers and system administrators. The "newbie factor" is less relevant here, so the barrier to entry for RDF is lowered.

RDF is not a format, but a set of concepts which can be serialised in several standardised formats, including RDF/XML, eRDF, RDFa, Turtle, RDF/JSON, etc. An example of describing broadcast information using RDFa embedded in HTML is:

<div xmlns:tv="http://example.com/schema/tv#" typeof="tv:Station">
  <h1 property="tv:stationName"><span property="tv:broadcaster">BBC</span> One</h1>
  <p property="tv:description">Public service broadcaster based in the
  <span property="tv:location">United Kingdom</span>.</p>
  <p>Link: <a href="http://www.bbc.co.uk/bbcone/" rel="tv:url">http://www.bbc.co.uk/bbcone/</a>.</p>
  <p>View: <a href="http://www.bbc.co.uk/iplayer/" rel="tv:playerUrl">http://www.bbc.co.uk/iplayer/</a>.</p>
</div>

This could easily be combined with hCard too:

<div xmlns:tv="http://example.com/schema/tv#" typeof="tv:Station" class="vcard">
  <div class="fn org">
    <h1 property="tv:stationName" class="organization-unit">
      <span property="tv:broadcaster" class="organization-name">BBC</span>
      One
    </h1>
  </div>
  <p property="tv:description" class="note adr">
    Public service broadcaster based in the
    <span property="tv:location" class="country-name">United Kingdom</span>.
  </p>
  <p>
    Link:
    <a href="http://www.bbc.co.uk/bbcone/" rel="tv:url" class="url">
      http://www.bbc.co.uk/bbcone/
    </a>.
  </p>
  <p>
    View:
    <a href="http://www.bbc.co.uk/iplayer/" rel="tv:playerUrl" class="url">
      http://www.bbc.co.uk/iplayer/
    </a>.
  </p>
</div>

Allowing specialist TV-station software to be able to parse the RDF information out, while naive generalist parsers would simply see an hCard, giving them access to most of the same information, but perhaps in lesser fidelity. That is, the RDF parser will understand that the thing being described is a TV station, whereas the hCard parser will only be able to identify that it's an organisation; the RDF parser will know which URL is intended for general information on the station and which is for viewing programmes, the hCard parser will simply see two URLs.

RDF (especially RDFa) offers a good general purpose solution for marking up this kind of specialist information - information which might be too specialised to justify its own microformat. It can easily be combined with microformats, as per the example above, offering a good hybrid solution.

Combining with other microformats

Examples of how a broadcast microformat could be combined with other microformats.

hAudio & hVideo

"Now Playing" information could be provided using hAudio for radio (e.g. to represent the current song) and hVideo (e.g. to represent the current film) for TV.

hCalendar

An event or a schedule of events for a channel could be signalled using vEvent or hCalendar as child elements.

hCard

Broadcaster / station details could be marked up with hCard.

<div class="vcard">
 <div class="adr">
  <div class="org fn">
   <div class="organization-name">BBC</div>
   <div class="organization-unit">One</div>
  </div>
  <div class="country-name">UK</div>
 </div>
 <div class="category"><a href="http://en.wikipedia.org/wiki/Mixed" rel="tag">Mixed</a></div>
 <img class="logo" src="http://www0.rdthdo.bbc.co.uk/services/api/res/images/BBCOne_small.gif" 
  alt="BBC One" />
 <a class="url" href="http://www.bbc.co.uk/bbcone/">BBC One Homepage</a>
</div>

Measure

A proposed measurement microformat could be used for the frequency.

hReview

Rating could be marked up using hReview.

Comments

The fields listed under technical information are common to the proposed but moribund file microformat proposal.

Related Pages