The thorobase API (Open Source)

[thorobasePA]

The thorobase API (http://j.mp/cVe0XN) goes open-source! Right now, the (JavaScript) API consists of 2 projects:

* thoroData (http://j.mp/cSqXHY), to encapsulate horse racing data, and
* thoroMotion (http://j.mp/bZGywp), to visualize this data.

The projects are all hosted on github.com (http://www.github.com) under my robinhowlett (http://github.com/robinhowlett) account. thoroData (http://j.mp/cSqXHY) and thoroMotion (http://j.mp/bZGywp) are submodules of the thorobase project.

The thoroData API (http://j.mp/9r3mzN) contains the basic Model for horse racing objects: Meets, RaceCards, Races, and Performances. It also contains static racing data (e.g. Equibase Points of Call and Points of Fractionals), and the "interface" for Provider (suppliers of racing data) objects.

Provider implementations parse the raw data contained with the provider's file format and transform it into the thoroData Model. Currently, I have implemented just one implementation of a Provider so far, the BRIS Import Chart Data (http://j.mp/as9JXj), with many more to come.

The thoroMotion API (http://j.mp/belrRo) wraps a Google Visualization API (http://j.mp/8XJBBp) Motion Chart (http://j.mp/bU0Yj2) object and provides a createThoroMotionData method that transforms any thoroData Race object into the format a thoroMotion visualization requires.

If all of the above makes absolutely no sense, don't worry! In the coming days and weeks I will give a series of simple tutorials about getting started with the thorobase API, including creating thoroMotions, custom PPs, gadgets, converting from one provider's format to another etc.

For those of you comfortable with code, please go ahead and follow the links above to the GitHub repositories where you browse the source code. I've written some (http://j.mp/bEfeDg) test (http://j.mp/9u9f9N) code (in the /test folder) that demonstrates some basic usage of the thoroData and thoroMotion modules, and I've left some comments on the code that I hope, along with the code design, makes things clear.

If you know Git and github feel free the fork the projects, and if you are comfortable with JavaScript, just download the code and get started.

Otherwise, just either subscribe to the mailing list or the RSS feed on thorobase.com (http://www.thorobase.com) and you'll receive the tutorials when they written.

If you have any questions, please don't hesitate to ask.

[Tom]

Thorobase....:ThmbUp::ThmbUp:

[CBedo]

Thanks for doing this Robin. Besides for the great code and ideas, I've been looking for a reason to learn and use Git instead of Subversion.

[thorobasePA]

@Tom and @CBedo, thanks for your support - it's always appreciated.

While I've released the source code now, this isn't version 1.0 by any means - it's very much an "alpha" project right now, which means the code may change significantly in the coming months.

I've had some feedback about data providers and I'm looking towards creating an implementation of the MULTICAPS format. I'm not overly-familiar with all the various data file structures or their popularity, but my impressions with .mcp files are that they are widely used and are perhaps the most detailed (is this true?).

So I think it makes sense to perhaps base thoroData on the most detailed file structure.

Also, while I will make some demos on creating a thoroMotion, I think that I will extend the thorobase API to include a database (tentatively titled thoroDB).

The majority of the feedback I've received has been around people wanting to explore racing data in the ways they see fit, and rightly so. However, I'm going to take a different approach on this. While the majority of sophisticated gamblers focus on using a database for investigating profitability of edge cases, I want to promote everyone being able to use the data in a variety of ways. That includes creating custom user interfaces and data discovery techniques, shareable queries and algorithms, and bespoke versions for mobile devices when at the track.

Hence, I'm looking at using the document-oriented database MongoDB. It stores objects as JavaScript objects so it's easy to work directly with the Model. It uses an Object-focused query language that great for simple filtering and supports map/reduce functionality for calculations on large datasets. I haven't used it before so it could turn into a disaster but that's always been the risk.

Hopefully I'll soon have something to show.

[CBedo]

I have been playing around with Mongo as well, and think it has some potential. I have used Solr/Lucene for some projects in the past (Solr is behind the model that I have talked about on this forum last summer) and the speed of queries is fairly impressive with the denormalized document structures. I think (still haven't reached full conclusion) that for simple queries, it will be a very good solution (and Mongo continues to evolve), but depending on the complexity of queries/join tables, it could possibly be limiting as well. I am going back and forth on whether to use Mongo or stick with MySQl with Ruby on Rails as the object relational model on top of it.

In general, I think the generalized relational database is somewhat a dying structure with more and more specialized solutions for specific projects. I'll be watching attentively with your progress with Mongo.

As far as data files, I don't think the multicaps files have the "most" information, but they do have more than the pp files, and their cost is substantially less than some of the other data files which probably only have more derived data anyway. Multicaps seems to be the way to go currently.