New schema to support TV listings #329

Closed
vholland opened this Issue Feb 6, 2015 · 22 comments

Projects

None yet

7 participants

@vholland
Contributor
vholland commented Feb 6, 2015

Schema.org currently has types for BroadcastService and TelevisionStation, but there is no notion of a channel in a given TV line up as one would find from a satellite or cable provider.

This proposal is to add the following:

  • New type TelevisionChannel for a specific channel in a provider lineup. Properties include:
    • channel: for the identifier (usually a number) in a provider's lineup
    • station: The TelevisionStation associated with the channel
    • inLineup: linking a channel to a BroadcastService (e.g. Comcast cable)
    • serviceTier: A text description of the service needed to access the channel (e.g. premium)
  • New properties on TelevisionStation:
    • affiliateOf: The broadcast network(s) associated with a TelevisionStation.
    • displayName: The name the station uses on its display. For example, WAAY may display as "ABC".
    • timezone: The timezone the station uses when publishing its lineup.

Details and some examples can be found in my GitHub repository at vholland@fe3fa6f

@vholland vholland changed the title from New schema to support TV listinsg to New schema to support TV listings Feb 6, 2015
@vholland vholland self-assigned this Feb 13, 2015
@danbri danbri added this to the 2015 Q1 milestone Mar 5, 2015
@tmarshbing

For timezone, should we recommend that people use the ISO 8601 suffix (e.g., "−06:00" for Central Standard Time)?

For channel, should we name it more specifically, such as televisionChannel? The Wikipedia disambiguation for channel has a few other meanings that could conceivably end up in our vocabulary at some point, such as for geography, marketing, communication, etc.

Similarly, station may also need to be qualified.

We have properties from channel -> broadcast service, and channel -> station, but not reciprocal ones. Should we have the reciprocal ones, too?

@vholland
Contributor

Agreed on the names. I'll think it through and come up with some better ones.

@moustaki

