Add broadcastFrequency to BroadcastService to specify the over the air frequency #1004

Open
vholland opened this Issue Feb 22, 2016 · 63 comments

Projects

None yet

8 participants

@vholland
Contributor

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.

@vholland vholland self-assigned this Feb 22, 2016
@vholland vholland added a commit to vholland/schemaorg that referenced this issue Mar 7, 2016
@vholland vholland Issue #1004: Added broadcastFrequency to BroadcastService. a4ef93a
@vholland
Contributor
vholland commented Mar 7, 2016

See pull request #1019

@danbri
Contributor
danbri commented Mar 16, 2016

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
Contributor
danbri commented Mar 16, 2016

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

@danbri
Contributor
danbri commented Mar 16, 2016

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
njh commented Mar 16, 2016

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
Contributor
danbri commented Mar 18, 2016

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
njh commented Mar 21, 2016

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
Contributor
danbri commented Apr 4, 2016

@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
njh commented Apr 5, 2016

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...

@vholland
Contributor
vholland commented Apr 5, 2016

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
Contributor
chaals commented Apr 6, 2016

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
njh commented Apr 6, 2016

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
Contributor
chaals commented Apr 6, 2016

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
njh commented Apr 6, 2016

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

@mfhepp
Contributor
mfhepp commented Apr 6, 2016

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

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

@vholland
Contributor
vholland commented Apr 6, 2016

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

@mfhepp
Contributor
mfhepp commented Apr 7, 2016

@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?

@vholland
Contributor
vholland commented Apr 7, 2016

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
njh commented Apr 8, 2016

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
Contributor
chaals commented Apr 11, 2016

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

@vholland vholland added a commit to vholland/schemaorg that referenced this issue Apr 15, 2016
@vholland vholland Issue #1004: Added BroadcastFrequencySpecification. b851b51
@vholland
Contributor

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
Contributor
mfhepp commented Apr 15, 2016

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

?

@vholland vholland added a commit to vholland/schemaorg that referenced this issue Apr 15, 2016
@vholland vholland Issue #1004: Renamed broadcastFrequencyModulation to
broadcastSignalModulation and removed QualitativeValue from the range
for broadcastFrequency.
284fe7a
@vholland
Contributor

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
Contributor
danbri commented Apr 15, 2016

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?

@mfhepp
Contributor
mfhepp commented Apr 15, 2016

radio in radio frequency has nothing todo with radio vs tv set.

RFID tags don't listen to NPR News and TV stations of all kinds same as telemetry use radio frequency as well...

"Radio frequency (RF) is any of the electromagnetic wave frequencies that lie in the range extending from around 3 kHz to 300 GHz, which include those frequencies used for communications or radar signals."

Source: https://en.wikipedia.org/wiki/Radio_frequency

;-)

On 15 Apr 2016, at 19:44, vholland notifications@github.com wrote:

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


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@mfhepp
Contributor
mfhepp commented Apr 15, 2016

@danbri I was not suggesting to rename BroadcastService, I was just suggesting to model the signal specification part so that it is in alignment with the terminology and foundations of radio frequency communication of all kinds.

@danbri
Contributor
danbri commented Apr 16, 2016

How close do you think we are currently?

@vholland
Contributor

I appreciate that we are talking about radio frequencies in the electromagnetic sense, but most people will see "radioFrequency" and think "audio broadcast within a certain range", so I would like to stay with the more generic names.

Otherwise, I believe I have incorporated all of the comments.

@chaals
Contributor
chaals commented Apr 20, 2016

+1

@danbri
Contributor
danbri commented Apr 21, 2016

@vholland 's original suggestion here mentioned "a radio/TV broadcast". The current pull request has "The frequency used for over-the-air broadcasts." (mentioning neither TV nor radio; however all examples are radio-oriented). Should we add any explanatory text setting expectations about whether this/when this is applicable or sensible to use? If it is credible for TV anywhere, let's have an example; if not, let's stick in a note saying so.

@vholland
Contributor

