A Baseball Ontology in Jena RDF/OWL Format

R95922007 Chih-Chau Ma

Abstract—In this project, a baseball ontology is proposed for efficiently recording and reasoning the information in baseball games. The baseball ontology is written by OWL (Web Ontology Language) format, and the data is recorded as RDF (Resource Description Framework). The rules and structures are designed based on the baseball rules and some common sense of baseball. Reasoning is tested on the ontology as some questions that are significant for a baseball game.

I. INTRODUCTION

T

HIS project proposes an ontology on baseball games. In one or a series of baseball games, many information is recorded as Figure 1, but much of them has relations for each other. For example, if a player has a homerun in this game, then he must have a hit and create a score, or in baseball terminology, have a RBI (Runs Batted In) in this game. Moreover, we may infer that he is a valuable player for this game. Based on these relations, an ontology is designed to record these information efficiently without listing all of them. By reasoning on the data based on this ontology, some important questions for a baseball game, like “Which player has a homerun in this game?” can be answered immediately.

An ontology structure will be shown in Chapter II. Some unfamiliar baseball terminologies are explained as well as the design principles of the ontology. The data representation of the information in baseball games is proposed in Chapter III, which provides an efficient way to record a baseball game. In Chapter IV, some rules are defined then used by Jena generic rule reasoner in addition to the ontology reasoner. Some reasoning is performed on the combinations of two reasoners. Chapter V gives a conclusion and shows some problem and weakness of this ontology.

II. ONTOLOGY STRUCTURE

The ontology of baseball games could be split into several parts: the game structure, the players, and the game events. Figure 2 shows the whole structure of ontology. It will be explained part by part, with the design principles for each part. The file schema.owl is the OWL format of this ontology.

A. Game Structure

A baseball game is formed by six to nine innings, according to the age of players. Each inning is split to top and bottom half-inning, in which two teams take turns to offense and defense. Each half-inning is composed by several batting, but the number is not fixed until three outs are accumulated for the offense team. So, the batting might be the base unit of baseball games. Of course we can further use pitch (each ball thrown by the pitcher) as the base unit, but the complexity will be too much to represent a whole game.

The classes for game structure are BaseballGame, Inning, HalfInning, TopInning, BottomInning, and Batting. They will be called game elements in Chapter III, and form a hierarchical structure for a baseball game. The object properties between them are Happens and HappenIn, they are transitive properties and inverse to each other. For example, A instance of BaseballGame which has nine innings will Happens nine Innings, and each Inning will Happens two HalfInnings, one of them is TopInning and the other is BottomInning. In each of these HalfInnings, several Battings are HappenIn them, and because the properties are transitive, those Battings in the inning are also HappenIn the BaseballGame instance.

The BaseballGame class has some datatype properties like GameDate and GameNumber. The Batting class also has some additional properties and subclasses. But they will be explained in part C as they are related to game events.

B. Game Members

A baseball game has at least nine players in each team, so Team and Player are two classes about game members. Because each baseball game requires two teams to play, A BaseballGame instance must have two Teams by the property HasTeam. It can be represented as HasHomeTeam and HasVisitingTeam further, which the home team is the team with the home field and be the defense team first, and the visiting team is the team that offense first.

The HasMember and BeMemberOf properties represent the relation between Team and Player. The player has only one datatype property that is Number because it is fixed for a player in general. The role of the player, e.g. pitcher, is not a datatype property because it may be changed during the game. It is represented as object properties like Pitches and PitchedBy between Player and the classes about game structure. If a Player has two different roles, i.e. plays for two defense position, it can be recorded by these properties without the need of creating two different instances for this Player. Presently, the only defined defense position is pitcher. But same manner can be used to define other defense positions like FirstBaseMan and Catcher. The two properties Pitches and PitchesDuring are different in meaning and function. The usage of them will be explained in Chapter III.

There are some object properties which are not game record directly, but represent some significant information about players like HasRBI, HasHit, and VersusPitcher. These properties are designed to infer the valuable players of a game.

C. Game Events

The game events are all subclasses of Batting and have a hierarchical form. They represent the various batting results which is possible to happen in the baseball game. These game events will be briefly explained here in order to show the hierarchical structure of them.

Subclasses of Batting:

