IMP: Project Name Change

[Ben Poor]

Dear All,

There has been feedback from members, supporters and broadcasters that the name “RadioEPG” does not properly explain what it does, and may be stopping people from looking into the extensive functionality that it provides.

The name was created because the functionality was initially extending from the DAB EPG functionality. That DAB EPG functionality is itself very heavily influenced from TV Anytime, and has been used as the basis of other projects that need to describe radio services and their programmes. It was also chosen because it was in the same style as RadioVIS and RadioTAG.

As we are looking at registering the names and trademarks, we need to decide if we want to change the name of RadioEPG now.

The reasons for changing it:

• It doesn’t describe (or even suggest) the functionality that is interesting most broadcasters – that is, the switching between broadcast and IP streaming
• Interest in an “Electronic Programme Guide” is quite low, because the majority of radio stations don’t have a strong reliance on “programmes”
• The “programme” part of the EPG isn’t mandatory. You can use RadioEPG just to provide information on a radio station (or group of stations), including logos and straplines. This is more interesting than programme information.

Whilst “RadioEPG” is technically correct, because the EPG includes Service and Programme Information, we could come up with a name that captures peoples’ interest and encourages them to find out more.

Alternative names have been suggested:

• RadioESG – (the ESG is used in Digital TV, for Electronic Service Guide)
• RadioINFO
• RadioLINK

I would please ask you to give your close consideration to this topic. Whilst I personally favour RadioEPG (the EPG to me is a hook, rather than specifically referring to a Programme Guide), I am aware of a large number of you who are not.

I'd like you all to post your feedback here - even if you've done it to either myself or the Steering Board privately. We need to get a discussion going here and rapidly arrive upon a conclusion.

In the first instance - Should we change the name?

If yes - What name should we choose?

Dont feel restricted by the suggestions above. Any left-field ideas are most welcome.

Many thanks,

Ben

[Ben Poor]

Hello All,

Just to remind you that we need to gather proposals for new project names and any split in the functionality (i.e. separating schedules from service following).

I'd like to collect these over the next couple of days. I think deadlines serve a purpose, so I'm going to set one at the end of this week: 17:00 GMT Friday 13th April.

If I dont receive any suggestions by this point I shall conclude that the current project name and structure is the most appropriate. Please feel free to contact me in private or in a public reply to the group. Public is better as this then gets discussion going.

Thanks

Ben

[James Cridland]

On Tue, Apr 10, 2012 at 9:03 AM, Ben Poor <ben....@radiodns.org> wrote:

Just to remind you that we need to gather proposals for new project names and any split in the functionality (i.e. separating schedules from service following).

If I dont receive any suggestions by this point I shall conclude that the current project name and structure is the most appropriate. Please feel free to contact me in private or in a public reply to the group. Public is better as this then gets discussion going.

Here's why it shouldn't be RadioEPG - which is universally understood as an Electronic Program(me) Guide.

"Program(me) guides" are pointless for heavily-formatted commercial music radio. Pointless. I don't care whether Johnny Jock's voicetracked links are between the songs, or Billy Bang, or Sally Songs.

Program(me) guides are also a lot of hard work for stations. It is not a trivial piece of work, nor a "set it and forget it" piece of work, to produce a programme guide. It will not serve the RadioDNS Project well if it looks as though in order to gain the benefits of the RadioEPG application, you need to produce a programme guide. It is simply outside the capabilities of many broadcasters.

And RadioEPG is AMAZING for the future of radio. Station logos; proper station names; descriptions of what the station plays; service following from FM to HD to IP; and the potential in future for links to on-demand programmes. All this genuinely is "set and forget".

This is a marketing issue, and not a technical one. RadioESG or RadioINFO (I prefer the latter) communicates to broadcasters that it isn't just an irrelevant programme guide - it's the glue on which the very future of radio is built. If you can build things with glue. It's *that* important.

A programme guide should be optional; and the product should therefore not be called RadioEPG.

Thoughts?

--
Where new platforms and radio collide: http://james.cridland.net/blog/

Tel: 020 7100 1811 | GTalk: ja...@cridland.net | Twitter: @jamescridland

