Add broadcastFrequency to BroadcastService to specify the over the air frequency

[vickitardif]

Authors have the ability to specify the channel a radio/TV broadcast uses on a particular service, but there is no way to specify the over the air frequency (e.g. 107.5 MHz for a radio station or 66 MHz for TV).

BroadcastService should have a "broadcastFrequency" property allowing either TEXT or a QuantitativeValue.

[vickitardif]

See pull request #1019

[danbri]

Sounds plausible to me. All your examples are unitCode "MHZ", looking at https://github.com/schemaorg/schemaorg/pull/1019/files ... what other codes are potentially applicable?

I was wondering - would the mixed-case "MHz" be more conventional? But according to /unitCode and the subset/excerpt at http://wiki.goodrelations-vocabulary.org/Documentation/UN/CEFACT_Common_Codes ... it seems 'MHZ' is correct. I'd suggest including "MHZ" (and any others) in the property definition, to avoid people chasing around downloading UN/CEFACT spreadsheets.

[danbri]

nearby, but this stuff always confuses me, http://www.vlf.it/frequency/bands.html

[danbri]

I pinged Yves Raimond @moustaki on Twitter https://twitter.com/moustaki/status/710151533279576064 who responds:

":-D That looks great! I wonder if we might need something extra for e.g. DVB-S - @njh do you know?"

(... where @njh conveniently has the same nick on Github; hi :)

If this is to cover TV too, we ought to get another example added for that (later if not immediately)

[njh]

Hi!

Yes, digital broadcast systems are a bit more complex than analogue - need various broadcast parameters, not just the frequency. For TV, the Local Channel Number / LCN could be useful but you also have to describe the service that it is being broadcast on.

Describing this kind of thing for Radio has been done in this ETSI specification:
http://www.etsi.org/deliver/etsi_ts/102800_102899/102818/03.01.01_60/ts_102818v030101p.pdf

Which the BBC publishes its FM and DAB services here:
http://radio-service-information.api.bbci.co.uk/radiodns/spi/3.1/SI.xml
(I would love to convert this to JSON-LD)

This is something that also isn't handled very well in the BBC's Programme Ontology but it is something that Tom Grahame is looking into. So not a simple answer but I would say that ideally there would be a lot more to describe this type of thing with schema.org.

It would be fantastic to be able to use this to go from Broadcast <-> IP and back.

nick.

[danbri]

Thanks @njh. #1019 is the current basic proposal from @vholland - I believe it was only intended to address analogue scenarios at this stage. Can you see a path towards doing something simple now and evolving it to become more expressive over time? I'd like to understand whether we should plan to merge this into the next release, or postpone it for further discussion / tweaks.

[njh]

If you can add an 'bearer' entity type, then it should give enough flexibility to model various different distribution types.

How about something like this ?

@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix s:     <http://schema.org/> .
@prefix bbc:   <http://www.bbc.co.uk/services/> .

bbc:radio4 rdf:type s:BroadcastService;
  s:name "BBC Radio 4";
  s:bearer [
    rdf:type s:FMRadio;
    s:frequency 93.5
  ] .

I think the Modulation type ("FM") is more important than the band or frequency unit.
Creating a bearer type of 'FMRadio' would imply a unit of MHz and modulation type of Frequency Modulated.

[danbri]

@vholland can you take a look?

We'd need the names to be more broadcast-oriented since schema.org is a (big) flat namespace.

Looking for information about analogue to digital switchovers I only found https://en.wikipedia.org/wiki/Digital_switchover_dates_in_the_United_Kingdom ... which seems only about TV and not radio. I understand we are covering both here.

Can we usefully add broadcastFrequency immediately (this/next week) and work out this more complex multi-term addition with more time for research?

[njh]

Yup, changing terminology should be straightforward.

I am sure just having broadcastFrequency would be useful to someone - although not certain of the application.

Wether it is worth releasing this, with the knowledge that the data would have to change in a future, I don't know...

[vickitardif]

I don't understand the question.

At least for terrestrial radio, broadcastFrequency is useful. For other types of broadcast (TV and satellite radio), we may need other properties. We can probably work on those in a subsequent release.