Hit: The batter makes a successful batting which lets him be on base without getting the runners (if any) out.

Walk: The batter goes to the first base directly by the rules about some bad pitches of the pitcher.

Fail: The batter does not bat well and cause some bad results for his team.

Sacrifice: The batter himself is out by some intentional batting, which helps the runner go to forward base.

Subclasses of Hit:

Single: A Hit that makes the batter go to first base.

Double: A Hit that makes the batter go to second base.

Triple: A Hit that makes the batter go to third base.

Homerun: A Hit that makes the batter run through all three bases then return to home base to create score.

Subclasses of Walk:

BaseOnBalls: The pitcher pitches four balls which do not pass the “strike zone” above the home base in a batting. The batter can then go to the first base directly.

DeadBall: The pitcher pitches a ball that directly hit the batter’s body. The batter can also go to the first base.

Subclasses of Fail:

StrikeOut: The batter receives three strikes (a pitch that pass the strike zone above the home base) before batting the ball to the field. He is then considered out in this batting.

GroundOut: The ball is batted and hitting the ground, then caught by the defender and passed to the first base before the batter reaches the first base.

AirOut: The ball is batted then caught by the defender before it hits the ground.

FieldChoice: The batter himself is on base, but his batting cause the runner to be out.

Error: The batter’s batting should make him or his teammate out, but it does not because some faults from the defender. This is the defender’s duty so the batter is still considered to have an unsuccessful batting.

Subclasses of Sacrifice:

SacrificeHit: The batter taps the ball into the field in order to earn the time for the runner to go forward.

SacrificeFly: When there is a runner on third base, the batter bats a fly ball that is far enough to let the runner go back to the home base after the ball is caught.

The following are the bottom-level classes about the game events, but they are only parts of the events and do not cover all of batting results. For example, the class Homerun has two subclasses SoloHomerun and GrandSlam. But there exist some Homeruns which are neither SoloHomerun nor GrandSlam. This part of classes are used to record some special game events, but not for all events.

Subclasses of Single:

InfieldHit: The batted ball is a ground ball and caught by the infield defender, but the batter and all runners (if any) run fast enough to go to the bases safely.

Subclasses of Homerun:

SoloHomerun: When there are no runners on base, the batter bats a Homerun and gets one score.

GrandSlam: When there are three runners on base, the batter bats a Homerun and gets four scores.

Subclasses of StrikeOut:

StrikeOutPassedBall: A special result of StrikeOut. The pitched ball is not caught by the catcher and the batter runs to the first base before the ball is caught and passed to it.

Subclasses of GroundOut:

GroundedIntoDoublePlay: When at least one runner is on base, the batter bats a ground ball that causes two players to be out., may or may not include himself.

Subclasses of AirOut:

InfieldFly: A fly ball that is above the infield area. It has some special rules if several conditions are satisfied.

The hierarchical structure makes it convenient to record the batting result. For example, an instance of Homerun is also an instance of Hit and Batting. The Battings are bond to Players by the properties Bats and BattedBy. Besides the batter, the runner information is also recorded by some other properties like OnFirstBase and OnSecondBase.

III. DATA STRUCTURE

Based on the ontology above, there are many ways to record a baseball game. But since the records has many relations between them and those relations are incorporated as an ontology, there should be an efficient way to record as little information as possible, then infer the complete information by the ontology reasoner. The file data.rdf is an example about a mini baseball game, which shows an efficient manner to record the game. The data structure can also be separated to three parts: the game structure, members, and events.

For a particular baseball game, a BaseballGame instance will be created, as well as its GameDate and GameNumber (optional). In data.rdf, there is a three-inning mini game, so three Innings and six HalfInnings with three TopInnings and three BottomInnings are created. These game elements will be linked by Happens and HappenIn, but since they are transitive and inverse to each other, only one properties is needed in definition and only the adjacent levels of elements (BaseballGame to Inning and Inning to HalfInning) are required to define the property. The Battings is also a game element, but the definition will be suspended to the last part.

The next classes that are need to be defined for a baseball game is the Teams and Players. A BaseballGame requires exactly two Teams, so the two Teams have the properties BeVisitingTeamIn or BeHomeTeamIn to BaseballGame. Using these two properties is better than using BeTeamIn, because the meanings of “visiting team” and “home team” include the information of offense/defense order. Again, because of the symmetry, only one direction of the properties is needed in definition. If the data contains more than one BaseballGame, then there may be more than two Teams in the data and BeVisitingTeamIn and BeHomeTeamIn will link the Teams to the BaseballGames.