Web: http://james.cridland.net/ | Google+: http://james.cridland.net/+

Not At All Bad Ltd  |  http://notatallbad.ltd.uk/legal_info/

[Ben Poor]

Thanks James, some good suggestions there.

Just to clarify from my earlier message, and also echoing something James mentioned - we are primarily looking for suggestions for new project names in order to resolve the 'marketing' of what we're trying to achieve.

There were also suggestions for splitting the project into separate elements, one for Programme Guide, the other for Service Following, but this is a separate issue.

Ben

On Wednesday, 4 April 2012 16:08:08 UTC+1, Ben Poor wrote:

[Sebasti...@swr.de]

Hi Ben, hi all,

Many thanks for raising this issue here which we've already discussed a few
times. Indeed I've got a few concerns regarding the current functionality
and naming.

As far as I understand RadioEPG arose from the idea of providing
"schedules". Additionally a solution was investigated how to provide
"service linking" with the same peace of technology. Currently it clearly
looks like the "service" part is much more important whilst the "schedules"
part already became optional.

From the reverse angle we're naming a "service following" specification
"RadioEPG" ... whereas schedules needn't be included. From my (and ARD's)
point of view that's not a good idea.

Germany (and also the public broadcasters here) are currently launching
digital radio. EPG is a good example for our "hybrid approach". We're
already providing schedules using the dab-epg xml-file structure over DAB+
and the IMDA Service Identification. Our main goal is to provide the same
data via RadioEPG also, as we'd then publish identical data over all
important radio technologies ... which gives the device makers the freedom
to choose the most appropriate technology for their receiver
implementation.

Providing RadioEPG with no schedules included would be very strange ... not
only from a marketing pov. Much more important for us is the fact, that
service linking/following is a too important part of radio and a crucial
requirement for the German market so that mixing it up with something else
is completely out of question.

That's why we're proposing to seperate those two parts ... fully aware that
this causes effort although we were all hoping to be close to the finish
line:

1. Exclude the "service" part from the RadioEPG spec and leave the
"schedules" part identical to the dab standard (with its existing pi, si,
gi file structure)

2. Specifiy another piece of technology for the "service" part which can be
called RadioLINK, RadioESG or whatever. This should be a stand-alone
solution for service linking/following in whatever shape we feel is
appropriate (e.g. the current specified XSI file which can be requested via
http/stomp/etc.)

Sorry to bother you all with that fundamental concerns.

Friday 13th for a deadline ... hopefully no bad omen :-)


Kind Regards
Sebastian.

____________________________________

SÜDWESTRUNDFUNK
Zentrale Programmaufgaben HFD

Fon: +49 7221 - 929-24007
Fax: +49 7221 - 929-1824007
Mobil: +49 172 - 103 17 66
mailto: Sebasti...@swr.de

[Ben Poor]

Hi Sebastian,

Thanks for sharing your thoughts.

I'd certainly agree with you that, during the lifetime of the project, the 'Service' part of the specification have become significantly more important that the 'Schedule' part of the specification.

This has raised the question of a project name change, to better market to people. We need something that emphasises the Service linking aspects of the project.

Where I respectfully disagree is the need to separate the two projects - I think that would be a large amount of effort for seemingly little return.

The contents of the RadioEPG specification arose from the need to express non-DAB bearer information within Service and Programme information files. The XSI document was formulated, due to a fundamental change in the structure of the original DABEPG SI document (i.e. the toplevel element in an SI file is a DAB ensemble, which would be inappropriate for our purposes). It was felt that a new document was best in order to provide clarity. 

The PI document format could still be largely kept and extended.

The advantage of doing this is so that both RadioEPG and DABEPG documents could be derived from a common source and lower implementation costs for Broadcasters and Device Manufacturers.

The thing that links the two in some respects, is their use of non-DAB bearer information - i.e. expressing the platforms that services and programmes are available on. Both Service and Schedules rely on this.

I would also be concerned that separating the two part of RadioEPG would be a harder sell to broadcasters and device manufacturers, and make the remaining links between the two sides of the project difficult to explain and maintain.