[chaals]

broadcastFrequency is useful, if we know the units.

@njh, if we know the broadcastType - FMradio, VHFanalogueTV, FancySatelliteServiceWithOwls - for modelling the things that we know will we have to add anything in the future, or is it just a question of adding information for new types of service?

[njh]

Typically Radio and TV broadcasts will be transmitted on multiple frequencies, protocols and mediums.
And it is useful to be able to associate extra information to the broadcastFrequency property - therefore I think it makes a lot of sense to have a new entity type 'BroadcastBearer', which can be used to gather these properties together. Examples would be AM/FM, frequency units, RDS identifiers, transmitters...

I guess it would be possible to start with just having a broadcastFrequency with a unit of kHz.

BBC Radio 4 is on around 50 FM frequencies and a smaller number of AM frequencies.

Using Absolute Radio as a smaller example:

• 92.5 Mhz = 92500 kHz
• 105.8 MHz = 105800 kHz
• 1215 kHz

For typical services, it could be inferred that the higher frequencies use Frequency Modulation and the lower frequencies using Amplitude Modulation.

[chaals]

For typical services, it could be inferred that the higher frequencies use Frequency Modulation and the lower frequencies using Amplitude Modulation.

Yes. But I would rather not rely on such inferences - what happens when someone tries to describe TV signals, or amateur radio?

[njh]

Yup, I agree. That is why I think a new entity type is needed.

[mfhepp]

Why don't you use http://schema.org/QuantitativeValue as the range for the frequency property?

This will allow any common unit of measurement (kHz, MHz, GHz have UN/CEFACT Common Codes) and you can attach additional meta-data like modulation details either via

• the description property,
• via http://schema.org/valueReference pointing to a http://schema.org/QualitativeValue, or
• via http://schema.org/additionalProperty

It's all there, thanks to the GoodRelations meta-model inside ;-)

Martin

PS: Note that modulation can mean a whole lot more than just FM vs. AM for your local radio station; think of SSB or digital modes in ham radio or see https://en.wikipedia.org/wiki/Modulation.

---

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 06 Apr 2016, at 17:21, Nicholas Humfrey notifications@github.com wrote:

Yup, I agree. That is why I think a new entity type is needed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[vickitardif]

I don't understand. The pull request does use QuantitativeValue.

[mfhepp]

@vholland
Sorry, I just saw the example above in which the frequency is a plain literal. But my other points re representing modulation and other additional characteristics hold

BTW, you set the range to QuantitativeValue OR Text - why not Number?

[vickitardif]

I am fine with adding Number, but used Text because many stations in the US use values like "107.5 FM or 1030 AM".

[njh]

The problem with using a text value of "107.5 FM" is that it stops being structured data.
It is no-longer possible to use the data to find all the radio stations on FM without parsing the text.

Or automatically tuning the receiver in your phone based on the data on the website...

[chaals]

Yeah, I'd like to have enough structure so we don't expect to have to parse text for straightforward cases.

[vickitardif]

I updated pull request #1019 to include a BroadcastFrequencySpecification where one can specify the value and modulation of the frequency. An example would be:

<script type="application/ld+json">
{
  "@context":"http://schema.org",
  "@type":"BroadcastService",
  "name": "WBZ-AM",
  "broadcastDisplayName": "WBZ NewsRadio",
  "broadcastFrequency": {
    "@type": "BroadcastFrequencySpecification",
    "broadcastFrequencyValue": 1030,
    "broadcastFrequencyModulation": "AM"
  }
}
</script>

[mfhepp]

Note that in some contexts of radio frequency transmissions, "broadcast" is too specific a term. broadcasting is one form of transmission, but not the only one. For instance in ham radio and likely other forms of radio communication, broadcasting is typically not allowed as a form of RF transmission.

We might want to model the whole approach on the basis of terms applicable to a broad set of radio frequency transmissions so that it will also fit ham radio, Internet-of-Things, geocaching, radio navigation beacons, etc.

