Mission: Be the go-to module for all information pertaining to horse racing past and present.
You have all of these processes running on various servers gathering data from oddschecker, bet fair, matchbook, BHR. Periodically they will lock onto new pieces of information, eg a market opens for a new race, or a new horse is discovered. The data source announces it to McCirick - "hey I have this new event here is what I know". Or “I’ve heard something about this horse”. It's up to McC to figure out oddities in naming and link it and store it all together. Then when it comes to working with the data we will say something like "what races are on for today" and you get a list back. Choose one and you get objects for all the data sources handed to you plus a compiled "authoritative" opinion on the information.
- Give me all races matching parameters, eg “todays card” or “all uk races in march”.
- Tell me about this horse.
- What races has this horse run in? OK give me information about these races.
- Data matching queries: Betfair calls this course X, which one is the OddsChecker name?
- Provide information in the face of missing data suppliers
For now I think it is best to implement the entity model described in “Horse Tinder” as it explains the entity relationships and data that we are interested in.
The authoritative data is a McCirick summation of various facts about an entity. For example location for a race, or stats for a horse. McCirick needs to take all of the available data providers and determine the one answer to “what sex is this horse” or “what was the rain % chance” or “what is the name of this horse and this racecourse”. So when a program looks at an entity it can easily look at “horse sex” in the authoritative data and be done, rather than worry about whether to look at BHR or BetFair and attempt to match names etc. Then if a program needs BetFair specific information it can access the BetFair data for the entity.
I see the recorded data as sub-data. Our current examples of oddschecker etc are all time based recordings, but they are stored in different systems or different formats. In the future there may also be another type of sub-data. So I’m going to assume that if your program needs to access this sub-data then it will know how to do so. So for now I wouldn’t worry about it. What we do need is a key to access the data. For example BetFair race data has a database key to access the recorded odds data. So this would be returned in the Race entity, contained in the betfair object.
As we will be running simulations, it is important that information stored includes the date at which it was available since we are simulating the past and can’t include data that was discovered after the event. A lot of data has this intrinsically, eg a race has a time and the result is only known after the run finishes. It would be nice to have McCirick handle this by passing a “current time” parameter in requests which would force the issue of making sure date information is provided when data is added.
I’m going to just make this up as a starting point. We ask McCirick for the British races on 13 October and choose the first one, 13:50 at Newmarket. So making up a story now, say we want the weather. Say something like getRace(“Newmarket”,”13:50 13 October 2017”) Get back some object with this cunk in it:
{
authoritative: {
temperature_c: 13,
... (other shit)
},
betfair: {
[no weather data on betfair]
...
},
bhr: {
weather_report: "Dry and breezy all day yesterday. Forecast: Dry and cloudy with sunny spells.",
...
},
weatherchannel: {
temp_f: 55,
}
}
So now if we want to know temperature, McCirick has worked it out for us by looking at what is available and using the best source. If however we really want to know BHR’s opinion we can look in that part of the object instead. Piece of cake.
Confirmed: * BetFair * Matchbook * Equotion * BHR * OddsChecker Shit to think about: * Irish horses * Scanning twitter for horse mentions * Scanning dudes talking bollocks on Facebook etc * Weather