Class Content
Publication
There is a technical report that describes the class project work.
Rui Yan, Hao Zhong, "Soccer Offside Knowledge Modeling. " Ontology Engineering 2016, Rensselaer Polytechnic Institute Technical Report, 2016
There is also a paper under review for publication that presents a broader picture of the work that is co-authored with our collaborators.
Assignments
- Assignment 1
- Assignment 2
- Assignment 3
- Assignment 4
- Assignment 5
- Assignment 6
- Assignment 7
- Assignment 8
- Assignment 9
- Assignment 10
- Assignment 11
- Assignment 12
Presentations
- 5/9/2016: link <-- final presentation leveraging semantic importance
- 4/25/2016:link
- 4/4/2016 : link
- 3/28/2016: link
Related Work and References
[1]Fédération Internationale de Football Association. Laws of the game. FIFA., 2002.
[2]Oudejans, Raôul RD, et al. "Errors in judging ‘offside’in football." Nature 404.6773 (2000): 33-33.
[3]D'Orazio, Tiziana, et al. "An investigation into the feasibility of real-time soccer offside detection from a multiple camera system." Circuits and Systems for Video Technology, IEEE Transactions on 19.12 (2009): 1804-1818.
[4] Calvanese, Diego, et al. "Can OWL model football leagues?." OWLED. 2007.
Soccer Offside Ontology
Content
1. Ontology
2. Conceptual Model
3. Term List
4. Use Case
5. Query Example
6. Data Annotation
7. Evaluation & Discussion
8. Getting Involved
Ontology
We provide a github repository for the ontology and all its previous versions. ontology git repo
We modularize the overall soccer offside ontology into three sub-ontologies: the individual ontology that encodes the specific match information such as teams and players in each team; the offside offence ontology that concentrates on the offside offence detection from the streaming data; and the domain literate ontology that focuses on filtering out offside-irrelevant data from the streaming data.
Conceptual Model
This figure shows the major classes and relations in order to describe the offside offence. When developing this ontology, we use [10] as the text corpus to extract a list of the offside relevant terms. The term list was then carefully examined and curated to create a conceptual model, which was refined and extended to create the offside offence ontology. In a soccer game, usually the player who is touching the ball is considered to be an attacker, along with his teammates. We use this to model the player who touches the ball as BallLastToucher, and the attackers as Attacker. An Attacker can either be the BallLastToucher or (hasTeammate some BallLastToucher). A Defender is defined as (Player and (playsAgainst some Attacker)), where playsAgainst is a symmetric property chain as (isOpponentOf o hasTeammate). Instead of manually labeling the competing relation (isOpponentOf) for each pair of opponent players, leveraging this property chain and a reasoner, the playsAgainst relationships are automatically established, which saves lots of tedious work, keeps a compact ontology and shows the value of the semantics. SecondLastDefender is one of the key concepts to define soccer offside, which is the subclass of both SecondLastPlayer and Defender. We directly annotate a player as SecondLastPlayer for each team by selecting the player who is the second-nearest to his own goal line among his team. This is to reflect the real world scenario that the assistant referee should always keep up with the second last player of his assigned half. The ball being played is an InFieldBall, whereas the other balls are BackupBall. When a player is classified as an Attacker, and isNearerToDefenderGoalLineThan both SecondLastDefender and InFieldBall, he is further classified as PlayerInOffsidePosition. If a player touches the ball or challenges an opponent, he is classified as PlayerInvolvedInActivePlay. Thus, according to the definition of offside offence, when a player is classified as both PlayerInOffsidePosition and PlayerInvolvedInActivePlay, he, who is therefore classified as PlayerCommitsOffsideOffence, commits the offside offence.
This figure illustrates the domain literate ontology. This use case is scoped to answer the question of who commits an offside offence. If a data item does not contain offside offence information, there is no need to execute the query on it. The purpose of this ontology module is to identify and eliminate irrelevant data by leveraging semantics to ask another question (an example is in Listing 2) of what the offside irrelevant positions are prior to execution of the offside query. For the data set of this use case, all ball positions, referee positions, goalkeeper glove positions and player’s positions are present. In this ontology, glove’s position GlovePosition, referee’s position RefereePosition, back up balls’ positions BackupBallPosition, positions of defenders who are not the second last player NotSecondLastDefenderPosition, positions of attackers who are in their own half (owl:intersectionOf (AttackerPosition and OwnHalfPosition)) are all offside irrelevant positions OffsideIrrelevantPosition.
For the purpose of illustration, we draw three players from each team in Figure 4. All of the player individuals have a type of Player, which is a concept in the offside offence ontology. hasTeam is a functional property with a domain of Player and a range of Team, while both hasTeammate and isOpponentOf are symmetric properties with Player as their domain and range. Further, hasTeammate is transitive, meaning that a player can be his own teammate. isOpponentOf is encoded only between two goalkeepers.
Term List
we have our curated term list: link
Use Case
We provide our use case : link
Query Demo and Reasoning Example
According to our use case, we have two major competency questions.
1. who commits an offside offence?
2. which position is an offside irrelevant position ?
The first questions further introduces three sub questions
1.1 who are the attackers/defenders ?
1.2 who is at offside position ?
1.3 who is involved in active play ?
The second question can be utilized to eliminate any irrelevant positions in the data processor, so as to make SPARQL queries faster.
Test individuals set up:
Two teams: teamA, teamB
Each team has a goalkeeper, and 7 other players
player_A6 and player_B6 are the second last player in each team.
Othe players are not second last players.
player_A1, player_A2, player_A3, player_A4 and player_B1 are not in their own half.
Other players are in their own half.
player_A2 touches the ball
player_A3 is nearer to the defender goal line than both ball and player_B6.
There are in total 4 balls, ball4, ball8, ball10, ball12.
Only one ball is in the filed being played, others are backup balls.
Q1: who are attackers/defenders?
prefix so: <http://tw.rpi.edu/web/Courses/Ontologies/2016/projects/soccer/ontology/…;
select ?attacker ?defender
where { ?attacker a so:Attacker. ?defender a so:Defender }
Reasoning example and answer:
conditions:
so:player_A2 so:touches so:ball4 (data)
so:Ball owl:EquilaventTo {ball4, ball8, ball10, ball12} (ontology)
so:BallLastToucher owl:EquilaventTo Player and (so:touches some Ball)
so:Attacker owl:EquilaventTo so:BallLastToucher or (so:hasTeammate some so:BallLastToucher)
so:player_A2 so:hasTeammate so:player_A3 (ontology)
Symmetric: so:hasTeammate (ontology)
Transitive: so:hasTeammate (ontology)
so:Teammate rdfs:range so:Player (ontology)
result:
player_A2, player_A3 are attackers
conditions:
so:player_B1 rdf:type so:NotSecondLastPlayer (ontology)
so:player_A2 so:hasTeammate so:player_A3 (ontology)
so:player_A3 so:hasTeammate so:player_A4 (ontology)
so:player_A4 so:hasTeammate so:player_A5 (ontology)
so:player_A5 so:hasTeammate so:player_A6 (ontology)
so:player_A6 so:hasTeammate so:player_A7 (ontology)
so:player_A7 so:hasTeammate so:goalkeeper_A (ontology)
so:hasTeammate rdfs:Range so:Player (ontology)
Symmetric: so:hasTeammate (ontology)
Transitive: so:hasTeammate (ontology)
so:goalkeeper_A so:isOpponentOf so:goalkeeper_B (ontology)
so:goalkeeper_B so:hasTeammate so:player_B1
Symmetric: so:isOpponentOf (ontology)
so:hasTeammate o so:isOpponentOf rdfs:SubPropertyOf so:playersAgainst (ontology)
so:player_A rdf:tye so:Attacker (inferred)
so:DefenderButNotSecondLastDefender owl:EquivalentTo so:Defender and so:NotSecondLastDefender.
result:
player_B1, goalkeeper_b are so:DefenderButNotSeconeLastDefender.
Q2: who is the second to last player?
prefix so: < http://tw.rpi.edu/web/Courses/Ontologies/2016/projects/soccer/ontology/…;
select ?player
where {?player a so:SecondLastDefender.}
Reasoning example and answer:
conditions:
so:player_B6 rdf:type so:SecondLastPlayer (data)
so:Player_B6 rdf:type Defender (inferred)
so:SecondLastDefender owl:EquivalentTo so:Defender and so:SecondLastPlayer (ontology)
result:
player_B6 is a second last defender.
Q3: who is at offside position ?
prefix so: <http://tw.rpi.edu/web/Courses/Ontologies/2016/projects/soccer/ontology/…;
select ?player
where {?player a so:PlayerAtOffsidePosition.}
Reasoning example and answer:
conditions
so:player_A3 rdf:type so:Attacker (inferred)
so:player_A3 so:isNearerToDefenderGoalLineThan so:player_B6 (data)
so:player_A3 so:isNearerToDefenderGoalLineThan so:ball4 (data)
so:player_B6 rdf:type so:SecondLastDefender (inferred)
so:Ball4 rdf:type so:InFieldBall (data)
so:PlayerAtOffsidePosition owl:EquivalentTo Attacker and (so:isNearerToDefenderGoalLineThan some so:InFieldBall) and (so:isNearerToDefenderGoalLineThan some so:SecondLastDefender)
result:
player_A3 is at offside position
Q4: who commits offside offence ?
prefix so: <http://tw.rpi.edu/web/Courses/Ontologies/2016/projects/soccer/ontology/…;
select ?player
where {?player a so:PlayerCommitsOffsideOffence. }
Reasoning example and answer:
conditions
so:player_A3 rdf:type so:PlayerAtOffsidePosition (inferred)
so:player_A3 so:isInvolvedIn so:opponent_challenge (data)
so:ActivePlay owl:EquivalentTo {ball_touch, opponent_challenge} (ontology)
so:PlayerInvolvedInActivePlay owl:EquivalentTo so:Player and (so:isInvolvedIn some so:ActivePlay) (ontology)
so:PlayerCommitsOffsideOffence owl:EquivalentTo so:PlayerAtOffsidePosition and so:PlayerInvolvedInActivePlay
result:
player_A3 commits offside offence.
Data Annotation
The original streaming game data comes in comma-delimited format with the schema (sid,ts,x,y,z,|v|,|a|,vx,vy,vz,ax,ay,az), where sid denotes the sensor ID; ts denotes the generation timestamp in pico-seconds; (x,y,z) denotes a sensor coordinate; and (|v|,|a|,vx,vy,vz,ax,ay,az) denotes sensor velocity, acceleration and their directions. In this paper, we use (sid,ts,x,y,z). Each shinguard of a player is installed with a sensor. We average sensor coordinates to obtain a player’s position.13 With the coordinates of the field markings, players and ball positions, we can calculate position coordinates to get information such as which balls are on or off the field or which players are in or not in their own half, etc. We use Euclidean distance to determine if there is an active play, the type of which is either a ball-touch or an opponent-challenge.14 We rank all players according to their distance from the ball in play. A ball-touch is identified if the nearest ball-player distance is less than 0.6 meter. We use the same method to count the cases of opponent-challenge. Once a ball-touch is detected, all attacking players’16 distance from the defender goal line and the ball will be calculated. Each player’s distance from his own goal line will also be calculated so as to determine who is the second-last player of each team. We then annotate the data as what this figure shows.
Evaluation & Discussion
Getting Involved
Interested in our work ? Please contact our team:
Rui Yan: yanr2@rpi.edu
Hao Zhong: zhongh3@rpi.edu
Our advising professor on this work: Dr. Deborah McGuinness