-
A Survey of Industry Data Models and Reference Data Libraries
14 Telecommunication ontologies for digital twins
-
14.1 Relationships between the ontologies
The ontologies considered in this section are summarised in Figure 14.1.
Figure 14.1 - Summary of digital twin ontologies
The bottom levels shown in Figure 14.1, DTDL, NGSI-LD and oneM2Mbase with SAREF core, each provides REST-based access to physical devices using JSON-LD. The introduction to DTDL on the Azure web site (https://github.com/Azure/opendigitaltwins-dtdl) says:
The Digital Twins Definition Language (DTDL) is made up of a set of metamodel classes that are used to define the behavior of all digital twins (including devices).
This is equally true of the others. Each of the three approaches has a slightly different scope. In Figure 14.1, the key objects in the different ontologies are shown in red.
In each case, the ontology at the base influences the forms of the application ontologies that rely upon it. Each ontology is principally static, with time introduced only to support time varying properties, such as room temperature. There appears to be no link between this community and the work on Top Level Ontologies carried out elsewhere.
NOTE - The acronyms used in Figure 14.1 are as follows:
DTDL Digital Twin Definition Language
ETSI European Telecommunications Standards Institute
M2M Machine 2 Machine
NGSI-LD Next Generation Sensor Initiative – Linked Data
SAREF Smart Applications REFerence -
14.2 oneM2M base ontology
https://git.onem2m.org/MAS/BaseOntology
14.2.1 Defining organization
oneM2M is an association of telecommunications companies, and has 227 members world-wide. oneM2M works with the following regional standardization organizations:
- ARIB (Association of Radio Industries and Businesses), Japan;
- ATIS (Alliance for Telecommunications Industry Solutions), USA;
- CCSA (China Communications Standards Association), China;
- ETSI (European Telecommunications Standards Institute), EU;
- TIA (Telecommunication Industries Association), USA;
- TSDSI (Telecommunications Standards Development Society), India;
- TTA (Telecommunications Technology Association), Korea;
- TTC (Telecommunications Technology Committee), Japan.
oneM2M does not publish standards, but defines standards which are then published by regional standards organizations. The oneM2M base ontology is published by ETSI as ETSI TS 118 112 - V2.0.0 (2016-09).
14.2.2 Objectives and scope
The oneM2M “about us” web page says:
“The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide.”
oneM2M defines an ontology. The introduction to the ontology says:
“Ontologies and their OWL representations are used in oneM2M to provide syntactic and semantic interoperability of the oneM2M System with external systems. These external systems are expected to be described by ontologies.”
14.2.3 Structure of the model
The oneM2M base ontology is described in oneM2M technical specification TS-0012 (version 2.2.2 is dated 2018-03-12). Both this document and the representation of the ontology in OWL can be downloaded from https://git.onem2m.org/MAS/BaseOntology .
The ontology is about things in the world. A thing that also part of a telecommunications network is a device. A device has:
- functions: what it does in the world;
- services: which expose functions to a telecommunications network.
Services can have input and output data points which can be accessed over the network. They can have RESTful URIs and by accessed by HTTP GET or PUT operations.
Functions can have commands which tell the device what to do. Services have operations which expose commands to a telecommunications network. Operations can have RESTful URIs be invoked by an HTTP PUT. The PUT can be empty, or can have a payload which says what to do.
The oneM2M base ontology can be specialised by application ontologies which:
- describe the world in which the device exists;
- describe the operation or data point which can be accessed over the telecommunications network.
The application ontologies can be layered. A layer directly about the oneM2M base ontology is the Smart Applications REFerence ontology (SAREF), which is standardised by ETSI (see section 10.3). Above this is the SAREF extension for Smart City ontology (SAREF4CITY), also standardised by ETSI (see section 10.4).
Examples are shown in Figure 14.2, Figure 14.3 and Figure 14.4.
Figure 14.2 - Monitoring the state of a washing machine
Figure 14.3 - Switch on a washing machine
Figure 14.4 - Set the intensity of a light
The intention of the oneM2M base ontology is to define the relationship between the telecommunications world of operations, services and input and output data points, and the physical world. A device provides the link between the telecommunications world and the physical world.
Figure 14.5 is taken from TS-0012 and shows the key classes and relationships in the ontology.
Figure 14.5 - The oneM2M base ontology
Figure 14.5 is the only ontology overview diagram within the definition document. This diagram does not describe a rigorous structure. There are also things which exist in the real world, such as state, which are not distinguished from the data exposed to the telecommunications network.
NOTE 1 Work may still be being carried out on the oneM2M ontology in the area of “state”, because the object operation state shown in Figure 14.5 does not exist in the published OWL representation.
NOTE 2 Possibly variable is the exposure of a aspect to the telecommunications network. It would be good if this were shown explicitly.
NOTE 3 The relationship between the oneM2M ontology and the SAREF ontology is discussed on https://git.onem2m.org/MAS/BaseOntology/blob/master/Example_usage_of_the_Base_Ontology_-_combinig_SAREF_and_BO/README_Base_Ontology_SAREF.md . The documentation notes that there have been issues between the two ontologies in the handling of property and state.
The oneM2M ontology has been developed from a telecommunications point of view. It would be good if the high level objects which can be specialised to describe the real world were taken from a formal Top-Level Ontology. This may have reduced the difficulty in defining the interface with SAREF.
14.2.4 Documentation
The oneM2M “base ontology” is documented as a standard in a style similar to that of ISO. The ontology is well described in the document and there is good annotation in the OWL file. These is also a worked example showing implementation of the base ontology using SAREF.
14.2.5 Maintenance and usage
The oneM2M base ontology version 2.2.2 was published in March 2018. It is widely used, and is the basis for other standards.
-
14.3 Smart Applications REFerence (SAREF)
NOTE This portal links to ETSI Technical Specification “SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping”, TS 103 264 V3.1.1 (2020-02):
https://www.etsi.org/deliver/etsi_ts/103200_103299/103264/03.01.01_60/ts_103264v030101p.pdf
The link to the ontology source in the report, “https://saref.etsi.org/saref”, is incorrect. The correct link is https://saref.etsi.org/sources/saref-core/ .
14.3.1 Defining organization
ETSI (European Telecommunications Standards Institute)
ETSI is one of the three organizations (CEN, CENELEC and ETSI) which develop European standards.
14.3.2 Objectives and scope
The SAREF website says:
The Smart Applications REFerence (SAREF) ontology is a shared model of consensus that facilitates the matching of existing assets in the smart applications domain.
SAREF provides building blocks that allow separation and recombination of different parts of the ontology depending on specific needs.
The introduction to the SAREF “core” says:
The Smart Applications REFerence ontology (SAREF) is intended to enable interoperability between solutions from different providers and among various activity sectors in the Internet of Things (IoT), thus contributing to the development of the global digital market.
SAREF shall use the SAREF Communication framework as defined in ETSI TS 103 267, "SmartM2M; Smart Appliances; Communication Framework”.
There are SAREF extensions for different industrial domains, which are documented in ETSI Technical Specifications, as follows:
- ETSI TS 103 410-1: "SmartM2M; Smart Appliances Extension to SAREF; Part 1: Energy Domain";
- ETSI TS 103 410-2: "SmartM2M; Smart Appliances Extension to SAREF; Part 2: Environment Domain";
- ETSI TS 103 410-3: "SmartM2M; Smart Appliances Extension to SAREF; Part 3: Building Domain";
- ETSI TS 103 410-4: "SmartM2M; Smart Appliances Extension to SAREF; Part 4: Smart Cities Domain" (see section 14.4);
- ETSI TS 103 410-5: "SmartM2M; Smart Appliances Extension to SAREF; Part 5: Industry and Manufacturing Domains";
- ETSI TS 103 410-6: "SmartM2M; Smart Appliances Extension to SAREF; Part 6: Smart Agriculture and Food Chain Domain".
SAREF and its extensions are shown in Figure 14.6, taken from the ETSI Technical Specification.
Figure 14.6 - SAREF and its extensions
14.3.3 Structure of the model
The summary of the SAREF model on the SAREF website is shown as Figure 14.7.
Figure 14.7 - Summary of the SAREF model
Comments on Figure 14.7:
1. The classes Device, Function, Command and Service also exist in the oneM2M base ontology. However they are not referenced but redefined. The ETSI technical specification says that they are “equivalent classes”.
NOTE 1 The relationship between the oneM2M ontology and the SAREF ontology is also discussed on https://git.onem2m.org/MAS/BaseOntology/blob/master/Example_usage_of_the_Base_Ontology_-_combinig_SAREF_and_BO/README_Base_Ontology_SAREF.md . This page notes that SAREF has no equivalent to Operation.
2. The class Commodity has the following subclasses:
- Coal;
- Electricity;
- Gas;
- Water.
The class Property has the following subclasses:
- Energy;
- Humidity;
- Light;
- Motion;
- Occupancy;
- Power;
- Pressure;
- Price;
- Smoke;
- Temperature.
NOTE 2 It is not clear that the subclasses of Commodity and Property are used correctly in some implementation of SAREF. In some cases, a member of the class measurement, which obtains a value, has a relatesToProperty relationship with a subclass of Property rather than a member of Property.
3. The class Device has the following subclasses:
- Actuator;
- Appliance;
- HVAC;
- Meter;
- Sensor.
4. The class Command has the following subclasses:
- CloseCommand;
- GetCommand;
- NotifyCommand;
- OffCommand;
- OnCommand;
- OpenCommand;
- PauseCommand;
- SetLevelCommand;
- StartCommand;
- StepDownCommand;
- StepUpCommand;
- StopCommand;
- ToggleCommand.
A Command acts upon a State. The class State has the following subclasses:
- MultiLevelState;
- OnOffState;
- OpenCloseState;
- StartStopState.
The SAREF ontology supports time histories through the Profile class, as shown in Figure 14.8.
Figure 14.8 - SAREF Profile
NOTE 2 It is not clear how this works for general time histories. The ETSI Technical Report “SmartM2M; Smart Appliances; SAREF extension investigation” says:
The energy and power profiles in SAREF at the moment are specific for the SAREF4ENER extension, therefore the Profile class in SAREF needs to be redefined to accommodate properties that are general enough for any type of profile, not only for Energy and Power.
14.3.4 Documentation
The SAREF “core ontology” is documented as a standard in a style similar to that of ISO. The ontology is well described in the document and there is good annotation in the OWL file. There are example instances of classes and properties in the document, but there is no overall example of the use of the use of SAREF for an application.
14.3.5 Maintenance and usage
The SAREF core ontology version 3.1.1 was published in February 2020, with an update to the source RDF/OWL in May 2020. It is the basis for other standards.
-
14.4 SAREF4CITY (Smart Cities extension to SAREF)
https://www.etsi.org/deliver/etsi_ts/103400_103499/10341004/01.01.01_60/ts_10341004v010101p.pdf
ETSI Technical Specification “SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain” TS 103 410-4 V1.1.1 (2019-05)
NOTE This technical report does not have a link to the RDF/OWL representation of the ontology. This can be downloaded from https://forge.etsi.org/rep/SAREF/SAREF4CITY/ .
14.4.1 Defining organization
ETSI (European Telecommunications Standards Institute)
ETSI is one of the three organizations (CEN, CENELEC and ETSI) which develop European standards.
14.4.2 Objectives and scope
The introduction to the SAREF4CITY Technical Specification says that the following use cases defined in the requirements document were taken into account:
- eHealth and Smart Parking
- Air Quality Monitoring and Mobility
- Street Lighting, Air Quality Monitoring and Mobility
NOTE 2 The requirements for SAREF4CITY were defined in ETSI Technical Report “SmartM2M; SAREF extension investigation; Requirements for Smart Cities”, TR 103 506 V1.1.1 (2018-09) https://www.etsi.org/deliver/etsi_TR/103500_103599/103506/01.01.01_60/tr_103506v010101p.pdf .
The introduction further states that the requirements were grouped into the following categories:
- Topology;
- Administrative Area;
- City Object;
- Event;
- Measurement;
- Key Performance Indicator;
- Public Service.
NOTE 2 The requirements Technical Report lists the following sources:
oneM2m: The oneM2M base ontology is described in section 14.2.
OGC (Open Geospatial Consortium): The CityGML standard and the GeoSPARQL query language are mentioned.
AENOR CTN 178: The Spanish standard for smart maturity level which covers:
- business catalogue;
- cultural agenda;
- population;
- air quality;
- contracts, public procurement, and service providers;
- municipal budget and budget execution;
- public park loads;
- bus timetable, line, stops and fares;
- traffic; touristic places;
- city street guide.
ISO 37120:2018: “Sustainable cities and communities — Indicators for city services and quality of life”.
ISO/IEC 30182:2017: “Smart city concept model — Guidance for establishing a model for data interoperability”.
AIOTI: The Alliance for Internet of Things Innovation, founded by the European Commission in 2015.
FEMP (Federación Española de Municipios y Provincias): The Spanish Federation of Municipalities and Provinces has published a guide for smart city open data publication.
FIWARE: Open source Internet of Things community.
EU Horizon 2020 project: Relevant projects are:
- ISA2: “Interoperability solutions for public administrations, businesses and citizens”. which has defined a set of core vocabularies.
- ESPRESSO: “Systemic standardisation approach to empower smart cities and communities”, which has defined core vocabularies for smart cities.
- VICINITY: “Open virtual neighbourhood network to connect IoT infrastructures and smart objects”, which has developed an IoT infrastructure.
14.4.3 Structure of the model
In spite of the wide range of inputs, the SAREF4CITY model is admirably concise. The principal extension to SAREF is the adoption of the GeoSPARQL core shown in Figure 14.9.
Figure 14.9 - GeoSPARQL core
Underneath feature, SAREF4CITY defines a hierarchy as shown in Figure 14.10.
Figure 14.10 - SAREF4CITY feature
Comments on Figure 14.10:
1. A facility is defined as “A place, amenity, or piece of equipment provided for a particular purpose”, which is the definition taken from the Oxford English Dictionary.
2. A city object is defined as “Generic class for describing city objects”. Presumably it is anything in a city.
The SAREF4CITY ontology introduces the class agent, and has a small hierarchy under it as shown in Figure 14.11.
Figure 14.11 - SAREF4CITY agent
The FOAF (Friend Of A Friend) class agent is used in the SAREF4CITY ontology. Its subclass agent in the SAREF4CITY namespace is merely defined as an “agent making an action in the context of a city”. SAREF4CITY comments that an agent can be software, but does not have “software agent” as a subclass.
The SAREF4CITY ontology also contains the following classes directly under owl:Thing:
event: temporary and scheduled event, like a festival or competition;
key performance indicator: measurement which evaluates the success of an organization or of a particular activity in which it engages;
public service: provided by the government, either directly (through the public sector) or by financing provision of services
NOTE 1 These classes are not clearly integrated with the rest of the ontology. This may be because the ontology lacks “activity” as a class.
NOTE 2 The class public service has a subclass with the same name but in a different namespace. It is not clear how they are different.
14.4.4 Documentation
The SAREF4CITY ontology is documented as an ETSI Technical Specification. The ontology is well described in the document and there is good annotation in the OWL file.
14.4.5 Maintenance and usage
The ETSI Technical Specification version 1.1.1 was published in June 2019. The source RDF/OWL is at version 1.1.2, and was published in June 2020. The level of use is unclear.
-
14.5 SAREF4BLDG (Building domain extension to SAREF)
https://www.etsi.org/deliver/etsi_ts/103400_103499/10341003/01.01.02_60/ts_10341003v010102p.pdf
ETSI Technical Specification “SmartM2M; Extension to SAREF; Part 3: Building Domain” TS 103 410-3 V1.1.2 (2020-05)
NOTE This technical report does not have a link to the RDF/OWL representation of the ontology. This can be downloaded https://forge.etsi.org/rep/SAREF/saref4bldg/ .
14.5.1 Defining organization
ETSI (European Telecommunications Standards Institute)
ETSI is one of the three organizations (CEN, CENELEC and ETSI) which develop European standards.
14.5.2 Objectives and scope
The introduction to the SAREF4BLDG Technical Specification says:
The present document is a technical specification of SAREF4BLDG, an extension of the SAREF ontology that was created based on the Industry Foundation Classes (IFC) standard for building information. It should be noted that not the whole standard has been transformed since it exceeds the scope of this extension, which is limited to devices and appliances within the building domain.
The IFC specification is developed and maintained by buildingSMART International as its "Data standard" and, since its version IFC4, it is published as the ISO 16739 standard. SAREF4BLDG is meant to enable the (currently missing) interoperability among various actors (architects, engineers, consultants, contractors, and product component manufacturers, among others) and applications managing building information involved in the different phases of the building life cycle (Planning and Design, Construction, Commissioning, Operation, Retrofitting/Refurbishment/Reconfiguration, and Demolition/Recycling).
14.5.3 Structure of the model
The SAREF4BLDG model is admirably concise at the top. The principal extension is the inclusion of the building classes shown in Figure 14.12.
Figure 14.12 - SAREF4BLDG core
Comments on Figure 14.12:
1. The figure is analogous to the Geospaql core imported into SAREF4CITY, and shown in Figure 14.9. However it is not integrated with it.
2. Only Building in this figure is directly mapped to a class in the buildingSMART IFCs.
There is class hierarchy under BuildingDevice, which is shown in Figure 14.13.
Figure 14.13 - SAREF4BLDG device
Comments on Figure 14.13:
1. There are further subclasses under EnergyConversionDevice, FlowController, FlowMovingDevice, FlowStorageDevice, FlowTerminal and FlowTreatmentDevice.
2. SAREF4BLDG defines 67 classes, 177 object properties, and 82 datatype properties. Only 58 of the classes are mapped to a class in buildingSMART.
The SAREF4BLDG may not be seen as an authoritative source for building devices and their properties. Therefore the maintenance of the detail at the lower levels of the ontology may be a problem.
14.5.4 Documentation
The SAREF4CITY ontology is documented as an ETSI Technical Specification. The ontology is well described in the document and there is good annotation in the OWL file.
14.5.5 Maintenance and usage
The ETSI Technical Specification version 1.1.2 was published in June 2020. The source RDF/OWL is at version 1.1.2, and was published in April 2020 and modified in June 2020. The level of use is unclear.
-
14.6 Next Generation Sensors Initiative – Linked Data (NGSI-LD)
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_cim009v010101p.pdf
ETSI Group Specification “Context Information Management (CIM); NGSI-LD API”,GS CIM 009 V1.1.1 (2019-01)
NOTE 1 The JSON representation of the NGSI-LD information model can be downloaded from https://uri.etsi.org/ngsi-ld/v1/ .
NOTE 2 The NGSI-LD is a development of the Open Mobile Alliance (OMA) NGSI Context Management specification published in May 2012 - http://www.openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf
14.6.1 Defining organization
ETSI (European Telecommunications Standards Institute)
ETSI is one of the three organizations (CEN, CENELEC and ETSI) which develop European standards.
14.6.2 Objectives and scope
The introduction to the ETSI Group Specification NGSI-LD says:
The Context Information Management API allows users to provide, consume and subscribe to context information in multiple scenarios and involving multiple stakeholders.
The NGSI-LD gives HTTP access to data that is structured according to the NGSI-LD Information Model.
14.6.3 Structure of the model
The NGSI-LD information model has a layered structure as shown in Figure 14.14, which has been taken from the specification.
Figure 14.14 - NGSI-LD information model
The layers of the ontology are:
1. RDF/RDFS;
2. NGSI-LD meta-model, which extends RDF/RDFS with some generic objects;
3. NGSI-LD cross-domain ontology, which extends the meta-model with basic capabilities for the description of things in time and space.
The geometry in the cross-domain ontology is geoJSON (see the IETF GeoJSON Specification, RFC 7946).
NOTE SAREF4CITY uses the geoSPARQL specification from OGC. The OGC report “Benefits of Representing Spatial Data Using Semantic and Graph Technologies, October 2020, suggests the development of a geoJSON serialisation of geoSPARQL.
The ETSI groups specification contains the example of an implementation for a particular domain, shown as Figure 14.15.
Figure 14.15 - NGSI-LD domain extension example
There is no class state, even though there is a domain model property hasState. Possibly state could have been introduced as part of the cross-domain ontology. The oneM2M base ontology also lack the class state, but this is introduced by SAREF.
There is a mapping between the NGSI-LD API and the Digital Twins Definition Language (DTDI) which is defined by Microsoft. This is described in https://github.com/Azure/opendigitaltwins-smartcities/ . Both give access to JSON-LD defined data.
14.6.4 Documentation
The ETSI-LD ontology is documented as an ETSI Group Specification. The ontology is well described in the document. There is also a primer published as ETSI Group Report “Context Information Management (CIM); NGSI-LD Primer”, ETSI GR CIM 008 V1.1.1 (2020-03), which is available at https://www.etsi.org/deliver/etsi_gr/CIM/001_099/008/01.01.01_60/gr_CIM008v010101p.pdf .
14.6.5 Maintenance and usage
The ETSI Group Specification version 1.1.1 was published in January 2019. The source JSON-LD is at version 1.4, and was last modified in February 2021. It is the basis for other standards.
-
14.7 Smart Cities Ontology for Digital Twins
Further documentation and the source files are available at:
https://github.com/Azure/opendigitaltwins-smartcities/ .
14.7.1 Defining organization
Microsoft in collaboration with:
- Open Agile Smart Cities (OASC) – a worldwide consortium of cities launched in 2015;
- Sirus – a software consultancy based in the USA.
Additional validation is being carried out by Siemens and ene.hub (a smart cities consultancy based in Australia and the USA)
14.7.2 Objectives and scope
The introduction to the Smart Cities ontology says:
As cities continue connecting their urban environments, the concept of digital twins—a digital representation of real-world environments brought to life with real time data from sensors and other data sources—has entered the realm of smart cities and promises to enable city administrations and urban planners to make better decisions with the help of data integration and visualization from across the urban space.
[…] The Azure Digital Twins platform enables developers to model and create digital representations of connected environments like buildings, factories, farms, energy networks, railways, stadiums, and cities, then bring these entities to life with a live execution environment that integrates IoT and other data sources.
[…] The open-source GitHub repository of Smart Cities ontology for Azure Digital Twins is available to the ecosystem.
The Microsoft Digital Twins Definition Language (DTDL) gives access to data defined in JSON-LD. The DTDL has a “context model” which is similar to the NGSI-LD meta-model shown in Figure 14.14.
The mapping between NGSI-LD and DTDL is as follows:
NGSI-LD
DTDL
Entity
Interface
Relationship
Relationship, Component
Property
Property, Telemetry
n/a
Command
NOTE Command is a class in the oneM2M base ontology, but not the SAREF core ontology.
14.7.3 Structure of the model
The Smart Cities ontology consists of a several sub ontologies which inherit from NGSI-LD or DTDL.
There are two sources for these ontologies
1. https://github.com/smart-data-models/SmartCities/
2. https://github.com/Azure/opendigitaltwins-smartcities
The difference between the ontology repositories is unclear. Some sub-ontologies are in both.
In repository 1, there are folders as follows:
- Building
- Parking
- ParksAndGardens
- PointOfInterest
- Ports
- Streetlighting
- Transportation
- UrbanMobility
- WasteManagement
- Weather
Within each folder there are several sub-ontologies. Two folders have been looked as examples:
-
the Building folder contains sub-ontologies:
- Building
-
Building Operation
-
the Transportation folder contains sub-ontologies:
- Bike Hire Docking Station
- Crowd Flow Observed
- EV Charging Station
- Road
- Road Segment
- Traffic Flow Observed
- Transport Station
- Vehicle
- Vehicle Model
In repository 2, there are folders for:
- Administrative Area
- City Object
- Environment
- Mobility
- Parking
- Point Of Interest
- Ports
- Streetlights
The content of the Administrative Area ontology is taken from SAREF4CITY, as is the class CityObject. The building ontologies are based on ontologies developed by the mobile phone operators consortium GSMA.
NOTE This is consistent with the content of the ontology which contains data relevant to the placing of a mobile phone mast and access to it.
The introduction to the ontologies says:
In addition to the core meta-model, NGSI-LD compliant open models for aspects of smart cities have been defined by organizations and projects, including OASC, FIWARE, GSMA and the Synchronicity project.
In addition to the ETSI NGSI-LD, we’ve also started adapting in DTDL the constructs of ETSI SAREF extension for Smart Cities (Saref4City) ontology for Topology to represent spatial objects, Administrative Area and City Object modeling.
14.7.4 Documentation
The documentation of the sub-ontologies within the Smart City ontology is limited.
NOTE Many of the sub-ontologies are taken from other sources, and documentation may be found there.
The documentation of the Digital Twin Definition Language is good.
14.7.5 Maintenance and usage
The ontologies are actively maintained and for many the GIT update dates for the files are within the last month. However there seems to be no version control.
It is not clear that ontologies are used outside of the projects that created them.
