Collect Requirements and Identify Reference Ontologies: 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 and reference ontologies for the domains at stake. These will facilitate the ontology development process and improve interoperability and community adoption. Learn more

Review Meeting : After Step 1, a review meeting 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. Learn more

Select Relevant Modules from Reference Ontologies : 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. 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, ortemperature 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. Learn more

Manage Module Backlog : To address modularity needs, 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, modelets are organized and managed in a \emph{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. Learn more

Modelet Development Meeting : Part of the backlog management and modelet assignment is done asynchronously through an issue tracker. In addition, dedicated module development meetings among ontology engineers (OEs) are organized. These meetings are the starting point of the inner cycles in \methodo. 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. Learn more

Develop and Test Modelets : Each ontology engineer is in charge of developing and testing a modelet's artifacts: description, competency questions (CQs), glossary, diagrams, ontological description, example SPARQL queries, recommendations and scripts. 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, specialization, domain-specific specialization, or Alternatively introduce alternative modeling choices. 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. Learn more

Integrate Modelet and Release Ontology Artifacts: 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. The ontology engineers may proceed with the management of the modelet backlog, 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: - 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. Learn more