3. Combined Ontology

The combined ontology model was made with the following scope, purpose, intended users, and intended uses. It can be downloaded here: sofijanimazoewangtransportationhub

 

Scope: An accessible transportation hub including an S-Bahn station, bridge for S-Bahns and regional trains, a highway, and wastewater treatment. The wastewater treatment includes a primary sedimentation tank and a sludge digester tank. Each system includes civil and functional (environmental/transportation) components. 

 

Purpose: This ontology serves to streamline conceptual design of an accessible transportation hub with in-house wastewater treatment for civil, environmental, and transportation engineers and provide a knowledge base for key design parameters. 

Intended Users: Civil/transportation/environmental engineers and accessibility consultants designing the accessible transportation hub. 

 

Intended Uses:

1. Knowledge base of varying engineering disciples. In such a large project, there will be many engineering teams (civil, transportation, environmental) working on the same project. We were inspired by the Doha Metro Project and the need to create knowledge bases while working with many companies on such a big project (Hartmann, 2024). 

2. Knowledge base of design values in conjunction with Dynamo. This ontology is meant to be used in conjugation with our Dynamo model. All changes made in the Dynamo model should also be noted in the ontology for clarity. 

3. To understand basic concepts of the transportation hub. Non-engineers working on the project, like accessibility consultants, will also have access to the ontology to recommend accessibility measures. Government workers will also have access to the ontology to be able to easily understand the project’s goals.

 


Protégé Ontology Classes

The first level of classes was based on the subsystems within the project: S-Bahn Station, Highway, Bridge, Primary Sedimentation Tank, Sludge Digester Tank. Primary Sedimentation Tank and Sludge Digester Tank were grouped together under Wastewater Treatment due to their extreme connectedness.

1.1 SBahn Station

New classes were created: AccessibilitySBahnStation, CivilEngSBahnStation, TransportationEngSBahnStation to reflect the different engineering teams working on the project. This was done in relation to the main intended use of this project: creating a knowledge base where engineers can easily see knowledge related to their discipline and all systems and knowledge related to other disciplines. For example, here it is important for a civil engineer to know what accessibility actions are recommended by the sustainability consultant. Previous classes were edited and combined under TransportationEngSBahnStation and CivilEngSBahnStation. It is important to note that subclasses related to civil, environmental, and transportation engineers were always made disjoint since these engineering teams have different goals/scopes.

Accessibility measures added in the Dynamo Model were added here (2 elevators so that if 1 is out of service, there is a backup), and ones which could not be shown in Dynamo. Some which could not be shown in Dynamo but are recommended in our model are: (1) having an accessible platform height difference, (2) having a display downstairs of arrival and departure times so that people do not have to rush unnecessarily, (3) speakers announcing departure times which are soon for visually impaired. 

screenshot-2025-02-11-at-3-39-38%e2%80%afam 

1.2 Wastewater Treatment

The original ontologies used in this section were (1) an ontology of a wastewater treatment plant and (2) a primary sedimentation tank. To apply these to our current system, where a primary sedimentation tank and sludge digester are used, a new sludge digester “sub-ontology” was created, following the format of the primary sedimentation tank ontology. The unused technology from the wastewater treatment plant ontology were included inFutureIntegrationContextImprovements in order to provide knowledge for flexible design if our system needed to change in the future. 

screenshot-2025-02-11-at-3-39-43%e2%80%afam

1.2.1 Wastewater Treatment -> Primary Sedimentation Tank: This ontology was kept very similar to the original because it had the same scope, purpose, users, and uses. Class names were slightly changed for organization according to Noy McGuiness. 

screenshot-2025-02-11-at-3-39-48%e2%80%afam

The plantInflow class from the wastewater ontology was incorporated under EnvironementalEngPrimarySedTank because environmental engineers need to know what the plant inflow is and this is a parameter for the primary sedimentation tank in Dynamo. All other classes of the primary sedimentation tank stayed the same as before since it was structured with the same intended use and intended users as this ontology. 

screenshot-2025-02-11-at-3-39-54%e2%80%afam

Another edit made to the primary sedimentation tank was to include the high performance criteria of detention time and surface overflow rate from Dynamo, which was included under EnvironmentalEngPrimarySedTank as this pertains to the knowledge of the environmental engineer.

The overall primary sedimentation tank section is seen below.

screenshot-2025-02-11-at-3-39-59%e2%80%afam 

1.2.2 Wastewater Treatment ->Sludge Digester: A sub-ontology, following the logic of the primary sedimentation tank ontology, was created for the sludge digester tank.

 screenshot-2025-02-11-at-3-40-09%e2%80%afam

1.3 Highway: Like the SBahn station, the original highway ontology was restructured by making three classes related to the three experts that would work on the highway/road. All existing subclasses were restructured under CivilEngHighway or TransportationEngHighway. A subclass under AccessibilityHighwayRoad was included to reflect that we designed the road with a high performance criteria in Dynamo to have a long cross time so that people with mobility issues could cross the entire street. We thought about the street crossing at the main university campus in Charlottenburg and how even a person who walks fast struggles to cross that road with the time given and wanted to change this to make it more accessible.

