RadioEPG for other broadcast platforms

[Nicholas Humfrey]

Hello,

I am looking at how RadioEPG, in particular Service Information, can be
represented as RDF. I hoping that this will then be fed up to the
schema.org specifications, so that Radio Station properties can be
described to search engines. Another goal would be automatic tuning of
radio stations on phones, based on metadata in the page.


However given a service information file, I am not sure this can be used
for reverse-lookup and tuning of a radio tuner for all services? I guess
this doesn't matter as much for systems where frequencies are scanned
automatically (DAB) - although might allow faster seeking if the frequency
is known.

For FM, given: fm:ce1.c201.09710
A frequency of 97.1 can be extracted fairly easily.


I can't find an example of a brearerId for IBOC/HD radio. And I am not
sure how to construct a country code for the US (I presume it isn't an ISO
3-character country code) - does anyone have any real examples?
hd:1a0.21920


However, the human readable references to stations I have seen have been
based on the frequency and channel number - 88.5-1. Which I presume means
you could seek to that much faster?


Thoughts?


Thanks,

nick.

[Evain, Jean-Pierre]

Hi Nicolas,

I believe quite substantial work has been doen in schema.org already derived from TV-Anytime also used for the DAB EPG.

This is work done in collaboration between EBU (me) and BBC (Yves Raimond) a few years ago.

We introduced the notions of radio and tv programmes (going beyond the pre-existing series and episodes which we thought was retricting TV and radio content too much:-)

We also brought in the publication event and publication service, which offers all the basic structure of an EPG.

This has been released by schema.org I would say at least 3 years ago?

best regards,

Jean-Pierre Evain, EBU
________________________________________
From: radioepg-...@googlegroups.com [radioepg-...@googlegroups.com] on behalf of Nicholas Humfrey [nicholas...@bbc.co.uk]
Sent: 08 August 2016 17:53
To: RadioEPG developers
Subject: RadioEPG for other broadcast platforms

--
You received this message because you are subscribed to the Google Groups "RadioEPG developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************

[Nick Piggott]

Hi Nick,

Those are good questions.

An FM station ought to be uniquely described by it's PI+ECC codes, but due to real-world implementation issues, some services also need to optionally include their frequency information.

Frequency was included in the SPI document for two reasons:

