GFO-light contains some simplifications compared to the full version of General Formal Ontology (GFO, Loebe, F. et al. (2022). GFO: The General Formal Ontology.) 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 ontologies. GFO-light is primarily concerned with categories of concrete individuals (Continuant, Attributive, and Situation), i.e., entities that have an immediate relation to time (Time Entity) or to space-time.
Tip
GFO-light extends GFO-core (i.e., adopts all GFO-core axioms), which contains the core GFO entities and serves as a common basis for both GFO variants (light and full). For some use cases, it may be sufficient to use GFO-core alone as a kind of minimal top-level ontology.
Important
When developing a domain-specific ontology using GFO-core or GFO-light, please create your classes as subclasses of Continuant, Attributive, 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-core or GFO-light properties).
Fig. 1. GFO-core overview (The figure shows all categories and selected relations.). Individuals are bearers of attributives (hasAttributive/attributiveOf, see Attributive), can consist of parts (hasPart/partOf), and can be temporally related to other individuals (subproperties of temporallyRelatedWith, see Time Entity). Concrete individuals are related to time (hasTime, see Time Entity). Situations (Situation) can be static (State) or dynamic (Process) and can have parts (hasSituationPart/situationPartOf). States can only consist of static parts (i.e., attributives or states), while processes can consist of both static and dynamic parts (i.e., attributives, states, or processes). Continuants (Continuant) can participate in situations (participatesIn/hasParticipant). Situations can lead to (leadsTo/resultsFrom) or cause (causes/causedBy) further situations.
Fig. 2. GFO-light overview (The figure shows all categories and selected relations. The GFO-core categories are displayed as filled boxes.)
 | Continuant Object parts can be specified using the object properties hasPart/partOf. To model the membership of a member in a group/aggregate, the object properties hasMember/memberOf should be used. Objects and situations can be located in other objects (locatedIn). Information objects denote/designate, describe, specify, or represent (represents/representedBy) other entities. Boundaries of objects are surfaces, boundaries of surfaces are lines, and boundaries of lines are points. Lines can pass through (spatiallyPassesThrough, spatiallyStartsOn, spatiallyEndsOn) various points. Object boundaries can be assigned to the corresponding object using the object property hasOwner. (see Continuant) |
 | Attributive Qualities, relators, and roles are attributives. A role is a relational entity that links an individual (role player) with some context (object, object aggregate, situation, relator), in which the individual plays that role. Roles are assigned to the corresponding context entity using object properties roleIn/containsRole. The role players are associated with the roles they play using object properties plays/playedBy. Individuals are quality bearers (hasQuality/qualityOf) and are related by relators (relatedBy/relates) in which they play a role. (see Attributive) |
