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?

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

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.

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.

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?

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.

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.

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

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

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.

Looks very good - many thanks @vholland !

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

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

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

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

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

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

Merged into sdo-gozer.

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

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

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

confirmed I am fine with this.