Given a suitable name, I think the project would still be best served by concentrating on Service information and linking, with an optional part giving functionality for Schedules.

Ben

[James Cridland]

On Tue, Apr 10, 2012 at 9:42 AM, <Sebasti...@swr.de> wrote:

As far as I understand RadioEPG arose from the idea of providing
"schedules". Additionally a solution was investigated how to provide
"service linking" with the same peace of technology. Currently it clearly
looks like the "service" part is much more important whilst the "schedules"
part already became optional.

I think this is a fair overview.

From the reverse angle we're naming a "service following" specification
"RadioEPG" ... whereas schedules needn't be included. From my (and ARD's)
point of view that's not a good idea.

...and I think this is also entirely fair. We shouldn't be naming a specification "Radio EPG" if the programme guide is optional.

Providing RadioEPG with no schedules included would be very strange ... not
only from a marketing pov. Much more important for us is the fact, that
service linking/following is a too important part of radio and a crucial
requirement for the German market so that mixing it up with something else
is completely out of question.

 

That's why we're proposing to seperate those two parts

 

Don't agree, here, Sebastian. Sorry. We've no requirement nor need to separate these parts.

Reading your emails, the only issue you have is that something called "RadioEPG" should include a programme guide ("schedules"). I agree with you. Which is why it is the name that is wrong; not the technology.

If you were to view this from a point of view of marketing:

RadioINFO

- information about the STATION is mandatory

- information about its PROGRAMMES is optional

... then all your issues have been fixed. Programme schedules are a subset of the "info" we're discussing here, though it's clear that the correct station name is also "info" too.

I don't believe we need to split these two projects - indeed, I think it would cause harm if we did so. Our overwhelming requirement here is to encourage as many broadcasters as possible to take part in RadioDNS. If they do not do so, we fail.

If we do anything which makes it harder to implement any of our applications - including adding new ones - we stand less chance of changing the future of radio.

In short: this is not a technology issue. This is purely a marketing one. I am proposing that RadioEPG is renamed RadioINFO to make it clear that the "EPG" bit is not mandatory, and that RadioINFO is more than just a (completely useless in many markets) programme guide.

[Sebasti...@swr.de]

Hi Ben, hi James,

Many thanks for your honest answers ... but I can't acknowledge my defeat
so easily :-)

Ben, you're the RadioEPG team leader so I completely trust you if you say
that seperating those two would yield in large effort with little return.
But this would be a problem of the RadioDNS project ( ... and of your
person. I know - sorry ... I don't want to make your life miserable).
However - I still feel that seperating the specs would be easier to sell at
least to the broadcasters. Please help me out ... I read the spec a few
times but I'm not feeling certain at the moment: If I was a broadcaster
willing to reuse my existing dab epg pi/si files ... what would I exactly
and mandatorily have to change in my files if I'd waive the service linking
stuff and solely focus on the schedules?

James, I don't agree with you either because we have that requirement: I've
brought it in several times :-)

Seriously - I don't think that you (nor the RadioDNS project) should make
decisions for other markets e.g. whether programme information are useless
or not. We both agree that it's a marketing issue. Good ... epg and service
linking are two independant functionalities in dab (which is from my
understanding the only relevant radio broadcasting technology ... besides
fm that unfortunately can't carry pi in the broadcast channel). So I'm
simply proposing that we shouldn't mix both things within our project.
Making epg to a subset is a meaningful decision.

Please be assured that I fully support the goal of the RadioDNS project.
This is exactly what I want to do ... especially looking at the German
market which I'm quite familiar with. I would be keen to learn what would
make the implementation harder for the broadcasters if we'd seperate specs?
Currently I can only see that the implementation is harder when we have a
mutual spec ...

Best
Sebastian.

[James Cridland]

On Tue, Apr 10, 2012 at 12:30 PM, <Sebasti...@swr.de> wrote:

James, I don't agree with you either because we have that requirement: I've
brought it in several times :-)

Seriously - I don't think that you (nor the RadioDNS project) should make
decisions for other markets e.g. whether programme information are useless
or not.