If the proposal is to describe such cable/satellite providers as BroadcastService (which I don't think was the original intent of that concept - the broadcast service examples include e.g. BBC Radio 4, Channel 4, NBC, etc.), then maybe the existing parentService and organization properties could be used to describe such relationships, without introducing new concepts.

In any case, I would recommend moving the proposed TelevisionChannel/TelevisionStation properties to concepts that could accommodate radio stations as well.

@vholland
Contributor

I've updated the property names to be less generic and I hope in line with Radio where applicable.

TelevisionStation:

  • "affiliateOf" changed to "broadcastAffiliateOf"
  • "displayName" changed to "broadcastDisplayName"

TelevisionChannel:

  • "channel" changed to "televisionChannelId"
  • "inLineup" changed to "inBroadcastLineup"
  • "serviceTier" changed to "televisionServiceTier"
  • "station" changed to "televisionChannelStation"

The easiest place to see the entire proposal in one go is in the pull request.

@tmarshbing

I'm OK if you want to keep the current, updated names, but here is my 2 cents:

I think that the original names were actually good -- and could be expanded in the future without loss of meaning -- except for station & channel. Also, televisionChannelStation is a bit of a mouthful. Would televisionStation be sufficient?

Also, @vholland, what were your thoughts on the reciprocal properties?

@vholland
Contributor

I agree televisionChannelStation is a mouthful, but televisionStation is the same as TelevisionStation other than case and I could not think of a better name.

Per @rvguha 's suggestion, I was also trying to avoid grabbing namespace like "serviceTier" for something that may not be generic.

We go back and forth on reverse properties. I'm willing to add them if people feel strongly about them.

@moustaki

These changes seems to make the concepts even more television-centric?

Just to re-iterate as well: the original intent of BroadcastService was exactly what 'TelevisionChannel' appears to be in the examples available in the pull request, except that it's generic across Radio and TV. It was never intended to model things like cable providers. Reading the original intent of that PR, I would have expected a new concept to model such providers, but no changes in semantics to BroadcastService.

@vholland
Contributor

@moustaki I see what you are saying. I am currently traveling, but will send out a new pull request next week.

@moustaki

Np @vholland. Here is an example of BroadcastService in-use on the BBC web site: http://www.bbc.co.uk/programmes/b05mqkbz

@vholland vholland added a commit to vholland/schemaorg that referenced this issue Mar 31, 2015
@vholland vholland Per Issue #329: Created CableOrSatelliteService and reverted changes …
…to TelevisionStation in favor of the more radio-friendly, BroadcastService.
2d36e0f
@vholland
Contributor

I've changed the proposal (and pull request) drastically, so I would appreciate another look.

Notably:

  1. Removed the proposed TelevisionStation changes in favor of using BroadcastService as @moustaki suggested.
  2. Proposed CableOrSatelliteService to replace the misuse of BroadcastService as originally proposed. A CableOrSatelliteService may be for television (e.g. Comcast, DirecTV) or Radio (e.g. SiriusXM).
  3. Added BroadcastChannel to link a CableOrSatelliteService to a BroadcastService. BroadcastChannel has the child types RadioChannel and TelevisionChannel.

Details are in pull request #389.

@moustaki

Looks very good - many thanks @vholland !

@rvguha
Contributor
rvguha commented Mar 31, 2015

Thanks. This looks good
On Mar 20, 2015 6:14 AM, "vholland" notifications@github.com wrote:

I've updated the property names
vholland@adabe5d
to be less generic and I hope in line with Radio where applicable.

TelevisionStation:

  • "affiliateOf" changed to "broadcastAffiliateOf"
  • "displayName" changed to "broadcastDisplayName"

TelevisionChannel:

  • "channel" changed to "televisionChannelId"
  • "inLineup" changed to "inBroadcastLineup"
  • "serviceTier" changed to "televisionServiceTier"
  • "station" changed to "televisionChannelStation"

The easiest place to see the entire proposal in one go is in the pull
request https://github.com/schemaorg/schemaorg/pull/389/files.


Reply to this email directly or view it on GitHub
#329 (comment).

@vholland vholland modified the milestone: sdo-gozer release, 2015 Q1 Apr 2, 2015
@tmarshbing

The conceptual model and names look good to me. I have a few detailed comments which I added to the pull request.

@thadguidry

@vholland "inLineup" changed to "inBroadcastLineup" - Lineups are ChannelLineup's and these are at a Broadcast Providers Service agreement (These are sometimes called Plans by the industry)... I could have Comcast Service Level 1 or Level 2 (Digital Starter Plan or Digital Preferred Plan, etc) and furthermore...Levels and Plans available are dictated by ServiceArea and Region.

What to do ? Are we going to be treating the CableOrSateliteService as A Plan or Level ? If so, it will need to have a property to hold a ServiceArea or RegionAvailable.

@vholland
Contributor
vholland commented Apr 7, 2015

On Mon, Apr 6, 2015 at 1:29 PM, tmarshbing notifications@github.com wrote:

The conceptual model and names look good to me. I have a few detailed
comments which I added to the pull request.

Thanks, Tom. I fixed those issues.

  • Vicki

Vicki Tardif Holland | Ontologist | vtardif@google.com

@vholland
Contributor
vholland commented Apr 7, 2015

@thadguidry CableOrSatelliteProvider inherits from Service, so it has a serviceArea property. A national provider like Comcast would need to model each region separately to clarify lineup availability.

@thadguidry

@vholland Right, which many providers do model each region separately (and use Zipcode lookups to ascertain the region) Thanks for verifying.

@vholland
Contributor
vholland commented Apr 8, 2015

Merged into sdo-gozer.

@vholland vholland closed this Apr 8, 2015
@danbri danbri reopened this May 12, 2015
@danbri
Contributor
danbri commented May 12, 2015

@chaals has raised a concern after spotting 'timezone' in the larger renaming discussion:

"Not so sure that broadcastTimezone is the right approach. There are lots of events that have timezones (and some that don't, or have multiples), and having multiple timezone-related properties seems like it would be a bad idea." (in #464 )

(note that the proposed 'timezone' became 'broadcastTimezone' recently).

@danbri
Contributor
danbri commented May 12, 2015

Talking more with Charles (in Skype msgs) I understand his concern is that we shouldn't lose the potential generality of a 'timezone' property and end up having dozens of highly similar timezone properties. I believe he is prepared to live with the status quo, so long as we explore adding a broader superproperty that covers more scenarios. This is now tracked at #481

@danbri
Contributor
danbri commented May 12, 2015

I'm marking this closed, I think we have a resolution for concerns that were raised.

@chaals please re-open if you think that premature, or else move #481 to the sdo-gozer release milestone. /cc @vholland

@danbri danbri closed this May 12, 2015
@chaals
Contributor
chaals commented May 12, 2015

confirmed I am fine with this.

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