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 entityprocess, 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, ProcessualEntityProcess, 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).
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 |
Process
Processes are concrete individuals that happen in time and have a temporal extension (chronoid/time interval). Processes represent dynamic knowledge. A football match, a treatment of a patient in a hospital or the course of an illness are examples of processes.
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| Match | Process | locatedIn exactly 1 Stadium hasProcessPart exactly 1 FirstHalf hasProcessPart exactly 1 SecondHalf hasParticipant exactly 2 Team temporallyStartedBy exactly 1 StartOfMatch temporallyFinishedBy exactly 1 EndOfMatch |
| FirstHalf | Process | processPartOf exactly 1 Match temporallyStartedBy exactly 1 StartOfMatch temporallyFinishedBy exactly 1 EndOfFirstHalf |
| SecondHalf | Process | processPartOf exactly 1 Match temporallyStartedBy exactly 1 StartOfSecondHalf temporallyFinishedBy exactly 1 EndOfMatch |
Example 2a. Processual classes.Process classes.
Processes can have parts (hasParthasProcessPart, partOfprocessPartOf), which are also processual entitiessituations, attributives or further processes, e.g., the first half and the goal eventssituations are parts of the match. Continuants can participate in processual entitiesprocesses (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 |
| Instance | Type | Assertion |
|---|---|---|
| matchX | Match | locatedIn RedBullArenaLeipzig temporallyStartedBy startOfMatch temporallyFinishedBy endOfMatch numberOfSpectators “40000”^^xsd:int |
| half1 | FirstHalf | processPartOf matchX temporallyStartedBy startOfMatch temporallyFinishedBy endOfFirstHalf |
Example 2b. Processual instances.Process 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 |
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| PlayerQuality → Assists → PlayerGoals |
Quality | qualityOf exactly 1 Player processPartOf exactly 1 Match |
| TeamQuality → BallPossession → TeamGoals |
Quality | qualityOf exactly 1 Team processPartOf exactly 1 Match |
| WinnerLoserRelator | Relator | containsRole exactly 1 WinnerRole containsRole exactly 1 LoserRole processPartOf exactly 1 Match |
| PlayerRoleInTeam → Defender → Forward → Midfielder |
ContinuantPartRole | roleIn exactly 1 Team playedBy exactly 1 Player processPartOf exactly 1 Match |
| TeamRoleInMatch → HomeTeamRole → VisitingTeamRole |
ProcessualRole | roleIn exactly 1 Match playedBy exactly 1 Team processPartOf exactly 1 Match |
| PlayerRoleInGoal → AssistantRole → ScorerRole |
SituationalRole | roleIn exactly 1 Goal playedBy exactly 1 Player situationPartOf exactly 1 Goal processPartOf exactly 1 Match |
| TeamRoleInWinnerLoserRelator → WinnerRole → LoserRole |
RelationalRole | roleIn exactly 1 WinnerLoserRelator playedBy exactly 1 Team processPartOf 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, situational 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 entityprocess (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 situational role is the role that a participant plays in a situation (e.g., scorer and assistant role in a goal situation or roles played by a doctor and a patient in a risk/adverse situation in hospital). 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 entityprocess, situation, relator) using object properties roleOfroleIn or hasRolecontainsRole. 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 |
| Instance | Type | Assertion |
|---|---|---|
| a1GoalsEndOfFirstHalf | PlayerGoals | qualityOf playerA1 processPartOf matchX decimalValue 1 startedByDateTimeValue “2020-05-05T21:20:00”^^xsd:dateTime finishedByDateTimeValue “2020-05-05T22:30:00”^^xsd:dateTime |
| a1GoalsEndOfMatch | PlayerGoals | qualityOf playerA1 processPartOf matchX decimalValue 2 startedByDateTimeValue “2020-05-05T22:30:00”^^xsd:dateTime |
| a2RoleInTeam | Midfielder | roleIn teamA playedBy playerA2 processPartOf matchX finishedByDateTimeValue “2020-05-05T22:40:00”^^xsd:dateTime |
| teamARole | HomeTeamRole | roleIn matchX playedBy teamA |
| winnerLoserRelatorEndOfMatch | WinnerLoserRelator | existsAt endOfMatch processPartOf matchX |
| aWinnerRole | WinnerRole | roleIn 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.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 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.
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, situational roles or relational roles) do not have an existence time to be defined and are no parts of situations or processes, 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 entitySituations represent static knowledge. A situation can exist at a certain point in time or during a certain period of time and can be part or result of a process or another situation (e.g., a goal situation as a result of an attack in a football match).
| 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 |
| Domain class | GFO-light superclass | Restriction |
|---|---|---|
| MatchSituation | Situation | hasSituationPart some (MatchSituation or PlayerQuality or PlayerRoleInTeam or TeamQuality or TeamRoleInMatch or TeamRoleInWinnerLoserRelator or WinnerLoserRelator) processPartOf 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 hasPartsituationPartOf or hasSituationPart. Continuants can participate in situations (participatesIn, hasParticipant), e.g., the player A1 participates in a goal situation or the teams participate in the situation at the end of the match.
| 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 |
| Instance | Type | Assertion |
|---|---|---|
| situationEndOfMatch | MatchSituation | hasSituationPart winnerLoserRelatorEndOfMatch hasSituationPart aGoalsEndOfMatch hasSituationPart aBallPossessionEndOfMatch hasSituationPart teamARole hasSituationPart teamBRole hasSituationPart a1GoalsEndOfMatch hasSituationPart a2AssistsEndOfMatch hasSituationPart a1RoleImTeam hasSituationPart a22RoleImTeam hasSituationPart a33RoleImTeam existsAt endOfMatch processPartOf 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 |
| 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.
Different types of cConcrete individuals relate to time in different ways. While continuants, situations and attributives have an existence time (time period or boundary/point), processual entities happen/occur in time. Processes have a temporal extension ( or 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 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 more precisely startDateTimeValue and endDateTimeValueits specific subproperties, e.g., startedByDateTimeValue/finishedByDateTimeValue) in the data property assertion (e.g., Example 2b aGoal1, Example 3b a1GoalsEndOfFirstHalf/a1GoalsEndOfMatch/a2RoleImTeam). However, if a timestamp or periodtime 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 hasTimePeriodsuch as existsIn, existsAt, temporallyStartedBy or hasTimePointtemporallyFinishedBy (or hasStartTimePoint and hasEndTimePoint) (Example 2b half1, Example 3b winnerLoserRelatorEndOfMatch, Example 4b). If an attributive or a situation is assigned to a processual entityprocess or another situation using the object property existsInproperties situationPartOf or processPartOf without defining an existence time, this instance exists in the entire time of the processual entityprocess or situation. 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 |
| 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). If a temporal relation is applied to other concrete individuals as time intervals (i.e., attributive, continuant, process 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,).