1. Ontology diagram
This diagram is generated directly from the .owl file and therefore reflects the actual state of the ontology (this version is accurate as of 4 February 2025). It shows classes with their subclasses radiating out from them, as well as the object properties relating classes. It does not show datatype properties (that is, properties where the value is a datatype, instead of an instance of a class in the ontology).
This diagram was generated with WebVOWL. To generate your own:
Upload the ontology file: Ontology > Custom Ontology > Select ontology file in the tabs at the bottom of the page.
Organise the diagram neatly by selecting Modes > Pick and pin and dragging the class nodes to the desired area.
Export the diagram: Export > Export as SVG.
You can adjust the level of detail shown in the diagram with Filter > Degree of collapsing. If you wish to exclude Object- or Datatype Properties, check the box next to Filter > Object properties/Datatype properties respectively.
2. Classes
Considerations pertaining to classes before release #1:
Class inconsistencies
Annotation practices
1. Inconsistencies
The following is a list of class for which there are inconsistencies between the .owl ontology file, the core ontology class list and the table of definitions (the latter two as per this page). The list below has the class name and a brief description of the problem; accurate as of 04-02-2025.
| Class | Reason | Status | Solution |
|---|
| 1 | Agent:LegalPerson
| In .owl, but not in ontology list | 
| |
| 2 | Agent:NaturalPerson
| In .owl, but not in ontology list | | |
| 3 | Agent:CyberPersona
| In .owl, but not in ontology list | | |
| 4 | Claim:Report
| In table, but not in ontology list | | |
| 5 | Control:DataFormat
| In .owl but greyed out in table; is this definitely not for version 1? | | |
| 6 | Indicator:Location
| In list, but no definition in table | | |
| 7 | Indicator:Position
| In list, but no definition in table | | |
| 8 | Indicator:Reputation
| In .owl but greyed out in table; is this definitely not for version 1? | | |
| 9 | SpatialMeasurementSystem:GeocentricDatum
| In .owl, but not in ontology list. Possible addition? Or are we not being that specific? | | |
| 10 | SpatialMeasurementSystem:GeodeticDatum
| In .owl, but not in ontology list. Possible addition? Or are we not being that specific? | | |
| 11 | SpatialParameter:Extent and subclasses
| In .owl, but greyed out in table | | |
| 12 | SpatialParameter:Location
| In .owl, but greyed out in table | | |
| 13 | SpatialParameter:Position
| In table, but not in list | | |
| 14 | TemporalParameter:Duration
| In .owl, but greyed out in table | | |
| 15 | TemporalParameter:Instant
| In .owl and table, but not in list | | |
| 16 | TemporalParameter:Period and subclasses
| In .owl and table, but not in list | | |
| 17 | TemporalParameter:TimePosition
| In .owl, but greyed out in table | | |
| 18 | Role:ProjectDeveloper
| In .owl, but greyed out in table | | |
| 19 | Activity:Reporting
| In list and .owl, but no definition in table | | |
| 20 | Instrument:MeasurementInstrument
| In .owl, but not in list. Possible addition? Or are we not being that specific? | | |
| 21 | Medium
| In list and .owl, but no definition in table | | |
| 22 | Medium:ClaimMedium
| In .owl, but greyed out in table; is this definitely not for version 1? | | |
| 23 | Medium:AttestationMedium
| Greyed out in table; is this definitely not for version 1? | | |
| 24 | Process
| Subclass of Event in table, but not in list | | |
| 25 | Process:NaturalProcess
| In .owl, but not in list and greyed out in table. Definitely excluded? |
| |
| 26 | Project
| Subclass of Activity in table, subclass of Process in list | | |
| 27 | Substantiation
| Greyed out in table | | |
Where definitions and annotations for these classes are present in the .owl file, they may be assumed outdated and possibly incorrect.
2. Annotations
Currently, each class has a definition (skos:definition) and a “name“ (a human-readable label; rdfs:label).
The table of definitions on this wiki page contains synonyms, notes, and considerations for use in addition to the definition. How many, if any, of these notes should be added to the ontology as comments or explanations (with rdfs:comment)?
3. Predicates
The predicates relate classes to one another and are, to a large extent, what makes the ontology usable; they warrant careful consideration and review before release of the ontology.
1. Object properties
As of 05-02-2025, the ontology contains 24 object properties. The majority of the 13 fundamental axioms of the ontology are explicitly encoded as predicates. Some, like #4 and #13 do not (or not yet) have equivalent properties.
This list of predicates is not sufficient to make the ontology fully operational. Working through some concrete examples may be a good starting point for identifying which additional predicates are needed.
Axiom | Property (Inverse property) | Status | Solution |
|---|
An agent engages in an activity
| engagesIn (isPerformedBy)
| 
| |
An activity impacts an environment
| activityImpacts (impactedByActivity)
| | |
An environment is defined by interrelated parameters
| isDefinedBy (belongsToEnvironment)
| | |
A state is the value of a parameter P at time t
| No explicit property; definition inferred by structure of actual data. For an example, see the state1 definition here. | | |
An activity is performed by an instrument
| hasInstrument (usedToPerform)
| | |
An activity has at least one thing as input
| hasInput
| | |
An activity has at least one thing as output
| hasOutput
| | |
A claim is a statement about a (some specific) thing
| isStatementAbout
| | |
A claim is expressed in a claim medium
| expressedInMedium
| | |
An agent enacts a role
| enacts
| | |
An event impacts a state
| eventImpacts (impactedByEvent)
| | |
A control limits or directs a thing
| hasSubject (hasControl)
| | |
A claim can be substantiated by another thing
| No property yet | | |
In addition to these properties, the ontology contains a number of additional properties:
Property (Inverse Property) | Rationale for inclusion | Considerations | Status | Solution |
|---|
comprises
| For many classes, instances of that class can contain “subinstances“ of the same class. For example, an organisation (which is an Agent), can have many employees (themselves Agents) | Is this necessary to define explicitly? | | |
makesClaim (hasClaimant)
| Agents make Claims
| | | |
hasLocation
| Useful property to have | Better practice to link aia-o with existing ontology and use their properties instead of defining our own. Possible alternatives: schema.org's Place W3C Basic Geo Vocab for simple lat/long/alt locations GeoSPARQL (more complex/technical)
| | |
hasStateDiff
| To quantify state differences | What is the domain and range? How exactly is a state difference defined (see axiom 4 in the previous table) | | |
hasAttribute (isAttributeOf)
| To identify attributes of an entity | | | |
hasProvenance
| Answer to the question “What caused this?“. Not yet included in ontology, but may be useful to include. | | | |
hasSubstantiation (isSubstantiationFor)
| Not yet included in ontology, but may be useful to include, once the Substantiation class is formalised | | | |
2. Datatype properties
Constructing these is not related explicitly to fundamental axioms. It is therefore harder to decide which properties are needed.
None of the current datatype properties should be viewed as final, fundamental, or indispensable. In fact, one approach may be to provide only a small handful of datatype properties in the ontology, and leave the rest to be defined by users in their own schemas as needed.
As a starting point for the discussion, the current datatype properties (05-02-2025) are listed below.
| Property | Domain | Range |
|---|
| 1 | hasAccuracy
| MeasurementInstrument
| xsd:float
|
| 2 | hasConfidenceLevel
| State
| xsd:float
|
| 3 | hasConfUpperBound
| State
| xsd:float
|
| 4 | hasConfLowerBound
| State
| xsd:float
|
| 5 | hasLogicalOperator
| Control
| xsd:string
|
| 6 | hasMake
| Instrument
| xsd:string
|
| 7 | hasModel
| Instrument
| xsd:string
|
| 8 | hasModality
| | xsd:boolean
|
| 9 | hasPrecision
| MeasurementInstrument
| xsd:float
|
| 10 | hasRationale
| | xsd:string
|
| 11 | hasUnitOfMeasure
| Parameter, Indicator
| xsd:string
|
| 12 | isBinding
| Control
| xsd:boolean
|
| 13 | wasCalibratedOn
| MeasurementInstrument
| xsd:dateTime
|
| 14 | wasManufacturedOn
| Instrument
| xsd:date
|
4. Enforcing data correctness
It is important to realise that OWL only ensures logical consistency, i.e. that the axioms of an ontology do not lead to contradictions. OWL does not automatically enforce the constraints (domain constraints, range constraints, etc.) in the ontology on instance data.
Ensuring that data actually adheres to the constraints and restrictions implied by the ontology requires the use of additional tools, like SHACL.
Why? Using SHACL helps ensure data of high quality. It forces data to adhere to the constraints and requirements of the ontology.
What? SHACL (Shapes Constraint Language) is “a language for validating RDF graphs against a set of conditions“.
When? Data can be checked against the defined shapes before being entered into a knowledge graph or triple store.
How? SHACL validators check the data against the defined shapes and generate a report if any violations are found.
Below is a small example for clarification.
Where can we use SHACL?
A good use case for SHACL in our ontology is the Role class.
Role is defined as “A control that specifies the scope of and/or requirements for an agent's relation to an activity.“ That is, given that an agent engages in a certain activity, there may be a collection of requirements the agent must adhere to.
Roles can be adjusted according to the needs of the application at hand. For example, the set of requirements for agents who own things (the set is collectively referred to as an Owner role) may differ between applications.
As an example, consider the following:
Define the Role: Verifier (Turtle code)
@prefix aia: <http://purl.org/aiaontology> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
<verifier-id> rdf:type aia:Verifier ;
aia:hasRequirements "The agent must have a qualification.",
"The agent must have more than 2 years of experience" .
|
2. Define the shape (SHACL)
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix aia: <http://purl.org/aiaontology#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
# The verifier role only applies to agents who verify something
aia:VerifyingAgentShape
a sh:NodeShape ;
sh:targetSubjectsOf aia:verifies ;
# Requirement 1
sh:property [
sh:path aia:hasQualification ;
sh:datatype xsd:boolean ;
sh:hasValue true ;
sh:message "The agent must have a qualification." ;
] ;
# Requirement 2
sh:property [
sh:path aia:yearsOfExperience ;
sh:datatype xsd:integer ;
sh:minInclusive 3 ;
sh:message "The agent must have more than 2 years of experience." ;
] .
# courtesy of ChatGPT |
Input data. To experiment with SHACL yourself, you can use a SHACL playground like this one (note that you will need to structure your data as JSON-LD for this playground).
# Data will be checked and pass
:aiaAgent1 a aia:Agent ;
aia:verifies <something>
aia:hasQualification true ;
aia:yearsOfExperience 4 . |
# Data will be checked and fail
:aiaAgent2 a aia:Agent ;
aia:verifies <something> ;
aia:hasQualification false ;
aia:yearsOfExperience 2 . |
# Data will not be checked
:aiaAgent3 a aia:Agent ;
aia:hasQualification false ;
aia:yearsOfExperience 3 . |