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.
CEUR ceur-ws.org
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 dificult 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 CEUR Workshop Proceedings 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 diferent 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 [
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 O2
The ontology must be modular, including modules that cover knowledge common to all IoT platform components; The ontology must reuse some identified ontologies for the application domains at stake; The ontology must have a homogeneous and predictable structure, such that similar concepts for diferent domains are described the same way; Diferent alternative representations must be possible to account for the need to manipulate small knowledge graphs in constrained devices; 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 efectiveness and eficiency of the collaborative efort.
Agile principles must be adopted to improve collaboration between ontology engineers, domain experts, and end-product owners, with short cycles, and working increments; 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; Regular meetings among ontology engineers must be held, to help prioritizing the modules to work on, and ensuring work on diferent modules can be led in parallel; Collaborative software development platforms with code versioning and issue tracking shall be adopted; 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) [
Many ontology engineering methodologies have been proposed over time, including
METHONTOLOGY [
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 [
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 [
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 1The Manifesto for Agile Software Development lists 12 principles. http://agilemanifesto.org/iso/en/principles.html 2https://docs.github.com/en/developers/apps 3https://github.com/marketplace/actions/case-ontology-validator 4https://github.com/marketplace/actions/setup-rdflint 5https://github.com/marketplace/actions/rdf-syntax-check 6https://github.com/marketplace/actions/validate-rdf-with-jena 7https://github.com/marketplace/actions/validate-shacl adopt diferent 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.8
The 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 diferent 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 project9, 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 diferent domains.
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. 8See for example the debate about whether instances of ssn:Property should be specific to some feature of interest, or generic. [4, Footnote 8] and https://www.w3.org/2015/spatial/wiki/What_is_an_instance_of_ssn:Property. 9https://github.com/polifonia-project/stories start 1.a. DE+PO: Collect use case requirements 1.b. OE: Identify reference ontologies Main cycle Backlog management cycle
Use case extension cycle OE Ontology Engineer DE Domain Expert PO Product Owner
Extend use cases ? 7. OE: Integrate Modelet and Release Ontology Artifacts
6. OE (in parallel) Develop and Test Modelets
2. Review Meeting (all) * Prioritize use case requirements * Validate reference ontologies * Ensure common global understanding * Validate ontology artifacts 5. Modelet Development Meeting (OE) * Manage modelet backlog (synchronous) * Validate modelet artifacts
end 3. OE: Select relevant modules from reference
ontologies 4. OE (asynchronous): Manage Modelet Backlog
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. 10https://gitlab.com/coswot/coswot-samod/-/blob/master/domains/building-automation/evaluation/README.md
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 diferent 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 diferent 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) [
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 diferent 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, afordances , 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.
Each ontology engineer is in charge of developing and testing a modelet’s artifacts.A typical modelet definition includes the following elements: Description: motivation statement extracted from use case scenarios of one or more domains. Competency questions: a list of questions that translate the requirements, and examples of responses in natural language; Glossary: optional correspondences to reference ontology modules.
Diagrams: CHOWLK [
Ontological description: specification of classes, properties and individuals introduced by this modelet.
Example: some RDF graph instanciating the modelet for the use case scenarios. Example SPARQL queries: formalization of competency questions as SPARQL queries, that may be executed over the examples.
Recommendations: how to best use the modelet in other modelets or applications. This includes entity naming conventions to improve clarity and consistency.
Scripts: any automated script that can be run to specialize this modelet for diferent applications, or check that specializations satisfy the recommendations.
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 ProcedureExecutionOnProperty, 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 Ofice 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 diferent possibilities: Loop to 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. 11https://guides.github.com/introduction/flow/, https://docs.gitlab.com/ee/topics/gitlab_flow.html 12https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
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.
Workflow step
Script check syntax of README in modelet check syntax of Turtle files in modelet check syntax of SPARQL files in modelet check syntax of CSV files in modelet check that modelet has a title and a description check that (at least) one term is correctly defined in modelet check that (at least) one CQ is correctly defined in modelet evaluate tests in modelet generate documentation of snapshot check that all terms are introduced in (at least) a modelet generate and release documentation 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 eforts 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 (HyperAgents13, ACCORD14) 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). 13https://www.hyperagents.org/ 14https://accordproject.eu/ [1] S. Peroni, Samod: an agile methodology for the development of ontologies, in: Proceedings of the 13th OWL: Experiences and Directions Workshop and 5th OWL reasoner evaluation workshop (OWLED-ORE 2016), 2016, pp. 1–14.