Social or material (three-dimensional) objects, their groups/aggregates, parts, and boundaries (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).
Objects are social or material entities that can exist independently of each other (e.g., a person, a computer, a chopstick, or a football stadium). Objects can be located in other objects (locatedIn, e.g., the driver is located in the car). Information objects are symbolic entities that denote/designate, describe, specify, or represent (represents/representedBy) other entities. Titles, descriptions, specifications (e.g., the specification of an algorithm), models (e.g., UML models), or computer programmes are examples of information objects.
Important
The category InformationObject is a simplified way of modelling symbolic objects, their parts, and the entities they represent, without distinguishing between, for example, content and information carriers. For advanced use cases, please use specific information artefact ontologies such as Design Science Artifact Ontology (DS-AO) or Information Artifact Ontology (IAO).
Object aggregates are groups of objects that together form a unit (e.g., a research group at a university or a sports team). To model the membership of a member in a group/aggregate, the object properties memberOf/hasMember should be used (Example 1b, playerA1).
Object parts are material entities that cannot exist independently of the corresponding whole object (e.g., part of a bone or of a chopstick). The relation between an object and its parts can be specified using the object properties hasPart/partOf.
While the object parts are firmly connected to the entire object, the aggregate members are loose objects. When modelling a person, for example, you could consider their skeleton as an 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. Another example is a computer. A kit of computer components is an object aggregate before assembly and an object (a computer) afterwards. However, if the components are thrown into the case without being correctly connected, it is not a computer, but the components are simply located in (locatedIn) the case.
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| Team | ObjectAggregate | hasMember some Player |
| Player | Object | memberOf exactly 1 Team |
| Stadium | Object | |
| FootballFieldSurface | Surface | hasOwner exactly 1 Stadium |
| FootballFieldBoundaryLine | Line | boundaryOf exactly 1 FootballFieldSurface |
Example 1a. Continuant classes.
Object boundaries are 0-, 1-, or 2-dimensional (visible or imaginary) entities (i.e., points, lines, and surfaces) that border objects (natural boundaries) or are located inside them (inner boundaries). 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. Boundaries of objects are surfaces, boundaries of surfaces are lines and boundaries of lines are points. Such relationships are specified using object properties boundaryOf, innerBoundaryOf, or naturalBoundaryOf. Lines are not necessarily straight. They can be, for example, curves or broken lines that pass through (spatiallyPassesThrough, spatiallyStartsOn, spatiallyEndsOn) various points and form a corner, a triangle, or a polygon. Object boundaries can be assigned to a corresponding object using the object property hasOwner.
| 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.
Note
In contrast to GFO-full (see Loebe, F. et al. (2022). GFO: The General Formal Ontology.), GFO-light does not support presentic objects (presentials) but only temporally extended objects (continuats). However, GFO-light enables you to define the validity/existence time of attributives of the objects and states in which they participate, either as a time interval or as a point in time.
Note
GFO-full includes a sophisticated space module based on the dual nature of space (phenomenal vs. extensional space) and distinguishes between boundaries of material objects and boundaries of spatial regions (see Baumann, R. et al. (2016). Towards an Ontology of Space for GFO., Loebe, F. et al. (2021). Developing GFO 2.0 Further – Initiating the Modules of Space and Material Objects.). For simplicity, GFO-light only considers boundaries of material objects.
Qualities (attributes, traits, characteristics, etc.) of individuals, relations (relators) between them, and roles they 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 3b, 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 2b, a1GoalsEndOfFirstHalf, a1GoalsEndOfMatch).
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| PlayerQuality → Assists → PlayerGoals | Quality | qualityOf exactly 1 Player situationPartOf exactly 1 Match |
| TeamQuality → BallPossession → TeamGoals | Quality | qualityOf exactly 1 Team situationPartOf exactly 1 Match |
| WinnerLoserRelator | Relator | containsRole exactly 1 WinnerRole containsRole exactly 1 LoserRole situationPartOf exactly 1 Match |
| PlayerRoleInTeam → Defender → Forward → Midfielder | Role | roleIn exactly 1 Team playedBy exactly 1 Player situationPartOf exactly 1 Match |
| TeamRoleInMatch → HomeTeamRole → VisitingTeamRole | Role | roleIn exactly 1 Match playedBy exactly 1 Team situationPartOf exactly 1 Match |
| PlayerRoleInGoal → AssistantRole → ScorerRole | Role | roleIn exactly 1 Goal playedBy exactly 1 Player situationPartOf exactly 1 Goal situationPartOf exactly 1 Match |
| TeamRoleInWinnerLoserRelator → WinnerRole → LoserRole | Role | roleIn exactly 1 WinnerLoserRelator playedBy exactly 1 Team situationPartOf exactly 1 Match |
Example 2a. Attributive classes.
A role is a relational entity that links a continuant (role player) with some context (object, object aggregate, situation, relator), in which the continuant plays that role.
- An object part can play a (e.g., functional) role in the whole object (e.g., the processor is part of the computer and has the task/function/role to process commands).
- A member (object) of a social group (object aggregate) can play a social role in that group (e.g., John is member of the football team and plays the role of midfielder, Example 2b, a2RoleInTeam).
- Objects can play processual or situational roles in processes (e.g., team A plays the home team role and team B plays the visiting team role in a football match, Example 2b, teamARole) or states (e.g., scorer and assistant role in a goal state or roles played by a doctor and a patient in a risk/adverse state in hospital) in which they participate.
- Objects can play relational roles in a relation (relator, see the next paragraph).
Roles are assigned to the corresponding context entity (object, object aggregate, situation, relator) using object properties roleIn or containsRole. The role players are associated with the roles they play using object properties plays or playedBy.
| Instance | Type | Assertion |
|---|---|---|
| a1GoalsEndOfFirstHalf | PlayerGoals | qualityOf playerA1 situationPartOf matchX decimalValue 1 startedByDateTimeValue “2020-05-05T21:20:00”^^xsd:dateTime finishedByDateTimeValue “2020-05-05T22:30:00”^^xsd:dateTime |
| a1GoalsEndOfMatch | PlayerGoals | qualityOf playerA1 situationPartOf matchX decimalValue 2 startedByDateTimeValue “2020-05-05T22:30:00”^^xsd:dateTime |
| a2RoleInTeam | Midfielder | roleIn teamA playedBy playerA2 situationPartOf matchX finishedByDateTimeValue “2020-05-05T22:40:00”^^xsd:dateTime |
| teamARole | HomeTeamRole | roleIn matchX playedBy teamA |
| winnerLoserRelatorEndOfMatch | WinnerLoserRelator | hasTime endOfMatch situationPartOf matchX |
| aWinnerRole | WinnerRole | roleIn winnerLoserRelatorEndOfMatch playedBy teamA |
Example 2b. 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. a2RoleInTeam is a midfielder (social) role in teamA that is played by playerA2 (this role has an end time due to substitution). teamARole is the home team (processual) role in matchX that is played by teamA. aWinnerRole is the winner (relational) role in winnerLoserRelatorEndOfMatch that is also played by teamA.
Note
GFO-light uses a simplified role model compared to GFO-full. In GFO-full there are three types of roles (see Loebe, F. et al. (2022). GFO: The General Formal Ontology., Loebe, F. (2007). Abstract vs. social roles: Towards a general theoretical account of roles.): relational role as sibling of quality and subclass of attributive, processual role as subclass of process, and social role as social/socio continuant. In GFO-light, no role types (no subclasses of Role) are explicitly defined. The roles are implicitly differentiated by their assignment (roleIn) to the corresponding context entities (object, object aggregate, situation, relator).
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 2b, 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 2b, winnerLoserRelatorEndOfMatch, a2RoleInTeam).
If the individual 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.
Situations are combinations of contextually related attributives. Situations can be static (state) or dynamic (process) and can have parts (hasSituationPart/situationPartOf). States can only consist of static parts (i.e., attributives or states), while processes can consist of both static and dynamic parts (i.e., attributives, states, or processes). Continuants can participate in situations (participatesIn/hasParticipant). Situations can take place (locatedIn) in objects. Situations can lead to (leadsTo/resultsFrom) or cause (causes/causedBy) further situations.
Note
In GFO-full, several further types of situations (e.g., object situations, presentic situations, and situoids) are considered (see Loebe, F. et al. (2022). GFO: The General Formal Ontology., Burek, P. et al. (2024). Ontologically Founded Design Patterns for Situation Modeling.). GFO-light only distinguishes between static (states) and dynamic (processes) situations. This makes it easier for domain experts to choose an appropriate GFO-light category for a specific use case, i.e., to use states for modelling static knowledge and processes for modelling dynamic knowledge.
Processes are dynamic situations that happen in time and have a temporal extension (period of time/chronoid). Processes represent dynamic knowledge, i.e., their attributives or participants change over time. Processes are cohesive, i.e., causally and temporally connected (e.g., a football match, a treatment of a patient in a hospital, or the course of an illness). Processes can have (hasSituationPart) both static and dynamic parts (i.e., attributives, states, or processes), e.g., the first half (dynamic) and the goal states (static) are parts of the match.
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| Match | Process | locatedIn exactly 1 Stadium hasSituationPart exactly 1 FirstHalf hasSituationPart exactly 1 SecondHalf hasParticipant exactly 2 Team temporallyStartedBy exactly 1 StartOfMatch temporallyFinishedBy exactly 1 EndOfMatch |
| FirstHalf | Process | situationPartOf exactly 1 Match temporallyStartedBy exactly 1 StartOfMatch temporallyFinishedBy exactly 1 EndOfFirstHalf |
| SecondHalf | Process | situationPartOf exactly 1 Match temporallyStartedBy exactly 1 StartOfSecondHalf temporallyFinishedBy exactly 1 EndOfMatch |
Example 3a. Process classes.
Continuants can participate in processes (participatesIn/hasParticipant), e.g., the teams A and B participate in the football match (Example 1b, teamA). Processes can take place (locatedIn) in objects (e.g., a football match in a stadium or an illness in a person).
| Instance | Type | Assertion |
|---|---|---|
| matchX | Match | locatedIn RedBullArenaLeipzig temporallyStartedBy startOfMatch temporallyFinishedBy endOfMatch numberOfSpectators “40000”^^xsd:int |
| half1 | FirstHalf | situationPartOf matchX temporallyStartedBy startOfMatch temporallyFinishedBy endOfFirstHalf |
Example 3b. Process instances.
States are static situations that happen either at a point in time (time boundary) or during a period of time (chronoid). States represent static knowledge, i.e., their attributives and participants do not change. States are cohesive, i.e., causally and temporally connected (e.g., a phase of increased temperature). A state can have (hasSituationPart) only static parts and can be a static part or result of another situation (e.g., a goal state as part of the match and result of an attack).
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| MatchState | State | hasSituationPart some (MatchState or PlayerQuality or PlayerRoleInTeam or TeamQuality or TeamRoleInMatch or TeamRoleInWinnerLoserRelator or WinnerLoserRelator) situationPartOf exactly 1 Match |
Example 4a. State class.
At the end of a football match (process), for example, a state 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 state, with one team playing the winner role and the other team playing the loser role. Another example is a risk state 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 the state using object properties situationPartOf/hasSituationPart. Continuants can participate in states (participatesIn/hasParticipant), e.g., the player A1 participates in a goal state or the teams participate in the state at the end of the match.
| Instance | Type | Assertion |
|---|---|---|
| stateEndOfMatch | MatchState | hasSituationPart winnerLoserRelatorEndOfMatch hasSituationPart aGoalsEndOfMatch hasSituationPart aBallPossessionEndOfMatch hasSituationPart teamARole hasSituationPart teamBRole hasSituationPart a1GoalsEndOfMatch hasSituationPart a2AssistsEndOfMatch hasSituationPart a1RoleInTeam hasSituationPart a22RoleInTeam hasSituationPart a33RoleInTeam hasTime endOfMatch situationPartOf matchX |
Example 4b. State instance. The state 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’ social roles in team (a1RoleInTeam, a22RoleInTeam, a33RoleInTeam).
Processes and states are considered cohesive, i.e. they are causally and temporally connected. For modelling situations (processes or states) that are contextually but not temporally connected, situation aggregates should be used. Examples of process aggregates include a series of lectures in a semester or a football league season, which consist of (hasMember) other contextually, but not temporally interconnected processes (i.e., single lectures or football matches). A state aggregate is, for example, a situation consisting of all not temporally interconnected phases/states of increased temperature during the course of an illness. However, it is also possible to combine both processes and states, as well as other situation aggregates, in a single situation aggregate.
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 | temporallyStarts exactly 1 FirstHalf temporallyStarts exactly 1 Match |
| EndOfFirstHalf | TimeBoundary | temporallyFinishes exactly 1 FirstHalf |
| StartOfSecondHalf | TimeBoundary | temporallyStarts exactly 1 SecondHalf |
| EndOfMatch | TimeBoundary | temporallyFinishes exactly 1 SecondHalf temporallyFinishes exactly 1 Match |
Example 5a. Time classes.
Concrete individuals have an existence time (time boundary/point in time or chronoid/time interval). There are two ways for assigning a timestamp or a time interval/period to concrete individuals in a domain-specific ontology. The simplest option is to use the data property dateTimeValue (or its specific subproperties, e.g., startedByDateTimeValue/finishedByDateTimeValue) in the data property assertion (e.g., Example 2b a1GoalsEndOfFirstHalf/a1GoalsEndOfMatch/a2RoleInTeam). However, if a timestamp or time interval 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 such as hasTime, temporallyStartedBy, or temporallyFinishedBy (Example 3b half1, Example 2b winnerLoserRelatorEndOfMatch, Example 4b). If an attributive or a situation is assigned to another situation using the object property situationPartOf without defining an existence time, this instance exists in the entire time of the situation. In the Example 2b (a2RoleInTeam), 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 | temporallyStarts half1 temporallyStarts matchX dateTimeValue “2020-05-05T21:00:00”^^xsd:dateTime |
Example 5b. Time instance.
GFO-light defined temporal relations between individuals based on Allen, J. F. (1983). Maintaining knowledge about temporal intervals.. For this purpose, 13 subproperties of the object property temporallyRelatedWith were introduced (after, before, during, temporallyContains, temporallyEqual, temporallyFinishedBy, temporallyFinishes, temporallyMeets, temporallyMetBy, temporallyOverlappedBy, temporallyOverlaps, temporallyStartedBy, and temporallyStarts). In addition, object properties hasTemporalPart (as a shortcut for temporallyStartedBy or temporallyFinishedBy or temporallyContains) and temporalPartOf (as a shortcut for temporallyStarts or temporallyFinishes or during) were defined. If a temporal relation is applied to other concrete individuals as time intervals (i.e., attributive, continuant, or situation), it is propagated to their existence times. 'StartOfMatch temporallyStarts Match' (Examples 5a and 5b) means that the time of the match (a chronoid) starts at the defined point of time. Some temporal relations can also be applied to points in time (before/after, temporallyEqual) or a point in time and a time interval (before, temporallyStarts, temporallyFinishes, during, or their inverse relations). For some temporal relations (object properties), corresponding shortcuts (data properties) are defined for direct use in data property assertions (afterDateTimeValue, beforeDateTimeValue, containsDateTimeValue, finishedByDateTimeValue, startedByDateTimeValue, hasTemporalPartDateTimeValue).
Note
The basic theory of phenomenal time in GFO-full is inspired by the ideas of Franz Brentano (Baumann, R. et al. (2014). Axiomatic theories of the ontology of time in GFO.). According to this theory, each chronoid has exactly two extremal time boundaries (which can be understood as its first and last time point) and infinitely many inner time boundaries. Time boundaries can coincide, i.e., have a temporal distance of zero, although they are different entities. GFO-light shares this view, but also provides a simplified option for modelling a point in time simultaneously as the end of a time interval and the start of the following time interval. In addition, GFO-light allows the application of some Allen's relations to points in time, so that, for example, temporallyEqual, applied to points in time, can be understood as equivalent to coincidesWith from GFO-full.