Ontology Rules for tax-free inheritance

Writing Rules and Actions in 1Integrate is logical and easy to use, however, it can be taxing to spend your time rewriting the same Rule multiple times for different classes. There are many methods to address this, for example templates are efficient for reusing logic, but if your data structure uses ontology, inheritance can be a game changer.

What is an ontology?

Ontologies are representations of how objects and concepts that have related properties are linked, formed from a series of subclasses and superclasses. A superclass is a broad definition that encompasses several class types, while subclasses are more specific definitions of those superclass types.

If the initial class was “Any Feature”, each subclass would be more specific, such as: “Topography”, “Linear”, and “Network Asset”. Each of these feature types share common properties such as geometry, and an ID, but are also distinct enough that they have their own definitions that separate them.

Objects are more easily categorised due to their physical traits but concepts can also be used in ontologies. An Electoral District as a concept could be the subclass of an Area, while it could also be the superclass of smaller local Elector districts.

Taking an ontological approach to working with data has the benefit of not needing to write the same class structures multiple times. Inheritance structures are defined in OWL files which list classes with their relations, and attributes with the class that uses them and the data type it uses. By defining the structure of your classes, you can create a hierarchy of super classes and subclasses that share attributes “down the line”. We’ll look at some examples of these files later, but let’s first explore how useful they can be and why you may want to use them.

Using Ontologies

Ontologies have lots of uses, perhaps you have a series of topography features that all require Rules to check them. Buildings and Roads both have enough in common for them to be subclasses of the Topography class. They can still have attributes of their own but have the benefit of inheriting the attributes of the existing superclass.

1Integrate natively supports using Ontologies to configure your Data Stores; it only requires an OWL file with the relevant hierarchy. 1Spatial’s Public Safety package makes good use of ontology, as we’ll see in the following cases.

National Emergency Numbers Association (NENA)

NENA is the 9-1-1 association of the United States of America; they are a non-profit organisation that focusses on 911 operations and policies. They ensure the smooth running and efficiency of Law Enforcement, Fire, and Emergency Medical Services.

In the Public Safety package, ontology is used on the root “NENA layer” to save on building multiple Rules for each class. This layer contains three attributes that all feature layers in the package use; NENA Globally Unique ID, Discrepancy Agency ID, and Date Updated.

There are 18 layers, all of which inherit those the attributes from the NENA Layer. By using inheritance, it allows 1Spatial to write a single Rule against the NENA Globally Unique ID.

The value of this attribute is always unique across all layers and allows the unique ID to be compared in a simple Check That predicate. It checks against itself once, instead of checking over each feature type individually.

This allows one flexible Rule to take the place of the 18 Rules that would otherwise need to be built and run for each of the 18 layers.

Emergency Service Boundary (ESB)

ESBs are used to map where each service can travel. Being able to understand and validate what the allowances and restrictions are for each service is integral to ensuring that proper call routing and emergency dispatches occur.

Within the same package, boundary containment also makes use of inherited classes. Roads must meet one of two requirements; they must be fully contained by an ESB or only touch the ESB that it intersects.

The three standard ESB features are Police, Medical, and Fire; but the scope is not limited to them alone. Additional layers can be added depending on what is relevant to that area, such as the Forest Service or Poison Control. Without inheritance, a minimum of three separate Rules are needed, with additional Rules required for any non-standard ESB layers that might be necessary.

By using inherited classes and attributes a single Rule that covers both standard and non-standard ESB layers can be built. This gives coverage of all existing and future ESB layers to a single Rule, while also being the only Rule that ever needs to be updated when changes are required.

Examples from an OWL file

The following excerpts are from an OWL file. This follows a familiar structure to that of HTML/XML files.

In the section above, the first class outlined is the NENA_Layers superclass. The following class, “NENA_Boundaries” is a subclass and will inherit attributes from NENA_Layers. The next two classes, are further levels of subclasses, making “Counties” the fourth level of class, inheriting from each level of superclass above it.

The section below covers the attributes, which are individually listed and assigned to the classes. Attributes will then be inherited by an subclasses of the superclass this is assigned to.

Adding your own Ontology in 1Integrate

Why use Ontology?

Once you’ve created an OWL file, 1Integrate does the rest of the heavy lifting, letting you concentrate on building Rules and Actions.  It helps streamline your work by making it more efficient to build and run your Rules; keeping them flexible an d easy to update in the future.

Once you’ve built one Rule or Action that can be used to cover multiple cases, you’ll see just how much easier it is to use in the right situations.

You can find further details on Ontology and Inheritance in our online documentation.