I'm not really making a decision for your market or your stations. Just like the BBC, your programme schedules are very important to you. I'm specifically not telling you that your own programme schedules are useless. I'm also not shunting off programme schedules to a different specification either.

However, I'm also saying that for a heavily formatted commercial radio station that simply has either a voicetracked DJ - or, like JACK fm formats worldwide, no DJs at all outside of breakfast - that a programme schedule is OPTIONAL. It's difficult for smaller broadcasters to implement - some of whom may not have schedules in any format other than a piece of paper in the studio - and schedules for this kind of station are completely irrelevant for consumers. 

In making programme guides optional within the spec - and not calling it RadioEPG - we are allowing ARD, BBC, Classic FM, WNYC etc to publish programme schedules; but Smooth 70s, JACK fm Los Angeles, SBS Chill and other services, which have no "programmes", are not forced to do so.

We both agree that it's a marketing issue. Good ... epg and service
linking are two independant functionalities in dab

They might be. But they needn't be in the IP space. And I'm proposing that they aren't. And, let's remember, we're actually pushing together PI information, service following, and (optionally) programme information, all into one specification. PI information is different in DAB too.

The fundemental point is whether you think EPG information can exist without ESG/PI information? EPG information is moderately useless without some form of station information. On FM, that means an 8-character station name, and precious little else. If ESG/PI information is so simple to set up - it could be done with a simple web form that spits out some XML - then I don't see any benefit to broadcasters to split this information up; and more complex for receiver manufacturers to have to cope with an EPG without the PI info.

I think it's clear that a programme guide is an optional subset of station information. I don't see this being an issue with broadcasters, and am curious to understand why you feel it is.

I would welcome other voices on this matter.

[Sebasti...@swr.de]

Hi James,

Many thanks for your answer which really helps me to understand your view.

Interestingly I don't think that a programme guide is an optional subset of
station information. I think that service information is just a necessary
piece of data to make use of the programme information. But you're
right ... that needn't be the case in the IP-world. However - from my
understanding the RadioDNS project's foundation is broadcasting.

So pushing everything together into one spec is pretty sensible when you're
on a "greenfield". But I'm arguing from a broadcasters position that
already has an evolved production and transmission infrastructure ... e.g.
distributes an epg (si and pi files) for its broadcast transmission. Such a
broadcaster wouldn't like to revise any of the already produced data when
it is so close to an already existing standard. With the current proposal
he has to ... which honestly creates some extra effort (and hopefully Ben
can give us some guidance on how much it really is).

What do the others think ...?

Best
Sebastian.

[James Cridland]

On Tue, Apr 10, 2012 at 2:56 PM, <Sebasti...@swr.de> wrote:

Interestingly I don't think that a programme guide is an optional subset of
station information. I think that service information is just a necessary
piece of data to make use of the programme information.

Ace. So we're agreed that SI is mandatory if we're to have a programme schedule.

We don't appear to agree that a programme schedule might be optional; but I hope you understand my point of view here that for some broadcasters, mandating a programme schedule makes things difficult (and subjects them to unnecessary work).

So pushing everything together into one spec is pretty sensible when you're
on a "greenfield". But I'm arguing from a broadcasters position that
already has an evolved production and transmission infrastructure ... e.g.
distributes an epg (si and pi files) for its broadcast transmission. Such a
broadcaster wouldn't like to revise any of the already produced data when
it is so close to an already existing standard. With the current proposal
he has to ... which honestly creates some extra effort (and hopefully Ben
can give us some guidance on how much it really is).

My understanding - and I'm really only in this from a marketing point of view - is that the programme schedule bit is very, very close to the existing DAB EPG standard; close enough for it to be a two-minute transform. The SI on the other hand is not.

Inevitably, both the SI and the programme schedule bit will continue to evolve; and, since we're mostly dealing with software-defined sets (either apps or firmware-upgradeable devices), the RadioEPG specification, whatever it gets called, will continue to evolve. This makes a change based on "let's copy exactly the information we have on DAB EPG into a frozen specification" short-sighted, in my opinion; it will diverge in time, and I don't understand the benefit we get from complicating matters by splitting SI (which we need for a programme guide) and the programme guide itself.

