search

schemaorg / schemaorg

Schema.org - schemas and supporting software
https://schema.org/
Apache License 2.0
5.42k stars 825 forks source link

New schema to support TV listings #329

Closed vholland closed 9 years ago

vholland commented 9 years ago

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:

Details and some examples can be found in my GitHub repository at https://github.com/vholland/schemaorg/commit/fe3fa6fea747f7080f1811a86bb35de8ac691989

tmarshbing commented 9 years ago

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 commented 9 years ago

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

moustaki commented 9 years ago

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 commented 9 years ago

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

TelevisionStation:

TelevisionChannel:

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

tmarshbing commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

moustaki commented 9 years ago

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

vholland commented 9 years ago

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 commented 9 years ago

Looks very good - many thanks @vholland !

rvguha commented 9 years ago

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

I've updated the property names https://github.com/vholland/schemaorg/commit/adabe5d2d0b28f36d04424bcc439522aaf9a5a6c 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 https://github.com/schemaorg/schemaorg/issues/329#issuecomment-84009113.

tmarshbing commented 9 years ago

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

thadguidry commented 9 years ago

@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 commented 9 years ago

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 Tardif Holland | Ontologist | vtardif@google.com

vholland commented 9 years ago

@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 commented 9 years ago

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

vholland commented 9 years ago

Merged into sdo-gozer.

danbri commented 9 years ago

@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 https://github.com/schemaorg/schemaorg/pull/464 )

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

danbri commented 9 years ago

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 https://github.com/schemaorg/schemaorg/issues/481

danbri commented 9 years ago

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

chaals commented 9 years ago

confirmed I am fine with this.