This work describes the Agile and Continuous Integration for Modular Ontologies and Vocabularies (ACIMOV) ontology engineering methodology for developing ontologies and vocabularies. ACIMOV extends the SAMOD agile methodology to (1) ensure alignment to selected reference ontologies; (2) plan module development based on dependencies; (3) define ontology modules that can be specialized for specific domains; (4) empower active collaboration among ontology engineers and domain experts;
(5) enable application developers to select views of the ontology for their specific domain and use case. ACIMOV adopts the standard git-based approach for coding, leveraging agility and DevOps principles. It has been designed to be operationalized using collaborative software development platforms such as Github or Gitlab, and tooled with continuous integration and continuous deployment workflows (CI/CD workflows) that run syntactic and semantic checks on the repository, specialize modules, generate and publish the ontology documentation.
As formal and structured representations of knowledge, ontologies are key software assets for achieving semantic interoperability among complex systems such as Internet of Things (IoT) applications, industrial control systems, and robotics.
Monolithic ontologies are difficult to maintain, hard to understand and adopt and therefore serve little to other domains and applications besides those for which they were initially created. Modularity in ontology design refers to breaking down knowledge into smaller pieces called modules or sub-ontologies. Hence, a modular ontology is constructed as a set of modules by connecting concepts relevant to the domain or application at hand.
Building an ontology from small modules that can be specialized for different domains brings understandability and homogeneity to the overall ontology. Modular ontologies based on such module specializations enable developers of specific applications to create custom views by selecting the set of required specializations. The underlying knowledge factorization also streamlines the development process and eases maintainability and resilience, considering that problems arising within a module are handled in a targeted fashion.
Ontology development methodologies play a determining role in the development of highquality ontologies that satisfy application requirements. As ontologies are software resources, advances in software engineering best practices, such as agility, version control management, and DevOps, can be transposed to ontology engineering. Ontology engineering literature has dedicated extensive work to methodologies definition, many of them adapting some agile methodology. In this paper, we propose to extend existing agile methodologies with git-based development tools in the case of modular ontologies collaborative design.
Accordingly, the paper proposes an approach to collaboratively develop modular ontologies for multi-domain applications, by adapting the standard git-based approach for coding.
The rest of this paper is structured as follows. Section 2 introduces the research project in which this work has been led, and the resulting requirements for the ontology and its development methodology. Section 3 overviews related work on designing modular IoT domain ontologies. Section 4 describes the ACIMOV methodology, designed as an extension of the Simplified Agile Methodology for Ontology Development (SAMOD) [1]. Section 5 describes how ACIMOV can be operationalized with collaborative software development platforms, and tooled with scripts.
The Constrained Semantic Web of Things (CoSWoT) project [2] investigates the exchange of semantic data and the distribution of semantic reasoning in resource-constrained execution environments, which are common in the internet of things (IoT) applications. It aims at providing domain-independent solutions and focuses on two vertical domains: smart buildings and precision farming. Use cases for the building domain include: (SB1) personalized dashboards containing aggregated sensor measurements and enabling automatic alerts, (SB2) heating and window-opening control for optimizing the occupant's health, comfort, and energy consumption. Use cases for the precision farming domain include: (PF1) estimate the crop's growth stages or weather events based on outdoor air temperature measurements, (PF2) planning watering based on soil moisture level, crop's growth stage, and rainfall measurements, (PF3) speed adaptation of autonomous machines to fields' moisture measurements.
The knowledge model for the CoSWoT project must hold knowledge common to all IoT platform components, and knowledge specific to some domain or application. Subsets of the CoSWoT ontology, or views, will ultimately be embedded in resource-constrained devices for representing, reasoning, and exchanging sensor data. We summarize the requirements identified for the CoSWoT ontology as follows:
O1 The ontology must align to reference IoT ontologies; O2 The ontology must be modular, including modules that cover knowledge common to all IoT platform components; O3 The ontology must reuse some identified ontologies for the application domains at stake; O4 The ontology must have a homogeneous and predictable structure, such that similar concepts for different domains are described the same way; O5 Different alternative representations must be possible to account for the need to manipulate small knowledge graphs in constrained devices; O6 One must be able to select a subset of the ontology (a view) that covers the needs of a specific application.
In addition to ontology engineers, various stakeholder profiles are involved in the development of the CoSWoT ontology: domain experts (DEs) and end-product owners (POs) actively and continuously collaborate to elicit requirements, develop the ontology, develop applications that use the ontology, and maintain the ontology. In this context, the ontology development methodology should fulfill some requirements, to ensure good communication and maximize the effectiveness and efficiency of the collaborative effort.
M1 Agile principles must be adopted to improve collaboration between ontology engineers, domain experts, and end-product owners, with short cycles, and working increments; M2 Regular meetings with all parties must be held to help prioritizing the requirements stemming from use cases, and choosing the target for the next iteration; M3 Regular meetings among ontology engineers must be held, to help prioritizing the modules to work on, and ensuring work on different modules can be led in parallel; M4 Collaborative software development platforms with code versioning and issue tracking shall be adopted; M5 DevOps principles must be adopted to enable continuous integration and deployment of the ontology artifacts (e.g., ontology modules, documentation, examples)
Three IoT ontologies can be considered as references from standardization bodies: W3C Thing Description (TD) [3], OGC&W3C Semantic Sensor Network (SSN) [4], ETSI Smart Applications Reference ontology (SAREF) [5]. These three ontologies adopt some form of modular design. TD comes hand-to-hand with the Hypermedia Controls Ontology (HCTL) [6] and the JSON Schema in RDF vocabulary [7], and relies on separate vocabularies for protocol bindings, such as for HTTP, COAP, and MQTT [8]. SSN consists of a lightweight core called SOSA (Sensor, Observation, Sample, and Actuator), a more expressive extension module SSN, a separate module SSN-Systems for system capabilities, and a set of alignment modules to other ontologies. SAREF consists of a core ontology SAREF Core, and different extensions for verticals including SAREF4BLDG and SAREF4AGRI for building and agriculture domains.
Many ontology engineering methodologies have been proposed over time, including METHON-TOLOGY [9], On-To-Knowledge [10], DILIGENT [11], the "Ontology Development 101" [12], NeOn [13]. Some directly transpose software engineering methodologies, for example UPON Lite [14] is based on Rational Unified Process. The LOT methodology [15] adopts a V-model approach with conditional feedback at upstream development stages. Other early methods proposed to rely and align with existing ontologies to bootstrap new ontologies as in SENSUS [16].
More recently, methodologies are inspired by the principles of Agile software engineering, which promote collaboration between developers and stakeholders by producing regular updates of the product1 . Among these methods, AMOD [17] and CD-OAM [18] are based on SCRUM. AMOD is the first method that describes the cycle of ontology development in a SCRUM sprint. CD-OAM enriches AMOD by describing the management the ontology commitment user community. XPOD [19] and eXtreme ontology method [20] are based on eXtreme Programming. The Lean Ontology Development (LOD) [21] is inspired by the Lean approach: Build-Measure-Learn. SAMOD [1] is revisiting the motivating scenarios and competency questions of Uschold and Gruninger [22], additionally considering ontology modules and test-driven development.
Just as agility aims to improve collaborations between software project customers and developers, DevOps improves collaborations between developers and IT operations professionals. Jenkins, Travis CI, Circle CI, Gitlab CI/CD, Github Actions, are all frameworks that allow to specify task pipelines that will be executed automatically when, for example, a commit is pushed to the server. Before the democratization of these frameworks, a few preliminary approaches such as VoCol [23] or OnToology [24] were proposed in the ontology engineering community using Github applications 2 . Ontology Development Kit (ODK) [25] uses Travis CI to run workflows with the ROBOT tool [26] developed by the Open Biological and Biomedical Ontologies (OBO) community. CI/CD pipelines are reported for the publication of different ontologies, such as the Financial Industry Business Ontology (FIBO) in [27], the International Data Spaces Information Model (IDSA) in [28], and the CASE Cyber Ontology 3 . Specific Github actions are available on the Github marketplace for running RDFLint4 , validating RDF syntaxes 5,6 , or validating RDF files against SHACL shapes 7 or ShEx [29].
Upfront, we have chosen to align the CoSWoT ontology to the three reference IoT ontologies TD, SSN, SAREF. These ontologies cover partially overlapping requirements and sometimes adopt different modeling choices, which makes fulfilling Requirement O1 a challenging task. In addition, even in their communities of developers there are sometimes disagreements on how concepts should be used. 8The SAMOD methodology covers requirement M1. It is an agile method that promotes the incremental development of the ontology based on the aggregation of small and simple ontology chunks named modelets, which can be seen as implementations of design pattern. SAMOD encourages the reuse of existing ontology design patterns when relevant, instead of entire ontologies. The resulting ontology (current final model in SAMOD) is built incrementally and sequentially, one modelet by one modelet. SAMOD does not describe how modelets may be reworked (Requirement M2), nor how their development can be prioritized and led in parallel by different ontology engineer (Requirement M3). Section 4 describes the ACIMOV methodology as an extension of SAMOD that covers requirements O1, O2, O5, and M1 to M3.
To the best of our knowledge, the use of SAMOD has only partially been operationalized with the Github collaborative software development platform and CI/CD workflows, for instance in the Poliphonia project 9 , and this aspect has not been published yet (Requirements M4 and M5). Section 5 describes how we defined similar pipelines as those used on the FIBO, IDSA and CASE ontologies, to automate testing and publishing. In addition, it describes how we leverage DevOps tools to encourage ontology engineers to follow the methodology.
Finally, SAMOD may help covering Requirements O2 and O5 considering each modelet is a module, but requirements O4 and O6 are not covered. Section 5 describes how the ontology may consist of modelets that can be specialized for different domains.
Figure 1 provides an overview of the seven steps in the ACIMOV methodology. The methodology consists of an outer, longer cycle that involves ontology engineers, domain experts, and endproduct owners, and two inner, shorter cycles dedicated to development activities carried out by ontology engineers. The steps are:
Step 1 Collect requirements and identify reference ontologies.
Step 2 Review meeting (an event)
Step 3 Select relevant modules from reference ontologies
Step 5 Modelet development meeting (an event)
Step 6 Develop and test modelets
Step 7 Integrate modelet and release ontology artifacts The rest of this section describes these main steps, events, and artifacts, formalized in ACIMOV.
The outer cycle in ACIMOV starts with the collection of use cases requirements and the identification of reference ontologies. Requirement collection aims to determine the extent of the knowledge to capture. Domain experts autonomously specify use cases, and end-product owners define the application scope and how software components will make use of the ontology. In parallel, ontology engineers identify reference IoT ontologies (Req. O1) and reference ontologies for the domains at stake (Req. O3). These will facilitate the ontology development process and improve interoperability and community adoption.
After Step 1, a review meeting (Req. M2) is organized to specify and prioritize use case requirements, validate the selection of reference ontologies, and ensure a common global understanding of the domain and the end-products. Accordingly, ontology developers formulate a set of competency questions (CQs) that the ontology should be able to answer. An example of CQs for a module in the CoSWoT project can be found in the project repository 10 .
In subsequent development cycles, review meetings are also organized when the current version of the ontology artifacts is presented, reviewed, and validated with respect to its adequacy to the use cases and the end-product applications.
Ontology artifacts include the set of modules, the ontology and its documentation, validation reports, and examples.
Based on the output of a review meeting, ontology engineers examine how subsets of the selected reference ontologies may wholly or partially match the requirements, and address potential modeling discrepancies. In the case of different modeling choices, reconciliation involves identifying the most suitable to the application at hand or merging complementary modules to enlarge the set of covered concepts. For example, the IoT ontologies SSN and SAREF both describe sensor observations/measurements, but with different modeling choices. Documented ontology design patterns may help to find a common ground or generalization in case of modeling discrepancies. As an alternative, ontology engineers may conduct a deep analysis of the reference ontologies, using some upper ontology such as the Dolce-Ultralite ontology (DUL) [30].
The output of this task is reference ontology modules that will be reused in the ontology development. Some of them may have the potential of being specialized in different domains. For example, the sensor class could be specialized as moisture sensor, temperature and relative humidity sensor, or temperature sensor. Reference ontology modules keep track of the provenance to the reference ontology(ies) they are selected from, thus facilitating semantic interoperability with applications that use these reference ontologies. Selected reference ontology modules for CoSWoT describe sensors, affordances, quantity kinds, ...The full list can be found on the project repository.
To address modularity needs (Req. O2), the ontology is designed as a set of stand-alone modules called modelets, each describing a particular aspect of the ontology and covering a small set of requirements. Modelets have a loose N-N correspondence with reference ontology modules, allowing some flexibility and opening up extension tracks.
For requirement O4, modelets are organized and managed in a backlog, with some relations such as isSpecializationOf, dependsOn, isAlternativeFor, hasHigherPriorityThan.
The coverage of the current list of requirements can be assessed based on the list of modelets in the backlog. The network of modelets can be analyzed to select the next top-priority ones, or those on which depend top-priority modelets. As an output of this task, some modelets are assigned to ontology engineers for the next session of collaborative and parallel development.
Part of the backlog management and modelet assignment is done asynchronously through an issue tracker. In addition, dedicated modelet development meetings among ontology engineers (OEs) are organized (Req. M3). These meetings are the starting point of the inner cycles in ACIMOV. In subsequent iterations of the inner cycles, modelet development meetings are when the current version of the modelet artifacts are presented and reviewed, backlog change requests are raised and discussed, and modeling choices for dependent modelets are synchronized.
A modelet can be developed from scratch, following a formalization process where the terms in the requirements are mapped to classes and properties, and use case constraints are mapped to axioms. Alternatively a modelet can be adapted from an existing one, leveraging: Generalization. For example, SSN Observation, Sampling, and Actuation, may be generalized with some new class ProcedureExecution that generically describes the act of executing some procedure, like observation or actuation. Specialization. For example, ProcedureExecution can be specialized as ProcedureExecutionOn-Property, with additional object properties that link to the Property over which the activity is carried out, and the result. The resulting modelet better covers Observation, Actuation, and additionally covers forecasts, planned actuations, etc. Domain-Specific specialization. Top-domain classes or properties can be specialized for vertical domains (Req. O6). For example FeatureOfInterest may be specialized as Office and MeetingRoom, but also SoilOfPlot or CropCultivatedInThePlot. Property may be specialized as IndoorAirTemperature and CarbonDioxideConcentration, but also MoistureLevel and CropDevelopmentStage. Alternative. Modelet may introduce alternative modeling choices (Req. O5). For example, as an alternative to modeling results of procedure executions using the QUDT ontology, one may introduce datatype properties such as hasSimpleResultInDegreesCelsius to concisely link an observation to a decimal that encodes its result with the degrees Celsius unit.
Modelet testing requires checking the quality and coherence of the ontological description, examples of SPARQL queries, and scripts. Modelet validation requires successful testing results (eg. competency questions), and a decision from the team of ontology engineers during some modelet development meeting. This can be obtained after looping back to Step 4, then a next session of collaborative and parallel development may be planned.
When a modelet is validated, one may proceed with the modelet integration and release preparation in Step 7.
Modelets that are validated can be integrated into the global ontology. This requires global checks such as to ensure the absence of name clashes, and a careful review of dependencies that link the modelet to other modelets, so as to mention interrelation when appropriate. As part of this last step, the global ontology documentation can be improved, and the ontology artifacts can be produced and released, with respect to DevOps best practices (Req. M5).
The ontology engineers may proceed with the management of the modelet backlog (Step 4), and a modelet development meeting to plan the next session of collaborative and parallel development. Alternatively, the ontology artifacts may be reviewed and possibly validated by all the stakeholders during a review meeting, opening up three different possibilities:
Step 1 if more work is needed by the domain experts and the end-product owners to extend or refine the set of requirements; Proceed with Step 3 if a new set of use case requirements is selected to carry on the development of the ontology; End if the ontology is considered done.
The ACIMOV methodology aims to be aligned with modern collaborative software development platforms (Req. M4), such as Github and Gitlab. These platforms provide Git-based code versioning, integrate project management tools such as issue trackers and Kanban boards, allow for release hosting, and provide a range of continuous integration and continuous deployment (CI/CD) features.
Github and Gitlab come with a canonical workflow that drives the way various software management features are integrated into a single platform. Both workflows 11 are themselves based on the default Git branching workflow 12 . Git's versioning model is a directed graph of changes (additions/deletions of lines of text), also known as commits. A commit can have multiple children, each materializing a branch, and multiple parents, if some branch is merged into another one. The default Git workflow is defined upon three kinds of branches:
• main branches, which include stable, successive versions of a code base; • feature (a.k.a. topic) branches, which branch a code base to implement a new feature or to improve or fix an existing feature; • development branches, which integrate the content of (potentially conflicting) feature branches before merging the in-development code base into a main branch. ACIMOV naturally aligns with the default Git branching workflow. Modelets are developed in feature branches in Step 6, and merged into the main branch in Step 7. Several feature branches may be created and independent modelets can be developed in parallel. The workflow consists of the following steps:
1. create a new feature branch from the reference main or a development branch 2. commit one or more changes to the feature branch 3. perform unit tests on the feature being implemented or fixed 4. merge feature branch into the development branch 5. perform integration tests 6. merge development branch into main branch During the methodology Step 6, CI/CD features can be leveraged to automate the execution of modelet testing during their developement in feature branches. Custom syntactic and semantic tests are executed before committing to a feature branch or after merging to the main branch. Their integrated issue tracker is also commonly used to document desired or in-development features, in that an issue can be tied to a specifc feature branch: once the issue is created, a branch is also created and once the branch is merged, the issue is closed. The application of the default Git workflow to ontology engineering is straightforward, once a correspondence to topics or features has been found. Our methodology stipulates that changes in the ontology are performed per modelet. Creating a new modelet should thus be performed in a dedicated feature branch. The "modelet branch" should in turn only be merged if the competency questions of the modelet are fully addressed and tested. The content produced in a modelet (formal content in RDF, OWL, SHACL, SPARQL or other languages, query answers in CSV files, or any other textual and graphical documentation) should be isolated from the rest of the code base. Upon merging the created or modified modelet, a continuous integration pipeline compiles it into a publishable version, along with existing modelets.
A summary of developped and suggested integration scripts is given in Table 1. In addition to integration scripts, the operationalization of the ACIMOV methodology includes a set of scripts to automate the ontology generation based on modelet integrations (Req. M5).
In CoSWoT, two script types have been defined:
Specialization scripts enable domain experts to derive domain ontologies tailored to specific application requirements from the core ontology (Req. M1 and O6). This automation is simplified by the use of YAML files to support domain experts in specifying classes and properties configuration without extensive coding. An example of a specialization script and YAML file are available on the project repository. Consolidation scripts minimize manual efforts to create views of the ontology constructed from core modelets (Req. O6). Scripts integrate the management of dependencies to guarantee the validity and consistency of generated views and ensure the integration of the corresponding annotations and documentation.
This paper introduces the ACIMOV ontology development methodology extending SAMOD by leveraging git-based collaborative development solutions. The methodology is designed for modular ontologies development with a focus on reusing reference ontology modules. It consists of seven steps covering two development cycles carried out by ontology engineers for backlog management and a long collaborative cycle where domain experts and end-product owners feed the requirements collection and participate in the validation process. The methodology has been operationalized using Gitlab as a collaborative software development platform, integrating scripts for automatic domain-driven ontologies generation.
We have several perspectives for this work. First we are reproducing the methodology in the context of two other projects (HyperAgents 13 , ACCORD 14 ) which are using Github as their Ontology project management platform. We plan to use these second experimentations as evaluation. Then we intend to provide guidelines, templates, and scripts for the operationalization of ACIMOV on Gitlab and Github leveraging and specializing all the functionalities they provide to the case of ontology project management and development.
This work has been partly supported by grants from the French research agency (ANR) on projects CoSWot (ANR-19-CE23-0012) and HyperAgents (ANR-19-CE23-0030), and EU project ACCORD (Horizon Europe R&I programme grant agreement no. 101056973).