We haven't really cracked the fundemental issue: what should this be called? RadioEPG is clearly the wrong name...

[Ben Poor]

Hullo All,

Probably best answered with a practical point of view.

Speaking with my broadcaster's hat on (it has a transmission tower on
it), we have managed to fit in RadioEPG into our process with minimal
effort, but the actual level of effort is dependant on how
closely-coupled your information source is to your output.

We (Global Radio) have a set of sources to provide us with Station
information, stuff about platforms and bearers, and schedules.

These we use to output to various places - websites, satellite EPG,
directory service providers (in their many and varied formats), and
DAB EPG. We added to this an output for RadioEPG.

The use of the same XML entities and structures allowed us to use a
common set of tools across DAB EPG and RadioEPG, especially in the
generation of PI files (it is open source too, which is nice). We used
the same tool we had for SI generation *as a basis for* our XSI
generation tool.

Basing the RadioEPG specification on DAB EPG and using common
entities, structures and concepts allowed us a lot of reuse both in
terms of the actual code in generating data and also the logic in the
way that things are done. We couldn't have done this if we would have
started with brand new specification, with entirely different
entities.

Even if I were a broadcaster with an entirely closed EPG chain, such
that all I have is a bunch of binary DAB EPG PI and SI files, it would
still be possible to take these, add the necessary information to them
and regenerate to the necessary XML files for RadioEPG. Again - there
are freely available tools to help you do this.

Ben

[Ben Poor]

> My understanding - and I'm really only in this from a marketing point of
> view - is that the programme schedule bit is very, very close to the
> existing DAB EPG standard; close enough for it to be a two-minute transform.
> The SI on the other hand is not.

Just a slight important clarification, but one thats important to keep in mind:

*You **can** keep the exact same PI file as you do for DAB EPG*. This
is because if no bearers are specified in the PI file, bearers will be
inherited from the SI file in DAB EPG and the XSI file in RadioEPG.

The XSI file is very close to the SI file format - services are placed
inside a <services> element rather than an <ensemble> element and so a
simple XML transform can produce XSI from SI (or vice-versa).

Ben

[Sebasti...@swr.de]

Hi Ben, hi James,

Thanks for this good discussion so far ...

>> Ace. So we're agreed that SI is mandatory if we're to have a programme
schedule. We don't appear to agree that a programme schedule might be
optional; but I hope you understand my point of view here that for some
broadcasters, mandating a programme schedule makes things difficult (and
subjects them to unnecessary work).

Yes - absolutely. We should keep the hurdles as low as possible and avoid
unnecessary work. So we shouldn't force anybody to provide a programme
schedule if he or she doesn't want to. But that doesn't exclude my
proposal. I also don't want to force anybody to provide anything
unnecessary. Quite the opposite ... I'm proposing to let everybody use the
'old and untouched stuff' except he or she wants to do more ... because ...

>> Inevitably, both the SI and the programme schedule bit will continue to
evolve;

I'd also agree. However - do you really feel that the programme schedule
will continue to evolve ... given that it seems not so important for the
majority of us than the XSI and service linking bit? So following the
opinion of our IT department when it comes to hardware procurement I'd say:
"one function per device" ... i.e. "one function per spec" in our case.
Assuming that it'd make things less complicated as we can then evolve one
bit without necessarily adapting any changes within the other bit (which
would probably also require e.g. my company to do unnecessary adaptions).

>> *You **can** keep the exact same PI file as you do for DAB EPG*. This is
because if no bearers are specified in the PI file, bearers will be
inherited from the SI file in DAB EPG and the XSI file in RadioEPG.

Many thanks for that. So I understand we can reuse our existing dab-epg
pi-files without changing anything (with the restriction that the bearer
info on pi-level would be impossible then) and only would need to revise
our existing si-file to an xsi-file (which is the two-minute-work). I also
understand that the big effort in splitting the specs would reside in
reproducing/emulating the bearer info on pi-level. Is that right?! The
reproduction of the bearer info on global level (i.e. how it's currently
done with the xsi) would be a minor task out of my understanding. Is that
also correct?!