Also, "broadcastFrequencyModulation" is not a really good name, because it is not always the frequency of the carrier that is being modulated, but it can also be a multitude of other aspects. On-off keying turns on and off the carrier wave, phase-shift keying changes the phase of the carrier wave, etc.

In fact in your example of an AM station, it is the amplitude and not the frequency of the carrier wave that is modulated.

And where is the unit in broadcastFrequencyValue? It can be kHz, MHz, GHz at least.

So maybe just RadioFrequencySpecification
with
radioSignalFrequency Number of QuantitativeValue
radioSignalModulation Text or QualitativeValue

?

[vickitardif]

I updates to add QuantitativeValue and QualitativeValue as suggested and renamed broadcastFrequencyModulation to broadcastSignalModulation.

I disagree with using 'radio' in the names as this may apply to over-the-air television as well.

See the updated pull request #1019

[danbri]

broadcastSignalModulation seems an improvement.

Let's acknowledge that this piece of work is not going to give us a general representation for all use of radios - ham radio isn't covered; radio telescopes aren't covered, and so on. These are being introduced as properties of BroadcastService ("A delivery service through which content is provided via broadcast over the air or online."). Can we review the current state of #1019 given that as context?

[gmackenz]

Looking good Dan. We guess we should complete the common range of specific types to include DABRadioChannel, DRMRadioChannel and IBOCRadioChannel (aka FM HD in the USA)—do we need a ShortwaveRadioChannel?

A naive question—does this lend to a potential denormalization as the data for the broadcast transmission's frequency and modulation data will be in both (or either) broadcastFrequency and hasBroadcastChannel?

I believe we still want to add the ability for a complete breakdown of the frequency into it's components beyond broadcastFrequencyValue (as per the conversation above I had with Thad and Martin above) by adding broadcastFrequencyChannel (expects Integer or QuantitativeValue) and should there be a broadcastFrequencyModulation property that uses the ITU codes?

[danbri]

@gmackenz - re (de)normalization, it isn't so unusual for schema.org to support a quick/shortcut idiom and a longer more explicit, detailed and extensible variant. We do that with http://schema.org/openingHours vs http://schema.org/OpeningHoursSpecification, for example. It works best when the equivalences are explicitly spelled out. We've also long said that sometimes we take a string in place of a structured entity in the spirit of "something is better than nothing".

[danbri]