The Players are defined after the Teams, with the instance IDs as their name. A Player will BeMemberOf the Team he belongs to, and has his player Number. One important and special definition for the Players is the PitchesDuring property. For completeness, we should record the pitcher for each Batting because the pitcher may be changed between any Battings. But in general, a (good) pitcher may pitch several innings or even the whole game. The two property Pitches and PitchesDuring are both object properties from Player to any game elements (BaseballGame, Inning, HalfInning, and Batting), but Pitches means the Player ever pitches any number of Battings which HappenIn the game element, and PitchesDuring means the Player completes all pitches in the whole game element. In data.rdf, Player Tom PitchesDuring the TopInnings Top1_Game001 and Top2_Game001, then Player Mark PitchesDuring the TopInning Top3_Game001. The pitcher John in other Team PitchesDuring the whole game Game001, but in fact he only pitches three HalfInnings in which his team is defending. This information cannot be solved by ontology, but can be inferred by generic rule reasoning in Chapter IV.

Finally, the definition of Battings, as well as they BattedBy which Players, will record the whole process of a baseball game. But the instances are not defined directly to have the type Batting. They will be defined as the instances whose types are various batting results like Single, Double, and StrikeOut, hence the batting results can be recorded and the high-level type of them e.g. Hit and Fail can be inferred by the ontology. For simplicity, the data example data.rdf only records the Battings batted by Team Lions. It contains 13 Batting instances in 3 TopInnings.

Some Additional Information may also be defined for the Batting instance depending on the game situation:

PitchedBy: If the PitchesDuring information defined on the Players does not cover all the game, the pitcher for those uncovered Battings should be defined here for completeness.

Has1BRunner, Has2BRunner, Has3BRunner: the on-base runner information, if any.

The final three datatype properties of Batting are some statistics about a batting. They must be recorded for current ontology structure, but a more complete ontology may have the ability to reason this information if missing.

Outs: The current count of outs in this half-inning. It must be the value 0, 1, or 2 because 3 outs will end the half-inning.

RBI: The number of “Runs Batted In” for this batting. The RBI must not be cause by the Errors of defender.

Runs: The number of scores earned in this batting.

IV. REASONING

The ontology and data structure are proposed, but the applications of them are to record the game efficiently and make some deductions in the record. Since data.rdf is an example of a mini game, a reasoner which is combined by Jena generic rule reasoner and ontology reasoner is tested on the data in this chapter.

The rules for generic rule reasoner are written in the file myrule.rule. It takes the form p₁, …, p_m → q₁ ,… ,q_n but may have more complicated structure that supported by Jena. The functions of rules are briefly explained in the following:

Pitches_Infer (2 rules): Infer that if a Player ever pitches in a game element by the definition of Pitches and the Happens and HappenIn properties between game elements.

PitchesDuring_Infer (4 rules): Infer that if a Player pitches during the whole game element. These rules are more complicated than the rules for Pitches_Infer. For example:

[PitchesDuring_Infer:

(?pitcher h:PitchesDuring ?game)

(?game rdf:type h:BaseballGame)

(?pitcher h:BeMemberOf ?team)

(?team h:BeHomeTeamIn ?game)

(?game h:Happens ?event)

(?event rdf:type h:TopInning)

→ (?pitcher h:PitchesDuring ?event)]

In this rule, when a Player PitchesDuring a whole game, the Player’s Team and the relation between that Team and the BaseballGame should be checked. If the Team is a home team, then it must defense first by definition. So the Player should PitchesDuring all TopInnings in that game, but not any BottomInnings in that game.

There is also a special assumption for PitchesDuring: The Batting is the minimum unit for a Player to Pitches, i.e. a batter only faces one pitcher in a Batting. This assumption is generally true for real baseball games but sometimes false, but for the convenience of recording, this assumption is added.

HasPlayer_Infer: Infer the BaseballGame has what Players by the properties HasTeam and HasMember.

Versus_Infer: Infer the pitcher-batter pairs in the game, including two properties VersusBatter and VersusPitcher.