screenshot-2025-02-11-at-3-40-15%e2%80%afam

1.4 Bridge: The bridge ontology was reconstructed in order to fit the purpose/intended users/intended uses/scope of this project and to fit the ontology rules set by Noy McGuiness. The first restructuring made, like other sections of the ontology, was to add subclasses of the engineering teams working on the project (civil and transportation). 

screenshot-2025-02-11-at-3-40-19%e2%80%afam

Under CivilEngBridge, the ontology was reconstructed to have similar levels of detail and since each subclass must be related to the classes before (Noy and McGuinness). 

screenshot-2025-02-11-at-3-40-25%e2%80%afam

For the transportation engineering subclass under the Bridge class, the BridgeUse subclasses which existed in the original ontology but did not apply to our integration context were deleted (EcoPassageUse, PedestrianUse). The BridgeUse of SBahnUse was added since our integration context is an SBahn station in a transportation hub. The heavy rail use and light rail use was kept since our station is inspired by the Tiergarten station and regional trains, ICE trains, and other trains pass on these tracks.

screenshot-2025-02-11-at-3-40-29%e2%80%afam

Object Properties: Two object properties were added: hasAccessibilityFeature and isAccesibilityFeatureOf. The domain and ranges are shown in the image below. This was done so that our accessibility features of the SBahn station could be easily logically connected to the station. These features included: (1) having an accessible platform height difference, (2) having a display downstairs of arrival and departure times so that people do not have to rush unnecessarily, (3) speakers announcing departure times which are soon for the visually impaired, (4) two elevators in case one is being maintained. 

img_a13936938883-1


Logic Axioms/SROIQ Constructors

The logical axioms used in the ontology were: classes/subclasses, object properties, inverses, domain/range, instances, restrictions, data properties, disjoint classes. An example of each logic axiom is shown in Table 1 (Krötzsch et al., 2013).

screenshot-2025-02-11-at-3-41-00%e2%80%afam

Ontology Procedures According to Noy and McGuinness

3.1 Transitivity: Each subclass must be related to the classes before (Noy and McGuinness). If this was not done in the previous ontologies, this was fixed.

3.2 Number of Classes: Noy and McGuinness’ suggestion that the number of direct subclasses should be between 2 and 12 was followed.

3.3 Generality: Same level of generality was given to siblings of each class

3.4 Multiple Inheritance: Multiple inheritance—a subclass that is a subclass of two classes—was used with PrimarySedimentationTank and SludgeDigestor since environmental engineers in both projects needed to know the population served. Thus, plantInflow was a subclass in both EnvironmentalEngPrimarySedimentationTank and EnvironmentalEngSludgeDigestor.

3.5 Naming: Spacing was not used to allow the possibility of interacting with other systems. The suggestion to not use abbreviations was not followed only for the primary sedimentation tank since it has a long name. “PrimarySedTank” was used instead of “PrimarySedimentationTank” to avoid hard-to-read classes.

3.6 Disjointing: All subsystems were disjointed from each other except the primary sedimentation tank and the sludge digester, since they share required knowledge of inflow.


  1. Engineering Uses

1. Improvement of Existing Transportation Hub:

Scenario: An existing transportation hub which has a road near it and also has a regional/ICE train bridge wants to improve on its accessibility measures. 

Ontology Use: Project managers and engineers in the project can access this ontology to easily identify the accessibility measures which can be applied in the SBahn and in the road. Some adjustments may take time (adding another elevator, platform height difference), while others may be low-cost and easy to install in an existing system (downstairs display screen, speakers announcing departures). By looking at this ontology, the engineers can improve not just obvious improvements (elevators) but also improvements which will be easy to implement but can often be overlooked. It will also help to look at the system was a whole, including the road, to add accessibility measures at the road like a longer crossing time.

2. Expansion of Existing SBahn Station:

Scenario: An existing SBahn station needs to be expanded due to increasing population and increasing transportation needs. A neighborhood which did not need a transportation hub now needs a place where regional trains, SBahns, ICE, and bus/car travel can be easily connected.

Ontology Use: To make this expansion easier and faster, the engineers can use this ontology to create a basis of what design parameters need to be chosen and what designs need to be made. By having the accessibility information readily available, the new expanded SBahn station can be inclusive. This ontology can be combined with the Dynamo model to note what value within the parameter range the design parameters are currently set at to not avoid confusion among engineering teams.

3. Updating wastewater treatment within the Transportation Hub

Scenario: The SBahn station has already been built but there is a change in wastewater input quality due to an environmental disaster nearby. Environmental and civil engineers need to be able to quickly work together to find what treatment processes to add. 

Ontology Use: Environmental and civil engineers can use FutureIntegrationContextImprovements under the WastewaterTreatment class to easily find what technology can be used to improve the wastewater quality. This goes hand in hand with the flexible design of Dyamo.

 

Bibliography
Noy, N., & McGuinness, D. Ontology Development 101: A Guide to Creating Your First
Ontology.

Hartmann, 2024. Lecture

Noy, N., & McGuinness, D. Ontology Development 101: A Guide to Creating Your First
Ontology.