GFO-light: General Formal Ontology (light version)
GFO-light contains some simplifications compared to the full version of General Formal Ontology (GFO) and is designed as a framework for the efficient development and foundation of domain/application ontologies. This guide describes the structure and a possible use of this lightweight top-level ontology in domain-specific projects, also for users who are not familiar with the basics of formal ontology. GFO-light is primarily concerned with categories of concrete individuals (continuant, processual entity, attributive and situation), i.e., entities that have an immediate relation to time (time entity) or to space-time. When developing a domain-specific ontology using GFO-light, please create your classes as subclasses of Continuant, Attributive, ProcessualEntity, Situation and TimeEntity (or their subclasses, the more specific the better). You can also create the desired object or data properties (if possible as subproperties of GFO-light properties).
Continuant
Material three-dimensional objects, their groups/aggregates and parts as well as immaterial two-, one- and zero-dimensional entities (i.e., surfaces, lines and points) are subsumed under the category Continuant. Continuants are concrete individuals that persist through time and are wholly present at every point of their existence time (lifetime).
Material continuants are individual 3-dimensional material objects (e.g., a person, a computer, a chopstick or a football stadium), material aggregates (groups) of objects that together form a unit (e.g., a research group at a university or a sports team) or material parts that have no natural boundary with the whole material object (e.g., part of a bone or of a chopstick).
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| Team | MaterialAggregate | hasMember some Player |
| Player | MaterialObject | memberOf exactly 1 Team |
| Stadium | MaterialObject | |
| FootballFieldSurface | Surface | hasOwner exactly 1 Stadium |
| FootballFieldBoundaryLine | Line | boundaryOf exactly 1 FootballFieldSurface |
Example 1a. Continuant classes.
Usually, connected objects are considered as single material objects, i.e., the object parts are firmly connected to the whole object, while loose objects can form a group/aggregate. When modelling a person, for example, you could consider their skeleton as a (connected) material object and as part of the human body. However, if we look at bone finds in the context of anthropology, the skeleton can be modelled as an aggregate of individual bones.
The object parts can be specified using the object properties hasPart or partOf. To model the membership of a member in a group/aggregate, the more specific object properties hasMember/memberOf should be used (Example 1b, playerA1). Material objects can be located in other material objects (locatedIn, e.g., the driver is located in the car).
Immaterial continuants are visible or imaginary surfaces, lines and points that are located on material continuants or in them. In the anthropology use case, for example, these can be certain planes (e.g., frontal plane), axes (e.g., longitudinal axis) and points (e.g., gonion) of the human skeleton. Other examples are the surface and the boundary lines of the football field or the penalty spot. Immaterial continuants can be assigned to a corresponding material continuant using the object property hasOwner. They can also be considered as (outer or inner) boundaries (boundaryOf). Note that surfaces are boundaries of material continuants, lines are boundaries of surfaces and points are boundaries of lines.
| Instance | Type | Assertion |
|---|---|---|
| teamA | Team | participatesIn matchX |
| playerA1 | Player | memberOf teamA participatesIn aGoal1 participatesIn aGoal2 |
| RedBullArenaLeipzig | Stadium | |
| fieldOfRbArena | FootballFieldSurface | hasOwner RedBullArenaLeipzig |
| sectorAFieldBoundary | FootballFieldBoundaryLine | boundaryOf fieldOfRbArena |
Example 1b. Continuant instances.
Processual Entity
Processual entities are concrete individuals that happen/occur in time. They can be instantaneous (events) or have a temporal extension (processes). A football match, a treatment of a patient in a hospital or the course of an illness are examples of processes. Events are instantaneous processual entities, i.e., they occur at one point in time. An event can be assigned to a process (be part of the process), i.e., happen at a point in the process time, result from a process or trigger a process. An example is a goal as a result of an attack in a football match.
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| Match | Process | locatedIn exactly 1 Stadium hasPart exactly 1 FirstHalf hasPart exactly 1 SecondHalf hasParticipant exactly 2 Team hasStartPointInTime exactly 1 StartOfMatch hasEndPointInTime exactly 1 EndOfMatch |
| FirstHalf | Process | partOf exactly 1 Match hasStartPointInTime exactly 1 StartOfMatch hasEndPointInTime exactly 1 EndOfFirstHalf |
| SecondHalf | Process | partOf exactly 1 Match hasStartPointInTime exactly 1 StartOfSecondHalf hasEndPointInTime exactly 1 EndOfMatch |
| Goal | Event | partOf exactly 1 Match |
Example 2a. Processual classes.
Processes can have parts (hasPart, partOf), which are also processual entities, e.g., the first half and the goal events are parts of the match. Continuants can participate in processual entities (participatesIn, hasParticipant), e.g., the teams A and B participate in the football match or the player A1 participates in the goal event (Example 1b, teamA, playerA1). Processual entities can take place (locatedIn) in material objects (e.g., a football match in a stadium or an illness in a person).
| Instance | Type | Assertion |
|---|---|---|
| matchX | Match | locatedIn RedBullArenaLeipzig hasStartPointInTime startOfMatch hasEndPointInTime endOfMatch numberOfSpectators “40000”^^xsd:int |
| half1 | FirstHalf | partOf matchX hasStartPointInTime startOfMatch hasEndPointInTime endOfFirstHalf |
| aGoal1 | Goal | partOf half1 dateTimeValue “2020-05-05T21:20:00”^^xsd:dateTime |
Example 2b. Processual instances.
Attributive
Qualities (attributes, traits, characteristics, etc.) of concrete individuals, relations (relators) between them and roles that objects can play in different contexts are subsumed under the category Attributive. Attributives are individuals that depend on other individuals by some kind of dependency relation.
Qualities are attributives that typically inhere in its bearer and can possess values. Examples are observable or measurable characteristics of single objects, e.g., persons, (such as weight and height, laboratory parameters or symptoms), qualities of object groups (e.g., goals scored by a football team in a match) or of processes (e.g., the number of spectators as quality of a football match). The qualities can be defined in two ways. If they have a value (representable as a number, string, date, etc.), do not require the specification of existence time and are no parts of situations, domain-specific data properties can simply be defined as subproperties of decimalValue (e.g., numberOfSpectators), stringValue, dateTimeValue, etc. These domain-specific properties can then be used in data property assertions for a direct assignment of the value to the corresponding bearer (Example 2b, matchX). In all other cases, a separate domain-specific class (e.g., PlayerGoals) must be created as a subclass of Quality and its instances can be assigned to the bearers using the object properties qualityOf or hasQuality. In this case, the existence time can be specified for the quality instances (Example 3b, a1GoalsEndOfFirstHalf, a1GoalsEndOfMatch).
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| PlayerQuality → Assists → PlayerGoals |
Quality | qualityOf exactly 1 Player existsIn exactly 1 Match |
| TeamQuality → BallPossession → TeamGoals |
Quality | qualityOf exactly 1 Team existsIn exactly 1 Match |
| WinnerLoserRelator | Relator | hasRole exactly 1 WinnerRole hasRole exactly 1 LoserRole existsIn exactly 1 Match |
| PlayerRoleInTeam → Defender → Forward → Midfielder |
ContinuantPartRole | roleOf exactly 1 Team playedBy exactly 1 Player existsIn exactly 1 Match |
| TeamRoleInMatch → HomeTeamRole → VisitingTeamRole |
ProcessualRole | roleOf exactly 1 Match playedBy exactly 1 Team existsIn exactly 1 Match |
| TeamRoleInWinnerLoserRelator → WinnerRole → LoserRole |
RelationalRole | roleOf exactly 1 WinnerLoserRelator playedBy exactly 1 Team existsIn exactly 1 Match |
Example 3a. Attributive classes.
A role is a relational entity that links a continuant (role player) with some context, in which the continuant plays that role. We distinguish between continuant part roles, processual roles and relational roles. A continuant part role is the role that a continuant part plays in the whole continuant (e.g., the processor is part of the computer and has the task/function//role to process commands or John is part/member of the football team and plays the role of midfielder, Example 3b, a2RoleImTeam). A processual role is the role that a participant plays in a processual entity (e.g., team A plays the home team role and team B plays the visiting team role in a football match, Example 3b, teamARole). A relational role is the role that an entity plays in a relation (relator, see the next paragraph). Roles are assigned to the corresponding context entity (continuant, processual entity, relator) using object properties roleOf or hasRole. The role players are associated with the roles they play using object properties plays or playedBy.
| Instance | Type | Assertion |
|---|---|---|
| a1GoalsEndOfFirstHalf | PlayerGoals | qualityOf playerA1 existsIn matchX decimalValue 1 startDateTimeValue “2020-05-05T21:20:00”^^xsd:dateTime endDateTimeValue “2020-05-05T22:30:00”^^xsd:dateTime |
| a1GoalsEndOfMatch | PlayerGoals | qualityOf playerA1 existsIn matchX decimalValue 2 startDateTimeValue “2020-05-05T22:30:00”^^xsd:dateTime |
| a2RoleImTeam | Midfielder | roleOf teamA playedBy playerA2 existsIn matchX endDateTimeValue “2020-05-05T22:40:00”^^xsd:dateTime |
| teamARole | HomeTeamRole | roleOf matchX playedBy teamA |
| winnerLoserRelatorEndOfMatch | WinnerLoserRelator | hasPointInTime endOfMatch existsIn matchX |
| aWinnerRole | WinnerRole | roleOf winnerLoserRelatorEndOfMatch playedBy teamA |
Example 3b. Attributive instances. a1GoalsEndOfFirstHalf represents the number of goals of playerA1 in the time period between his first and second goal. a1GoalsEndOfMatch is the number of goals of playerA1 after the second goal. a2RoleImTeam is a midfielder (continuant part) role of teamA that is played by playerA2 (this role has an end time due to substitution). teamARole is the home team (processual) role of matchX that is played by teamA. aWinnerRole is the winner (relational) role of winnerLoserRelatorEndOfMatch that is also played by teamA.
Relators are attributives that connect other entities (role players) by relational roles (played by role players), i.e., represent individual relation instances. For example, a relator could be defined that describes the relative location of an object (playing the target object role) in relation to another object (playing the reference object role), e.g., the location of a person relative to the city centre or the location of an anatomical structure relative to the longitudinal axis. Such relators can be further classified, e.g., according to direction (in anthropology/anatomy, e.g., dorsal, ventral or lateral). Other examples are the marriage (relator) of John and Mary (in which Mary plays the wife role and John the husband role) or the winner-loser relator (Example 3b, winnerLoserRelatorEndOfMatch, aWinnerRole).
Similar to qualities, relations can also be represented by simple object properties (such as hasPart). However, if the existence time of the relation is relevant or it (or its roles) are parts of some situations, a relator (e.g., with a part and a whole role) should be used instead. An existence time can be defined both for relators themselves and for the individual roles (Example 3b, winnerLoserRelatorEndOfMatch, a2RoleImTeam).
If the individual roles (regardless of the type, i.e., continuant part roles, processual roles or relational roles) do not have an existence time to be defined and are no parts of situations, they can likewise be represented by object properties. The relative position relator (see above) can, for example, be linked directly to the corresponding objects using the object properties hasTargetObject and hasReferenceObject. Similarly, football players can be assigned directly to a team using the properties forwardOf, defenderOf, etc. It also works with processual roles, the two playing teams can be associated to the football match by properties homeTeamOf and visitingTeamOf.
Situation
Situations are combinations/constellations of attributives that belong together in the context of the use case under consideration. A situation can exist at a specific point in time or during a time period and may arise in a processual entity or result from a processual entity.
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| MatchSituation | Situation | hasPart some (PlayerQuality or TeamQuality or WinnerLoserRelator or PlayerRoleInTeam or TeamRoleInMatch or TeamRoleInWinnerLoserRelator) existsIn exactly 1 Match |
Example 4a. Situation class.
At the end of a football match (process), for example, a situation may arise in which one team has scored two goals and the other team one (the number of goals is a team's quality). A winner-loser relator can also be seen as part of this situation, with one team playing the winner role and the other team playing the loser role. Another example is a risk situation when treating a patient in hospital if his laboratory values (qualities) are in the critical range over a certain period of time. The desired attributives can be assigned to a situation using object properties partOf or hasPart.
| Instance | Type | Assertion |
|---|---|---|
| situationEndOfMatch | MatchSituation | hasPart winnerLoserRelatorEndOfMatch hasPart aGoalsEndOfMatch hasPart aBallPossessionEndOfMatch hasPart teamARole hasPart teamBRole hasPart a1GoalsEndOfMatch hasPart a2AssistsEndOfMatch hasPart a1RoleImTeam hasPart a22RoleImTeam hasPart a33RoleImTeam hasPointInTime endOfMatch existsIn matchX |
Example 4b. Situation instance. The situation at the end of the match contains all relevant attributives: winner-loser relator, teams’ qualities (aGoalsEndOfMatch, aBallPossessionEndOfMatch), teams’ processual roles in match (teamARole, teamBRole), players’ qualities (a1GoalsEndOfMatch, a2AssistsEndOfMatch), players’ continuant part roles in team (a1RoleImTeam, a22RoleImTeam, a33RoleImTeam).
Time Entity
The time entities defined in GFO-light are points in time (time boundaries) and time intervals/periods (chronoids), which consist of points in time.
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| StartOfMatch | TimeBoundary | startPointInTimeOf exactly 1 FirstHalf startPointInTimeOf exactly 1 Match |
| EndOfFirstHalf | TimeBoundary | endPointInTimeOf exactly 1 FirstHalf |
| StartOfSecondHalf | TimeBoundary | startPointInTimeOf exactly 1 SecondHalf |
| EndOfMatch | TimeBoundary | endPointInTimeOf exactly 1 SecondHalf endPointInTimeOf exactly 1 Match |
Example 5a. Time classes.
Different types of concrete individuals relate to time in different ways. While continuants, situations and attributives have an existence time (time period or point), processual entities happen/occur in time. Processes have a temporal extension (chronoid), whereas events occur at a point in time (time boundary) and can relate to a process (e.g., result from a process or trigger a process). There are two ways for assigning a timestamp or a time period to concrete individuals in a domain-specific ontology. The simplest option is to use the data property dateTimeValue (or more precisely startDateTimeValue and endDateTimeValue) in the data property assertion (e.g., Example 2b aGoal1, Example 3b a1GoalsEndOfFirstHalf/a1GoalsEndOfMatch/a2RoleImTeam). However, if a timestamp or period is to be defined once and reused several times for different individuals, instances of the classes TimeBoundary or Chronoid must be created, data property assertions based on the aforementioned data properties must be defined for them (Example 5b) and the instances must then be used in the object property assertions of the desired individuals based on the object properties hasTimePeriod or hasTimePoint (or hasStartTimePoint and hasEndTimePoint) (Example 2b half1, Example 3b winnerLoserRelatorEndOfMatch, Example 4b). If an attributive or a situation is assigned to a processual entity using the object property existsIn without defining an existence time, this instance exists in the entire time of the processual entity. In the Example 3b (a2RoleImTeam), only the end time of the player’s role in team is defined. The start time of the role coincides with the start of the match and does not need to be defined.
| Instance | Type | Assertion |
|---|---|---|
| startOfMatch | StartOfMatch | startPointInTimeOf half1 startPointInTimeOf matchX dateTimeValue “2020-05-05T21:00:00”^^xsd:dateTime |
Example 5b. Time instance.