UHF and VHF bands are still used (at least in the USA), although it is a dying use case outside of rural areas.

@danbri danbri pushed a commit that referenced this issue Apr 21, 2016
Dan Brickley Added broadcastFrequency to pending.
From #1004
8215674
@danbri
Contributor
danbri commented Apr 21, 2016

Added to pending extension for wider review:

http://pending.webschemas.org/broadcastFrequency

@danbri
Contributor
danbri commented May 26, 2016
@danbri
Contributor
danbri commented Jul 22, 2016

Where are we with this? Anyone uncomfortable with the current definitions as shown at http://pending.webschemas.org/broadcastFrequency ? Any proposals for improvements, tweaks etc?

@thadguidry
thadguidry commented Jul 22, 2016 edited

@danbri https://en.wikipedia.org/wiki/Frequency

Perhaps add just a little scientific hint to avoid confusion for future types of oscillation ? I.E. expand to the full term "temporal Frequency". I would avoid adding any extra narrowing terms like "radio Frequency", because the technology is already changing now and might not use discrete radio wave frequencies themselves in 10+ more years. Its now going towards multiplexed spectrums and bands... which begs the question...

Do we have broadcastBand ? To capture the spectrum in a range value ? You'll need that to capture the sublties of HD Radio that is now popular and in use now even in my own Toyota Camry car (Digital Audio Broadcasting) https://en.wikipedia.org/wiki/Band_III

By broadcasting digitally over traditional radio waves, a single frequency is now capable of delivering up to four stations of content in crystal clear sound. All you do is tune in to your favorite station and your HD Radio receiver will automatically lock in to the HD1 signal for that station. One notch over on the dial and you’re listening to entirely new content on the HD2 station. Additionally the digital signal provides on-screen information such as: album art, song info, traffic and weather.

So you'll want to be able to deal with a new property to capture "many stations per frequency or a channel or even a spectrum range".

So we should have a way to capture. A Frequency... A Channel...A Spectrum...and a Service Following as @njh suggests also.

@njh
njh commented Jul 22, 2016

Myself and @magicbadger were chatting at a recent RadioDNS conference and we agreed that we should try transforming the WorldDAB Service Information specification into RDF.

That should produce a good starting point for schema.org.

Given that the goal of this is to model Broadcast Radio - not the physics of radio waves, it would be a great shame to not benefit from the existing work done modelling radio stations and their bearer channels.

@mfhepp
Contributor
mfhepp commented Jul 22, 2016

I think I already raised similar concerns. At least we should think of separate properties for modulation (like AM, FM, USB, LSB, CW, ...) and cater for use-cases (like spread-spectrum) in which the frequency is a range or set of point values instead of a single point value.


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

On 22 Jul 2016, at 20:14, Thad Guidry notifications@github.com wrote:

@danbri https://en.wikipedia.org/wiki/Frequency

Perhaps add just a little scientific hint to avoid confusion for future types of oscillation ? I.E. expand to the full term "temporal Frequency". I would avoid adding any extra narrowing terms like "radio Frequency", because the technology is already changing now and might not use discrete radio wave frequencies themselves in 10+ more years. Its now going towards multiplexed spectrums and bands... which begs the question...

Do we have broadcastBand ? To capture the spectrum in a range value ? You'll need that to capture the sublties of HD Radio that is now popular and in use now even in my own Toyota Camry car (Digital Audio Broadcasting) https://en.wikipedia.org/wiki/Band_III


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@gmackenz
Contributor

Hi, interesting discussion about future of radio broadcasting starting up
here.

On Fri, Jul 22, 2016 at 4:04 PM, Martin Hepp notifications@github.com
wrote:

I think I already raised similar concerns. At least we should think of
separate properties for modulation (like AM, FM, USB, LSB, CW, ...) and
cater for use-cases (like spread-spectrum) in which the frequency is a
range or set of point values instead of a single point value.


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

On 22 Jul 2016, at 20:14, Thad Guidry notifications@github.com wrote:

