Some notes of ideas basic on the http://www.unilinkbus.co.uk/times.shtml timetable.
- This page is just notes for now, not a meaningful recipe **
The first issue is do you store the stock timetables, and link them to days?
How do you handle the date on buses which run after midnight? (guessing the service will have a line between night and morning, but may vary between companies). Does a bus starting on one date follow the entire path of that date, or does it switch to the next date at midnight or at the company date rollover line, eg 4am?
Each day of the year the unilink bus service runs one of what is, in effect, a fixed set of services:
- Monday in University Termtime
- Tuesday in University Termtime
- Wednesday in University Termtime
- Thursday in University Termtime
- Friday in University Termtime
- Saturday in University Termtime
- Sunday in University Termtime
- Monday out of University Termtime
- Tuesday out of University Termtime
- Wednesday out of University Termtime
- Thursday out of University Termtime
- Friday out of University Termtime
- Saturday out of University Termtime
- Sunday out of University Termtime
- Public Holidays (basically same as sunday service) (note to self, are public holidays in term time treated like sundays in term time etc.?)
- Special Holidays (Chistmas) which have no buses at all
A single bus service is, I think, one bus running from the start to end of a route (with a single bus route ID number, like U1C). The physical bus can then start providing another service, eg. U1H. It would be associated with a number of events which are a bus-stop ID and a time (or datetime?)
Very adaptable simple model: Just say describe every single day and make every single bus service occur once. The same bus with the same number making the same stops at the same time, but on a different day, is an entirely new bit of data. This is horrifically verbose, but would work combined with an API to request buses for day X. It would be a nightmare to work with in SPARQL etc.
More compact notation: A bus service (identified by a URI) has a number, and lost of stop events (busstop/time (not date)). A days timetable is comprised of a set of specific bus service URIs, but the same bus service can appear in more than one timetable (eg. Monday and Tuesday). Each date is associated with one or more timetables.
It would be theoretically possible to use goodrelations, but it does not have a very smart handling of special cases, and while shop or coffeebar opening hours can be treated with some common sense on Christmas Day, bus and train timetable data remains of much more importance to people. Hence the value in linking to each days' timetable.
sketch of possible data model
- Transport stop/node had lat/long/name
- A given date has a list of relevant timetables
- A timetable consists of a set of services and/or abstract-services (need a better name for these)
- A service consists of a single vehicle going via a bunch of nodes, the service may also have a name,description and ID number (eg bus number)
- A service has a set of stops with a single datetime of the time at each stop, or the time of arrival & time of departure. (note, maybe times are just always times of arrival, unless there's departure too at a few special nodes)
- An abstract service is the same *except* there is no date and the time is the number of hours and minutes from midnight of the date it is being insansiated(sp?). This is a non-standard time field as it can be negative. eg. -00:30 If Tuesday's service starts at 11:30pm on Monday, or more likely 26:00 for the last night bus at 2am.
- it does not need ordering as the time will do that implicitly.
- A date and timetable containing abstract services can be mapped to a non-abstract timetable, but not using RDF reasoning.
- Nodes, Services, Timetables etc. can all be related to the providing company. eg. Unilink
- A route is an ordered set of stops with a route code/number/name and possibly an inverse route (nb. what if a route changes between timetable publications? -- probably need to put a timecode in route URIs?)
This model doesn't do very well with circle routes... It could be treated as a single service stopping at each stop many times in one day. Unilink busses go to one end, change number, and come back, but in some other transport services the transport may just keep going round a circular path (eg. the ferry link bus which does ferry/station/shops/ferry/station/shops/..) In some instances a logical break can be found, but not others. Maybe services could have a flag which says 'becomes service: X', which means you can assume that if there is a service X arriving at the exact stop and second as the last stop in the current service, then it is the same vehicle. (this allows busses to change number. eg. 7 becomes 7X and continues to blah - the 7X is a different service but has been linked to the 7. If there's a different arrival & departure time then the 7X will need to specify the arrival time in its schedule to facilitate the link. The link should be by ID of bus or route, not the exact next service as this will allow you to have an abstract service that is not continued on sundays. The sunday timetable just does not include the continuation service.
URI/URL design will be very important here. Almost certainly, it should be done by date. Also most services will want quick answers not huge amounts of data so it makes sense to query date/time ranges, and filter these by destination/
ARGH. You can't just use time or datetime to sort the stops as many timetables only list the times for primary stops. So we need some other way to order it... _seq or list?