Best
Sebastian.

[James Cridland]

So following the
opinion of our IT department when it comes to hardware procurement I'd say:
"one function per device" ... i.e. "one function per spec" in our case.

I still don't understand the requirement to split the specifications, and struggle to understand why printer procurement is relevant to this discussion. More importantly, we're no further down the line of "is RadioEPG a good name" - I don't believe it is - but this continued religious discussion about splitting specs (which will add complexity and confusion, which is why I am resisting it) will get us nowhere.

Sebastian, it's clear you feel strongly about this for some reason, and apologies that I haven't fully understood the reasons why. The Steering Board meets next week, and I'd be happy to help escalate this discussion if you want to do that.

//j

[Ben Poor]

Echoed, I wouldn't characterise splitting the spec as a 'big effort' (sorry, I probably was not careful with my language before), but it would certainly be effort for no obvious reason (to me at least).

In my mind the two parts of RadioEPG have enough links to keep them in the same spec. Splitting them off looks like unecessary work to me. XSI mandatory, PI optional, but since the two speak the same base language and are involved in the same area of functionality we keep them together.

If I were to draw comparisons with DAB EPG, I would be puzzled if the SI file format was in one project and the PI file format was in another.

Ben

[Ben Poor]

Hi All,

As regards the issue of project name, I would say we need a change of name, and I'd like to put my support forward for...RadioESG

My reasons for this are:

* It describes the function - Electronic Service Guide.

* It is a known acronym, as its function is understood

* It is 3 letters - small point, but consistency is a good thing

* It is not a name used commonly elsewhere - obviously it would benefit the project to be the most prominent use of the name.

I've separately thought about alternatives, but none were forthcoming. However, I think this name accurately describes the project and so I am satisfied that I'm not compromising...

Please do all get involved - let us know whether you agree or disagree, and whether you have any ideas yourself.

Ben

[James Cridland]

Agree. +1. Me Too.

ESG is already a known description for this function in digital television, and encompasses tuning in to a service using either channel name or programme name. It looks entirely consistent with the aims of the project. RadioESG works very well here, and doesn't scare those who think they need optional programme schedules.

I don't like TLAs, but I think consistency is a good thing.

(True story - when I last worked for a big company, I asked my team to stop using three-letter-acronyms completely, and tried to institute a TLA-swearbox. This worked for a very short amount of time, until one of my team members pulled me over and broke it to me, softly, that I worked for... the BBC.)

[Sebasti...@swr.de]

>> I still don't understand the requirement to split the specifications

You say that it adds more complexity and confusion if we split things (now
and in the future). I say that it's probably vice versa ... and I'm trying
to find out whether my feeling is right or wrong and to understand where
complexity or problems could occur. Apologies that I failed to make that
clear to you. But I don't see that this is religious!

Back to the naming ... I'm fine with RadioESG. The spec incorporates
'service linking' and 'epg' functionalities (whether optional or not). So
any name should reflect both. RadioESG seems to fit best ...

Best
Sebastian.

[Ben Poor]

Cool, so thats +3 for RadioESG so far.

Do any others of you on the list want to give your opinions? I know you're out there...I can see the member list :)

Some of you may be aware that the most important thing in any project / software / business is its name, so lets all try and get it right!

Ben

[Dylan Jones]

+1 ESG

Thinking of what a digital Radio Times does, it makes sense that you need to know service information first and then, if available, programme information. 

Dylan

[Ben Poor]

"Other publications are available"

A little British humour there. For our non-UK friends, the Radio Times was/is a very well-known magazine publication giving channel listings, and has successfully transitioned this model to the online world.

Thanks Dylan, that makes it +4, which coincidentally is also a marvellous piece of clothing for playing Golf.

[Ben Poor]

Hello All,

I've received 4 nominations for RadioESG and none for anything else, or any usable alternative names.

Therefore I will be writing to the RadioDNS steering board this morning to inform them that our recommendation for project name will be: 

RadioESG

Where ESG will be described as standing for Electronic Service Guide.

Many thanks for all your input.

Ben