@danbri https://en.wikipedia.org/wiki/Frequency

Perhaps add just a little scientific hint to avoid confusion for future
types of oscillation ? I.E. expand to the full term "temporal Frequency". I
would avoid adding any extra narrowing terms like "radio Frequency",
because the technology is already changing now and might not use discrete
radio wave frequencies themselves in 10+ more years. Its now going towards
multiplexed spectrums and bands... which begs the question...

My initial impression is that we currently discussing something beyond
over-the-air broadcasting of content by content broadcasters?
broadcastFrequency for wireless communication networks?

Also is there an assumption of some or much near-future usage of non-radio
wavelengths for radio broadcasts?

Do we have broadcastBand ? To capture the spectrum in a range value ?
You'll need that to capture the sublties of HD Radio that is now popular
and in use now even in my own Toyota Camry car (Digital Audio Broadcasting)
https://en.wikipedia.org/wiki/Band_III

Not sure if I fully understood but wouldn't spread spectrum data (does such
examples of radio broadcast web data exist currently?) be covered by
BroadcastFrequencySpecification
http://pending.webschemas.org/BroadcastFrequencySpecification's
broadcastFrequencyValue
http://pending.webschemas.org/broadcastFrequencyValue which can
contain a value
range http://pending.webschemas.org/QuantitativeValue?

I only bring this up as I worry about creating schema that is much more
complicated than the data currently being presented. Are there examples of
radio broadcast data that cannot be served by the current proposed model?
Is the thought for separate properties for modulation such as AM, FM, etc.
intended so they can be further extended by that particular modulation's
unique characteristics and how would that relate to a specific radio
broadcast data? Very interested in learning more about this, but also very
interested in getting a good easily usable broadcastFrequency into
schema.org.

@danbri
Contributor
danbri commented Jul 25, 2016

@njh @magicbadger w.r.t. "WorldDAB Service Information specification" - is https://portal.etsi.org/webapp/workprogram/Frame_WorkItemList.asp?SearchPage=TRUE&qSORT=HIGHVERSION&qINCLUDE_SUB_TB=True&butSimple=++Search++&qETSI_STANDARD_TYPE=&qETSI_NUMBER=103+176&qETSI_ALL=TRUE&qMILESTONE=&qACHIEVED_DAY=&qACHIEVED_MONTH=&qACHIEVED_YEAR=&qREP the relevant spec? i.e. http://www.etsi.org/deliver/etsi_ts/103100_103199/103176/01.02.01_60/ts_103176v010201p.pdf ?

I would love to see ~5 grounding examples that describe real existing radio stations and their actual broadcast details to help us scope this discussion. Can anyone make a start at that?

Is there any possibility that the relevant trends / technologies and terminology differ significantly between territories, e.g. (western) Europe vs US vs Russia, ...?

@njh
njh commented Jul 25, 2016

Yes, I will see if I can come up with some concrete examples.

The ETSI specification is "Hybrid Digital Radio (DAB, DRM, RadioDNS); XML Specification for Service and Programme Information (SPI)", where Hybrid means combining Broadcast technology and Internet Protocol:
http://www.etsi.org/deliver/etsi_ts/102800_102899/102818/03.01.01_60/ts_102818v030101p.pdf

The bits of particular interest to this are the Bearer and Service concepts.

I believe @RadioDNS aims to support all kinds of broadcast systems. DAB is popular in Europe/Asia, HD Radio and Satellite radio are popular in US. FM is fairly universal.

@thadguidry
thadguidry commented Jul 25, 2016 edited

@gmackenz GORDON ! :) miss ya man

