Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
vholland opened this issue Feb 22, 2016 · 74 comments
Closed
Assignees

Comments

@vholland
Copy link
Contributor

@vholland vholland commented Feb 22, 2016

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
Copy link
Contributor Author

@vholland vholland commented Mar 7, 2016

See pull request #1019

@danbri
Copy link
Contributor

@danbri 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
Copy link
Contributor

@danbri danbri commented Mar 16, 2016

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

@danbri
Copy link
Contributor

@danbri 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
Copy link

@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
Copy link
Contributor

@danbri 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
Copy link

@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
Copy link
Contributor

@danbri 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
Copy link

@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
Copy link
Contributor Author

@vholland 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
Copy link
Contributor

@chaals 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
Copy link

@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
Copy link
Contributor

@chaals 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
Copy link

@njh njh commented Apr 6, 2016

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

@mfhepp
Copy link
Contributor

@mfhepp 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
Copy link
Contributor Author

@vholland vholland commented Apr 6, 2016

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

@mfhepp
Copy link
Contributor

@mfhepp 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
Copy link
Contributor Author

@vholland 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
Copy link

@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
Copy link
Contributor

@chaals 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 added a commit to vholland/schemaorg that referenced this issue Apr 15, 2016
@vholland
Copy link
Contributor Author

@vholland vholland commented Apr 15, 2016

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
Copy link
Contributor

@mfhepp 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 added a commit to vholland/schemaorg that referenced this issue Apr 15, 2016
broadcastSignalModulation and removed QualitativeValue from the range
for broadcastFrequency.
@vholland
Copy link
Contributor Author

@vholland vholland commented Apr 15, 2016

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
Copy link
Contributor

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

danbri added a commit that referenced this issue Aug 17, 2016
@gmackenz
Copy link
Contributor

@gmackenz gmackenz commented Aug 18, 2016

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
Copy link
Contributor

@danbri 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
Copy link
Contributor

@danbri 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
Copy link

@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
Copy link
Contributor

@gmackenz gmackenz commented Sep 6, 2016

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

@thadguidry
Copy link
Contributor

@thadguidry thadguidry commented Sep 6, 2016

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

@ghost
Copy link

@ghost ghost commented Jan 7, 2017

@thadguidry
Copy link
Contributor

@thadguidry thadguidry commented Jan 7, 2017

@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
Copy link
Contributor

@thadguidry thadguidry commented Jan 7, 2017

@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
Copy link

@ghost ghost commented Jan 7, 2017

@njh
Copy link

@njh njh commented Jan 7, 2019

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
Copy link
Contributor

@danbri danbri commented Feb 6, 2019

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
Copy link
Contributor

@danbri danbri commented Feb 6, 2019

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
Copy link
Contributor

@thadguidry thadguidry commented Feb 6, 2019

@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
Copy link
Contributor

@danbri danbri commented Feb 6, 2019

@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
Copy link
Contributor

@thadguidry thadguidry commented Feb 6, 2019

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

@danbri
Copy link
Contributor

@danbri danbri commented Feb 13, 2019

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 added a commit that referenced this issue Feb 13, 2019
danbri added a commit that referenced this issue Feb 13, 2019
Content is now in schema.rdfa.
@danbri
Copy link
Contributor

@danbri danbri commented Feb 21, 2019

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
Copy link
Contributor

@danbri danbri commented Feb 21, 2019

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
Copy link
Contributor

@danbri danbri commented Feb 21, 2019

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>
danbri added a commit that referenced this issue Feb 21, 2019
danbri added a commit that referenced this issue Feb 21, 2019
@RichardWallis
Copy link
Contributor

@RichardWallis RichardWallis commented Apr 10, 2019

Implemented in release 3.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.