VersusTeam_Infer: Infer the property VersusTeam which is the relation from Team to Team or from Player to Team.

HasRBI_Infer, HasHit_Infer and so on: These inference rules are used to find the important Players of a game. For example, HasHomerun_Infer infers the HasHomerun property which indicates a Player has Homerun(s) in some game elements like TopInning. The following two properties RunsAllow and HomerunAllow mean that the pitcher let the batters he faces to got score(s) or hit Homerun(s).

HomerunOn_Infer: Infer the pitcher-batter pairs that the batter hits a Homerun on the pitcher.

The testing program of reasoning is BaseballInf.java, which is run in Eclipse. It includes three tests as the “queries” that a person who is interested in baseball may want to know for a given game data. The inferred RDF triples are shown in below. The results are sorted manually and the namespaces are removed for the convenience of reading.

Test 1: Print all data about player “John”

Batting information:

( John, Bats, Batting0003 )

( John, Bats, Batting0008 )

( John, Bats, Batting0013 )

( John, HasHit, Batting0003 )

( John, HasHit, Top1_Game001 )

( John, HasHit, Inn1_Game001 )

( John, HasHit, Game001 )

( John, HasHomerun, Batting0003 )

( John, HasHomerun, Top1_Game001 )

( John, HasHomerun, Inn1_Game001 )

( John, HasHomerun, Game001 )

( John, HasRBI, Batting0003 )

( John, HasRBI, Top1_Game001 )

( John, HasRBI, Inn1_Game001 )

( John, HasRBI, Game001 )

( John, HomerunOn, Tom )

Pitching Informaion:

( John, Pitches, Bottom1_Game001 )

( John, Pitches, Bottom2_Game001 )

( John, Pitches, Bottom3_Game001 )

( John, Pitches, Inn1_Game001 )

( John, Pitches, Inn2_Game001 )

( John, Pitches, Inn3_Game001 )

( John, Pitches, Game001 )

( John, PitchesDuring, Bottom1_Game001 )

( John, PitchesDuring, Bottom2_Game001 )

( John, PitchesDuring, Bottom3_Game001 )

( John, PitchesDuring, Game001 )

Versus Information:

( John, VersusPitcher, Tom )

( John, VersusPitcher, Mark )

( John, VersusTeam, Tigers )

Others:

( John, Number, 33 )

( John, BeMemberOf, Lions )

( John, BePlayerIn, Game001 )

( John, type, Player )

( John, type, Thing )

( John, type, Resource )

( John, sameAs, John )

Test 2 : Find all players who has Hit(s) in Game001

( Game001, HitCreatedBy, Smith )

( Game001, HitCreatedBy, John )

Indeed, Smith has two Hits, but the reasoner can only know he has Hit(s) or not. This is a weakness of the ontology.

Test 3 : Show all pitcher/batter Versus pairs

( Tom, VersusBatter, Richard )

( Tom, VersusBatter, David )

( Tom, VersusBatter, John )

( Tom, VersusBatter, Smith )

( Tom, VersusBatter, Bill )

( Mark, VersusBatter, Bill )

( Mark, VersusBatter, John )

( Mark, VersusBatter, Richard )

( Mark, VersusBatter, Smith )

Again, these triples only indicate the versus pairs, but it cannot show how many Battings they face to each other.

V. CONCLUSION

This project gives an OWL ontology structure and a manner to record the data of baseball games as RDF format. The reasoning on the data could be considered as the queries for information that a baseball fan may want to know. On application, these structures can be used for query systems about baseball events, or the artificial intelligence in baseball computer games as a coach.

But this kind of structures has its restrictions and weakness. When the data is represented to logical form, it is easy to record the existence and the truth/false value of the data, as well as the reasoning between them. But many of the baseball data include statistics, like BA(Batting Average). It is hard to compute these statistical values by the logical database and reasoner. Hence, from the tests in Chapter IV, the reasoning results are the logical information, but it cannot count for values. For example, it can tells that “Player Smith Bats some Hit(s)”, but it cannot shown how many Hits that Player Smith Bats. However, there is also some significant information about baseball that is not statistics. If the interested queries are about logical information, then the ontology structure is suitable to be used. Otherwise, a database with many statistical aggregations may be a more powerful system.