Let me simplify....(lets not worry about 10 years from now, that's a side discussion clarified further down) , but for the immediate need now, we need to be able to support Broadcasters that currently list Station call details such as this Example:

KSCS (Dallas, TX)
offering 'New Country' content on
96.3 FM

KLIF (Dallas, TX)
offering 'News and Information' content on
96.3 FM

wait, whuuut ? 2 stations using the same frequency ? yes and no.
For HD Radio broadcasting Its really like this instead,

Dallas - marketArea
96.3 FM - broadcastFrequency
96.3-1 channel for KSCS
96.3-2 channel for KLIF

I am fine with broadcastFrequency, with just a slight tweak on its definition.
But additionally we need to support Channels at a given frequency.

FCC has not changed their regulations for Radio Spectrum licensing yet. This is in the planning stages and is about 10 years out by some estimates, but the general idea is to allow a pool of broadcasters to take a slice of the spectrum and share it digitally.

Like so:

96.3 - 96.9 KSCS, KLIF, KNON, serving across 10 channels of News, New Country, Blues, Independent Talk, etc

The Future:
In non-public areas, special industrial broadcasting is being researched and attempted via Ultrasonic waves (using high frequency sound via ultrasonic emitters, not radio waves) to transmit and receive a digital broadcast within spaces such as a large performance venue, etc. But lets not worry about this future tech just yet, its about 5 years away, and will be primarily for Events and simulcasting in closed areas where radio waves are not allowed or prohibited.

@thadguidry

@danbri Just add the term "radio" somewhere in that definition and I am OK.

@gmackenz
Contributor

@thadguidry Hello to you as well!

Thanks for the response, so something like this as example of having a need for channel (always 1 thru 9 I suppose) ?

So it could be typically presented in the US as 88.1-1 or more commonly I think, 88.1 HD1.

So maybe for the above example: a new property broadcastChannel on BroadcastFrequencySpecification that expects either Integer (1) or QualitativeValue (HD1)

@thadguidry

@gmackenz Yeap, you got it. but its not limited to channels 1 thru 9 since current and future can pack a lot of digital data channels on a single frequency...then you add spread spectrum to the mix in the farther future and :)

@gmackenz
Contributor
gmackenz commented Jul 29, 2016 edited

So, @thadguidry, as per your interest in channel (for example from this HD Radio page) you would like to see a broadcastFrequencyChannel property that accepts either an Integer or QuantitativeValue?

`


WBGO 88.3-2 FM HD2
The Jazz Bee

`
@mfhepp
Contributor
mfhepp commented Jul 29, 2016

For the records: If we want a proper way of modeling radio-frequency transmissions, we should include a property for the type of modulation and use standard ITU codes like "F8E" for FM broadcasting for radio transmissions on VHF.

See

https://en.wikipedia.org/wiki/Types_of_radio_emissions

These codes are pretty established and used in equipment datasheets etc.

Best wishes

Martin


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

On 29 Jul 2016, at 10:40, Gordon Mackenzie notifications@github.com wrote:

So, @thadguidry, as per your interest in channel (for ecample like that from this HD Radio page) you would like to see a broadcastFrequencyChannel property that accepts either an Integer or QuantitativeValue?

WBGO 88.3-2 FM HD2 The Jazz Bee
And all of the other channels would be like the above example so


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@thadguidry
thadguidry commented Jul 29, 2016 edited

@gmackenz Yes, correct, A broadcastFrequencyChannel property as in your example.

@mfhepp Yes, sounds good. modulationSignalType = 7 - More than one channel containing digital information

@njh
njh commented Aug 12, 2016

Hi,

While very much work in progress, I have spent some time looking at modelling Radio Stations using RDF, including some examples:
https://github.com/bbc/radio-service-vocab

schema.org already deals with programmes, as does the BBC Programme Ontology, so this is more about the transmissions and tuning of radio stations. It is heavily based on the RadioEPG specification, but serves a different purpose - modelling the data and entities.

While I wouldn't expect schema.org to adapt much of this in the short term, I think concept of a 'Bearer' is very important - even if it is named something else. It is basically a broadcast channel, adding an extra level of indirection between a broadcast service and the frequency it transmits on. But the extra level of indirection makes it possible to model anything that isn't analogue radio in a sensible way.