* To differentiate services in situations where the same PI code has been issued to different services (which shouldn't happen, but has *shrug*)

* As a secondary benefit - a hint to the receiver for frequencies to check for that service.

The benefit of the hint is to speed acquisition. A pragmatic approach might be to put the frequencies of the 10 transmitters that cover the majority of the population, which might speed up finding that service for the majority of people.

If a broadcaster knows their PI code is unique (within their country), they ought to have a wildcard service entry, where the frequency is specified as "*". This tells the receiver to then check all the other potential channels (out of 200 in the European FM band, 100 in the US) for a service with a matching PI code. (If the wildcard isn't provided, the other channels won't be searched).

In DAB, services are uniquely described by their SId + ECC codes, so frequency isn't needed to differentiate them. However, we do include EId (ensemble ID) as a way of differentiating between services, even though strictly speaking, SId+ECC is sufficient. (Again, as a response to real world implementations).

HD uses an identifier format designed by DTS (formerly iBiquity) which is part of their proprietary documentation. There is a globally unique "facility identifier" transmitted in the HD signal, that doesn't need any country information. We'd need to talk to DTS about whether they'd make that information open for the purposes of inclusion in schema.org. HD services are based on a multiplex transmitted on an existing FM frequency, which was originally intended to be a bundle of services related to the main FM service (indeed, the HD1 service must always be a simulcast of the analogue service, if present). Over time, this has changed, so it would be as legitimate a navigation model for a receiver to scan all frequencies and acquire service labels, and present them in a list without reference to frequency (as DAB does), but I don't believe that's permitted in current HD radio receiver implementations (?). So essentially frequency is included in the reference to HD stations to help *humans* navigate a dial by frequency, rather than a way of identifying services. (The forthcoming addition of FM translators ("relays" in European parlance) of HD services complicates the situation slightly). 

Generally, we haven't rested too much weight on frequency information (other than where necessary to differentiate services). It's a helpful byproduct in SPI that you can get hinting of where to look, but that wasn't the original intent.

When I've spoken with DAB manufacturers about the value of frequency hinting information (either in SPI or via the FIG0/21 mechanism in DAB), they've said they would generally not use it, preferring to rely on the results of a recent (background) scan of received services. That seems to be the trend?

Nick

 

[Nicholas Humfrey]

Hello Jean-Pierre,

This is about Services / Stations, rather than Programmes. And more
specifically the Bearer.

It came out of the proposal to be able to add broadcastFrequency to
BroadcastService:
https://github.com/schemaorg/schemaorg/issues/1004


I believe this is a mistake and doesn't work well for digital services. I
think an extra level of indirection, by adding a BroadcastBearer class
will allow it to work for a lot more scenarios.


nick.


On 09/08/2016 08:52, "radioepg-...@googlegroups.com on behalf of
Evain, Jean-Pierre" <radioepg-...@googlegroups.com on behalf of

[Evain, Jean-Pierre]

Hi Nick,

I haven't been following this for a while ;-) Thanks for the link, interesting.

Welcome to schema.org. I hope you'll be able to get what you need.

I also read you want to convert the EPG schema to RDF. Actually I would do this independently from schema.org, which is just (as far as I am concerned) a format for publication.

Best regards,

Jean-Pierre

________________________________________
From: radioepg-...@googlegroups.com [radioepg-...@googlegroups.com] on behalf of Nicholas Humfrey [nicholas...@bbc.co.uk]

Sent: 09 August 2016 11:52
To: radioepg-...@googlegroups.com
Subject: Re: RadioEPG for other broadcast platforms

[Nicholas Humfrey]

Thank you for your very detailed response Nick. It is very helpful.

One of the big differences between SPI / RadioDNS and schema.org is that SPI has some specific applications in mind, which the data model was designed for. The definitions of Service and Bearer are fairly loose, whereas the correct usage of the values is well defined.

In contrast schema.org defines the semantic meaning of the terms and properties but doesn't tell you how or what to use them for. For that reason I am tempted to include the ability to specify both the frequency and identifier information, as it usage is likely to vary based on application.

nick.

From: <radioepg-...@googlegroups.com> on behalf of Nick Piggott <nick.p...@radiodns.org>
Reply-To: "radioepg-...@googlegroups.com" <radioepg-...@googlegroups.com>
Date: Tuesday, 9 August 2016 10:48
To: RadioEPG developers <radioepg-...@googlegroups.com>
Subject: Re: RadioEPG for other broadcast platforms

--

You received this message because you are subscribed to the Google Groups "RadioEPG developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

[Nick Piggott (RadioDNS)]

Hello,

I think it's sensible to include frequency.

I do need to throw in a potential curveball, courtesy of the RDS specification.

There are rules around how to interpret RDS PI codes, based on the value of the second nibble.

If you look at a service like Heart Bristol in the UK, when all the three FM transmitters are carrying the same programme, they all transmit the code 0xC36B. During ad-breaks, when they're all transmitting different ads, they use the codes 0xC36B, 0xC46B, 0xC56B. (You can see this in the SI file for Heart Bristol  - http://epg.musicradio.com/radiodns/spi/3.1/SI.xml)

I don't know how that affects the definitions, other than to say that Heart Bristol, depending on time of day, can be using code 0xC36B or 0xC46B or 0xC56B, and the rules of RDS tell you that the services are "related" because the first, third and fourth nibbles are the same value (and the second nibble is in the value 3-F).

Nick

--

Nick Piggott

Project Director

RadioDNS

www.radiodns.org // @radiodns // +44 (0) 1600 888335 // +1 (850)-888 8335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 96a Curtain Road, LONDON, EC2A 3AA.