Transit Stop Service Hours

Hmm. My assumption for this proposal is that the service hours of a station is equal to the combined service hours of trains that serve that station.

If Station Foo is closed at 2am, and serves lines 3, and 4, the new properties for line-based service hours will be able to model the following:

Line 3 at Station Foo ends service at 12:23am
Line 4 at Station Foo ends service at 1:45am

Reilly, the question is, do we need to capture the fact that Station Foo is "open" between 1:45 and 2am even though there's no service there?

I've entered/typed many transit stops and I just ignored service hours due to Faye's point about transit stops being serviced by several transit lines.  It's meaningless, for example, for huge transit stops such 30th Street Station in Philadelphia or Gare du Nord in Paris to have listed service hours as those stops are served by long-distance trains as well as local and light-rail transit lines that have varying hours.  If the intention is for service hours to refer to the closing and opening of station doors, that's not entirely clear when one examines the schema.  The property description of "Open Times' captures the hours and days of business operation for a retail location" seems too confusing when it comes to a transit stop. 

Besides, many transit stops that are street locations don't really "open" or "close";  there are only meaningful first and last service times by particular transit lines servicing particular locations on particular days.

I guess the idea of the visible timestamp is some sort of way of letting people know the "data might not be accurate - so don't go planning your trips based on this"?

It still wouldn't help with emergency closures or last minute changes of time.  You'd still need a disclaimer; and I see this is already provided by section #18 of the TOS.

The timestamp would just add clutter and complexity. 

No, the timestamp is says when the data was last edited, but when it was last confirmed to be correct.  If it was in the recent past, then it's safer.  If a long time ago, then much less so.

It also signals to the community when it might make sense to confirm and possibly correct the data.  

For example, if the data was bulk loaded 2 years before (when the timestamp was set), it's unlikely to be accurate unless somebody looked at it.   If somebody did look at it the month before, it has a much higher chance of being usable.

Without the timestamp, there is little confidence at all when the data can be used. In that case, I wonder if it even makes sense to load it as it will mostly be ignored in practice.

Ah, I see - if data was uploaded 2 years ago and then checked again yesterday and found accurate the timestamp will still show 2 years ago.  Yesterday's check will be unknown to us as accurate data does not require any changes - and only changes leave new timestamps.

This is common to all data which may change in time, not just transport timetables.  e.g. a check to see if someone is still alive or if Pluto is recategorised, or a reinterpretation of historical events based on new research.

It's part of a bigger discussion of confidence in data, related closely to that of verification of data from verifiable sources.

Some stations are open for ticket purchases even though trains may not be stopping there.  But could these be co-typed as business locations, which does have an opening hours property?

If so, nuke the property from Transit Stop.