/cc @moustaki especially re any TV/Radio differences (following on from #329 which was TV centric, here we are radio-centric)

[njh]

@gmackenz I was thinking that AMRadioChannel would cover all of Short wave, Medium wave and Long wave. Some radio receivers allow you to chose a tuning band, but I believe most analogue receivers just switch between AM (in kHz) and FM (in Mhz) now - it certainly makes it easier for the user. Services are typically advertised in the UK as something like "1287 AM". I think it is good for publishers to be able to use micro-syntax to allow them to publish the basics, even if they don't know how to create the more complex structures (as would be required for my super-complex Radio 4 example).

I think the broadcastFrequencyModulation information is covered by having seperate classes of radio channel types. Although the ITU code could be referenced in the description of the class for clarity.

More useful than the frequency information are the identifiers for the broadcast, so that tuners can find a radio service, even if they are closer to a relay transmitter on a different frequency.

[gmackenz]

I'm good with this @njh & @danbri .

[thadguidry]

@danbri if you don't mind, a slight tweak (for iot needs later) on description to BroadcastService ?

A delivery service through which content is provided via broadcast over the air, online, etc

then I'm good with what I see in pending.

[danbri]

Noting as b/g, http://www.cbc.ca/beta/news/world/norway-fm-radio-switch-off-digital-1.3923612

[ghost]

broadcastFormat would also be useful, ie: dvb-t, dab, dab+, dvb-t2, dvb-s2, FM, AM, HbbTV V2, etc.

…

On Sat., 7 Jan. 2017, 11:39 pm Dan Brickley, ***@***.***> wrote: Noting as b/g, http://www.cbc.ca/beta/news/world/norway-fm-radio-switch-off-digital-1.3923612 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1004 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFdABm9UPxA0_cGkoXGG3HZcuJDiLdggks5rP4eJgaJpZM4Hfssz> .

[thadguidry]

@mediaprophet Timothy, I am hesitant to use the term Format in there....and would prefer Mode instead. The reason is because within a broadcastMode like DAB+ there could be multiple formats used, like MPEG2 and AAC+ .... this is technical level stuff that doesn't really apply to regular consumers of Schema.org but in choosing Mode or some word that signifies higher level abstraction it would allow a nice base for Schema.org extentions later that want to deal with the lower level stuff of Formats and even the protocol stack layers of the Modes themselves like the encoding, error correcting, data link layers, etc.

[thadguidry]

@danbri We are missing Provider on http://pending.webschemas.org/BroadcastChannel but it looks like inBroadcastLineup is sorta expecting a type of service and then within that we make the leap to Provider. We actually also need to have access to Provider right on the BroadcastChannel itself as well. (for disambiguation and simplifying the model for publishers where we can)

[ghost]

Good point. Whilst I think most of these standards (version control included) manage these sorts of things relatively well, a better term is certainly worth considering. BroadcastTechnology? deliveryTechnology? The use of it would be for IoT related purposes, ie: an EPG used on a phone that can serve as a remote, et.al. also, providers may simulcast using multiple technologies. Oh, the other is coverage area. Tim.H.

…

On Sun., 8 Jan. 2017, 2:27 am Thad Guidry, ***@***.***> wrote: @mediaprophet <https://github.com/mediaprophet> Timothy, I am hesitant to use the term Format in there....and would prefer Mode instead. The reason is because within a broadcastMode like DAB+ there could be multiple formats used, like MPEG2 and AAC+ .... this is technical level stuff that doesn't really apply to regular consumers of Schema.org but in choosing Mode or some word that signifies higher level abstraction it would allow a nice base for Schema.org extentions later that want to deal with the lower level stuff of Formats and even the protocol stack layers of the Modes themselves like the encoding, error correcting, data link layers, etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1004 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFdABqksthxHcnJPCvaBGscqIdWbCJ6Tks5rP67LgaJpZM4Hfssz> .

[njh]

As a source of examples of BroadcastService and broadcastFrequency, I am now publishing 425 Broadcast Services at https://www.radiodns.uk/services with BroadcastFrequencySpecification for the FM bearers. This is based on data from Ofcom and data from broadcasters themselves published using RadioDNS.

Example:

{
	"@context": "http://schema.org",
	"@id": "https://www.radiodns.uk/services/dab/ce1/c186/cc31/0",
	"@type": "BroadcastService",
	"broadcastTimezone": "+00:00",
	"name": "BBC Radio London",
	"broadcastDisplayName": "BBC Radio London",
	"description": "London's radio station - First for news, sport, travel, weather and entertainment with your views and stories. Call 0800 731 2000, text 'London' followed by your message to 81333",
	"url": "http://www.bbc.co.uk/bbclondon",
	"logo": [{
		"@type": "ImageObject",
		"width": 32,
		"height": 32,
		"url": "http://radio-service-information.api.bbci.co.uk/logos/bbc_london/32x32.png"
	}],
	"broadcastFrequency": [{
		"@id": "fm:ce1.cc11.09490",
		"@type": "BroadcastFrequencySpecification",
		"broadcastFrequencyValue": 94.9
	}]
}

I am encoding the Bearer URI (as specified in ETSI TS 103 270) into the @id field. But I still think it would be good to separate out the RDS Country Code and PI code into additional properties.

It would also be really good to be able to describe the DAB Bearers, in addition to the FM Bearers.

Is it too late to rename BroadcastFrequencySpecification to BroadcastBearer?

[danbri]

see also #2111

Is it too late to rename BroadcastFrequencySpecification to BroadcastBearer?

Can you expand on why the latter would be better? I lean towards putting what we have in the core for now, but the core is not this sacred untouchable thing ... we can continue to evolve

/cc @vholland @rvguha

[danbri]

How about we add BroadcastBearer as a supertype that is more inclusive of digital "broadcast", leaving the existing structure with its bias towards radio transmitters etc...?

[thadguidry]

@danbri "bearer" is not how you are probably thinking. You are thinking at a parallel level however in that a "bearer" is something kind of different, and it is ...its the transmission between a sender and listener essentially.

From ETSI doc...
bearer: method of carriage of the service
bearerURI: unique identifier for the service to be used in SPI SI documents
ServiceIdentifier: string that uniquely identifies a radio service within the scope of an Authoritative FQDN service provider: organization providing RadioDNS Hybrid Radio applications

"bearer" in other broadcast realms beyond Radio, such as Telecom (ISDN, Cellular, etc.) means the same thing here also, "a channel or transmission link between a transmitter and receiver, that carries the main information of the service".
https://searchnetworking.techtarget.com/definition/B-channel
https://en.wikipedia.org/wiki/Radio_Bearer_in_UMTS
http://www.teletopix.org/4g-lte/radio-bearer-in-lte/

I.E. "bearer" is universally accepted around the world in all forms of broadcast transmissions to mean "a transmission link" and "transmissions carry information". A "bearer" is what carries the information signal. smoke, a pair of wires, 4 wires, optic cable, or radio carrier, or some future bearer type yet to be discovered.
https://books.google.com/books?id=K4ribVEOhSAC&lpg=PA186&ots=JW0oNM6uMC&dq=transmission%20bearer&pg=PA186#v=onepage&q=transmission%20bearer&f=false.

[danbri]

@thadguidry bearing and carrying are similar metaphors here. Some context is that @njh and I talked about this a while back in London, in terms of trying not to be overly pre-digital in our schema terminology...

[thadguidry]

@danbri I guess you are saying "trust my intuition on this, Thad". Sure, then I'll see how things shape out with BroadcastBearer.

[danbri]

For info, https://developers.google.com/actions/media/radiostations-specification documents some usage made of this vocabulary at Google. It uses BroadcastFrequencySpecification + broadcastFrequency + broadcastFrequencyValue plus the existing broadcastAffiliateOf.

My sense is to push on with the current pending vocabulary moving into core, and add BroadcastBearer in pending as a supertype. @njh - does that work for you? Care to propose a definition?

[danbri]

QA question (nudged by Travis-CI although I don't think it was complaining about this exactly),

broadcastSignalModulation - is in the JSON-LD example but not in the current schemas

[danbri]

Nick wrote

I think the broadcastFrequencyModulation information is covered by having seperate classes of radio channel types

... is that where it disappeared to?

Looking at the examples, we only use this property (in either version, there was a broadcastFrequencyModulation variant discussed too) to say AM vs FM. And as @njh says, we have types for that:

-bash-3.2$ grep -Hin modulation issue-1004-examples.txt
issue-1004-examples.txt:14:   <meta itemprop="broadcastSignalModulation" content="FM" />
issue-1004-examples.txt:25:   <meta property="broadcastSignalModulation" content="FM" />
issue-1004-examples.txt:41:   "broadcastSignalModulation": "FM"
issue-1004-examples.txt:56:   <meta itemprop="broadcastSignalModulation" content="AM" />
issue-1004-examples.txt:67:   <meta property="broadcastSignalModulation" content="AM" />
issue-1004-examples.txt:83:   "broadcastSignalModulation": "AM"

[danbri]

If we did have such a property, definition could be (or was)

    <div typeof="rdf:Property" resource="http://schema.org/broadcastSignalModulation">
      <span class="h" property="rdfs:label">broadcastSignalModulation</span>
      <span property="rdfs:comment">The modulation (e.g. FM, AM, etc) used by a particular broadcast service</span>
      <span>Domain: <a property="http://schema.org/domainIncludes" href="http://schema.org/BroadcastFrequencySpecification">BroadcastFrequencySpecification</a></span>
      <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/Text">Text</a></span>
      <span>Range: <a property="http://schema.org/rangeIncludes" href="http://schema.org/QualitativeValue">QualitativeValue</a></span>
    </div>

[RichardWallis]

Implemented in release 3.5