For digital services (DAB, DVB and even HD Radio in time), the frequency is not the most important factor. Some kind of service identifier is a lot more important. Many digital radio tuners will be constantly scanning the frequencies and then tuning to a station based on that service identifier. This allows broadcasters to manage frequencies more flexibly and move services between frequencies, invisibly to the listener.

So at its simplest you have an FM bearer with a frequency in the range 87.5 to 108.0 MHz. For small town USA radio is it likely that a BroadcastService will often only have a single bearer, with the frequency and RDS PI code. Then over time, you can add other bearers over time to support DAB, HD Radio, DVB etc...

nick.

@danbri
Contributor
danbri commented Aug 12, 2016

Thanks @njh, this is really useful and +1 to the suggestion that we consider taking on board at least the Bearer construct.

@danbri
Contributor
danbri commented Aug 17, 2016 edited

I'm sat with @njh at BBC going over this, and discussing possible alternate names for "bearer", I looked for "channel" in schema.org and remembered (barely!) that we had https://schema.org/BroadcastChannel https://schema.org/RadioChannel https://schema.org/TelevisionChannel

This is from #329 last year. Nick's view (I think...) is that this construction gives an existing entity that could play the same role he was calling "bearer", and which would be an attachment point for various useful pieces of information that go beyond frequencies. It has http://schema.org/providesBroadcastService linking from a RadioChannel to a BroadcastService. There is no inverseOf this property, @njh suggests "broadcastChannel" could be a useful inverse.

node arc diagram described below

captures a drawing showing:

  • (top right, blue) simple shortcut notation, e.g. "87.7 FM"
  • (lower right, blue) current pending.schema.org design implemented as broadcastFrequency here.
  • (lower left, red) sketch of the bearer-based structure, with subtypes for common kinds of bearer e.g. for BearerFM, BearerAM
  • (left, black) sketch of where RadioChannel fits in, idea being that this could play same role as bearer, and we'd subtype e.g. FMRadioChannel...

@njh - did that capture it?

@danbri
Contributor
danbri commented Aug 17, 2016

Simplified (omitting the FM HD 2 proprietary aspects for now):

{
"@context": "http://schema.org/",
"@type": "BroadcastService",
 "broadcastDisplayName": "The Jazz Bee",
 "broadcastChannel": 
  {
    "@type": "FMRadioChannel",
    "broadcastFrequency": "88.3",
    "...": "..."
  }
}
@danbri danbri pushed a commit that referenced this issue Aug 17, 2016
Dan Brickley Updated based on @njh's proposed design after meeting at BBC.
For #1004
04590dd
@danbri
Contributor
danbri commented Aug 17, 2016

I've made some commits to the version sketched in data/ext/pending/issue-1004.rdfa (but not the examples in issue-1004-examples.txt nearby), based on meeting up with @njh earlier today. These do not leave a complete or fully considered design (esp. textually definitions and some properties are woolly) but begin sketching one based on the ideas above and the existing RadioChannel structure.

Work-in-progress:

(I didn't touch the pending stuff in schema.org proper...)

@danbri danbri pushed a commit that referenced this issue Aug 17, 2016
Dan Brickley Fixed s/FM/AM/
See #1004
efb68ba
@danbri danbri pushed a commit that referenced this issue Aug 17, 2016
Dan Brickley Backed out retiring BroadcastFrequencySpecification since properties …
…used it.

For #1004
69b0a08
@danbri danbri pushed a commit that referenced this issue Aug 17, 2016
Dan Brickley Added hasBroadcastChannel as inverseOf providesBroadcastService
For #1004
71e4868
@danbri danbri pushed a commit that referenced this issue Aug 17, 2016
Dan Brickley Explicit 2nd inverseOf.
See #1004
c191028
@gmackenz
Contributor

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
Contributor
danbri commented Aug 18, 2016

@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
Contributor
danbri commented Aug 18, 2016

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

@njh
njh commented Aug 18, 2016

@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
Contributor
gmackenz commented Sep 6, 2016

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.

@mediaprophet
@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
thadguidry commented Jan 7, 2017 edited

@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)

@mediaprophet
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment