Ontology engineering geplaatst op 5/17/2024

Seeing objects

Be attentive to what you say and stop and think every time you see something new

In this short video, the airport business operations are shown. Our goal is to study what opportunities for improvement there are. For that, we must perform a business analysis.

We start by discovering objects, defining their properties and classes, and cataloguing them to develop the foundational structure of our domain model. Discovering objects is a fundamental operation when we build project ontologies.

We first see, "The first flight is arriving." That means we can model this object, "arrival." We create a resource airport-ontology and add a new class " arrival."

A short note here - always use the singular form of a noun when naming a class.

From the very first moment, we begin to leverage our knowledge base. We run a query in chatGPT: "What properties should I consider if I create a data model for a new class "arrival"? And we get this response.

When creating a data model for a new class "Arrival" in the context of flight operations, several key properties should be considered to capture all relevant aspects of the arrival process. Here are the primary properties to include:

  1. Arrival ID: A unique identifier for each arrival record.
  2. Flight Number: The flight number associated with the arriving aircraft.
  3. Aircraft ID: The unique identifier of the aircraft (tail number or registration).
  4. Airline: The airline operating the flight.
  5. Origin Airport: The airport from which the flight departed.
  6. Destination Airport: The airport where the flight is arriving.
  7. Scheduled Arrival Time: The planned time for the flight to arrive at the destination airport.
  8. Actual Arrival Time: The real-time when the flight landed at the destination airport.
  9. Gate Arrival Time: The time when the aircraft reaches the gate.
  10. Runway Arrival Time: The time when the aircraft lands on the runway.
  11. Status: The current status of the arrival (e.g., on-time, delayed, landed, at gate).
  12. Arrival Gate: The gate at which the aircraft will unload passengers.
  13. Terminal: The terminal where the arrival gate is located.
  14. Baggage Claim: The baggage claim area assigned for this arrival.
  15. Passengers Count: The number of passengers onboard.
  16. Cargo Details: Information about any cargo being transported, if applicable.
  17. Flight Crew: Details of the flight crew (optional, for internal purposes).
  18. Weather Conditions: Weather conditions at the time of arrival.
  19. Runway Used: The specific runway used for landing.
  20. Taxi Time: The duration it takes for the aircraft to move from the runway to the gate.
  21. Ground Services Required: Details of any ground services needed upon arrival (fueling, cleaning, etc.).
  22. Comments: Any additional comments or notes regarding the arrival.

These meticulously chosen properties provide a comprehensive view of the arrival process. They are not just a list but a practical toolkit for managing, monitoring, and analysing flight arrivals effectively.

When creating properties, remember that some of them can be classes of themselves

When you get a list of properties, please take the time to put them into your model and think everything through. Atomic Server, like any other database, allows the creation of two types of properties - intrinsic properties or links to different classes. For example, you have an age, a height, a weight, and that's your inherent properties. Also, you are a son/daughter, an employee of some company, or a university graduate, and that's your property as links to other classes and objects in this world. You need both to describe yourself, but for properties-as-links, you create a property and another class (the master list of all persons, companies, or universities).

In this case, let's sort proposed properties into two groups - one that will require separate classes (physical objects) and another that will represent intrinsic properties of arrivals:

  1. Arrival ID: Intrinsic. There is no real object that corresponds to this property.
  2. Flight Number: Intrinsic.
  3. Aircraft ID: This is an interesting case. An aircraft is a separate class, a physical thing. But what is an ID? ID is a pointer to a specific instance of an aeroplane, meaning this must be an ID (index) of the "aircraft" class.
  4. Airline: Airline is a class.
  5. Origin Airport: An airport is a class.
  6. Destination Airport: An airport is a class reused from the previous, making our model more compact.
  7. Scheduled Arrival Time: Time is an intrinsic property.
  8. Actual Arrival Time: Time is an instrinsic property.
  9. Gate Arrival Time: Time is an instrinsic property.
  10. Runway Arrival Time: Time is an instrinsic property.
  11. Status: Status is usually an intrinsic property, but there are some considerations to it. Typically, you can create a predefined list of statuses in Atomic Server and allow users to choose one. But suppose you want to list all statuses and share them between different classes (for example, crew and passengers can have the status "on board," though they belong to different classes). In that case, you may consider creating a separate class "status." Here, we model it as an intrinsic property.
  12. Arrival Gate: Gates are physical objects; you need a separate class for them.
  13. Terminal: Terminals are also physical; it's a separate class with a link to it.
  14. Baggage Claim: A baggage claim area is an object; it's a separate class with a link to it.
  15. Passengers Count: That's a calculated property, though in some sense, it is physical because it can be linked to a company's passenger list; see deeper methodological considerations in
  1. Cargo Details: As before, this can be text notes to an arrival record or imported information from a cargo management system linked to the "cargo" class; an analyst must ask follow-up questions.
  2. Flight Crew: This is definitely a separate class, and most likely even several—one for all authorised airline personnel, another for airport personnel, and the third for shifts and crew scheduling. Again, this is a good subject for further inquiry before modelling that.
  3. Weather Conditions: Weather conditions are physical, and they change frequently as a new weather report arrives at a control tower or an aircraft; you need to create a separate class for them.
  4. Runway Used: The runway is physical and most likely comes from an external country, regional, or international air traffic control system. So yes, it requires a separate class, but you will need to check our data interchange standards.
  5. Taxi Time: This case is not very obvious. It is a time that calls for making it an intrinsic property and calculating it in the business logic layer. But, the number of gates and runways is limited, and there are a lot of arrivals. Hence, statistics are available, and very reliable data for that property can be gathered and stored in tables. In this case, we are representing all 4D instances of taxiing as objects (see West, 2011 or data re-engineering examples in Partridge's book for details) and model them as a class.
  6. Ground Services Required: Similar to the previous item, that is most likely a separate class with multiple selections.
  7. Comments: That's an intrinsic property.

Now you have more work; you need to create new classes - "aircraft" (and link it with an "Aircraft ID" property), "airline," "airport," "gate," "terminal," "baggage claim area," "personnel," "flight crew," "weather conditions," "runway," and "ground services." And we should repeat that process for each of them. That should be a norm - a concise conversation or observation must be a source of at least a few data models and particular questions. You must not always be satisfied with the data models that ChatGPT offers on the first try; try to specify your prompts and get better models. See, for example, not suitable reply I scratched for the "aircraft" data model.

Review proposed data models and remove all properties irrelevant to the concerns of actual project stakeholders; your data model should be helpful but not overloaded with details. Also, remember that you can specify to produce an output in the required format; you can import directly to Atomic (JSON, for example) so that you don't need to create your data model line by line. If you are doing external integrations, you can copy or map the existing JSON data schemas.

It makes sense to check the measurement methodology for all intrinsic properties immediately. In this case, for example, you need to check how scheduled and arrival times are collected, calculated, and processed. Time can be stored in multiple formats, which drives the format in which you store these fields in your ontology.

Only once you have considered a data model for one class can you move to the other

As you can see, it took us about half an hour to create a small data model from just a small piece of evidence we saw in business operations. With proper knowledge inquiries, we can choose a lot of directions of our further investigation. This is exactly the value of formal modelling techniques - they require us to think very clearly and ask very specific questions, removing barriers to deliver a software solution that will solve a very specific problem for a very specific stakeholder. Such formal models are very beneficial for project communications and assist to a much better understanding between a customer, project manager, product manager, and an engineering team.

Technical note. A proficient analyst must pay enough attention to cross-relations and dependencies between classes. For example, the "terminal" class has "amenities" property. Do you need to model it? Remember, that each property requires not only development, but also takes time from employees to administer the data in it, and it should be useful. If you divert an arrival to a wrong terminal, where contracted amenities are absent (for example, there is no business lounge), it would be a poor decision and can cause claims, that means, you need to carefully think what properties can be excluded and why. An analyst should always check his assumptions before delivering the data model to a developer with requirements. Also, as an analyst discovers domain terms, some interesting sources of domain models, taxonomies, and ontologies can be discovered. For example, once we discover term "taxiway," when we google its definition, the first result we find is "The ATM Information Reference Model (AIRM) The reference vocabulary for defining air traffic management information", which is an excelent source of further line of inquiry for domain modelling. We can go in many directions from it - see.

undefinedCaptura de pantalla 2024-06-29 a las 14.41.12.png