The eProcurement Ontology Methodology
Overview
The ePO development and maintenance methodology is an adaptation of the Linked Open Terms (LOT) methodology, and applies both to the development of the ePO Ontology as a whole, and to its modules:
Image Source: https://lot.linkeddata.es/
The above diagram demonstrates that the approach is cyclical and includes the following high-level activities:
-
Requirements Specification
-
Ontology Implementation
-
Ontology Publication
-
Ontology Maintenance
Requirements Specification
The Ontology Requirements Specification activity refers to the collection of the requirements the ontology should fulfil, such as:
-
the goal of the ontology
-
the domain the ontology should model, or
-
the technical details of the ontology
Collectively in the Working Group, ontology developers, domain experts, and ontology users go through a process of requirement elecitation, requirement capture, and requirement documentation, as illustrated in the detailed workflow below:
Image Source: https://lot.linkeddata.es/
The outputs of the requirements specification step are:
-
Use case specifications that provide a view of the ontology’s potential use. They describe the desired situations to be reached with the data described by the vocabulary. Their objective is to guide the collecting of the requirements.
The specification of a use case consists of the narration of a scenario, in which one or several actors intervene, and the interactions necessary to obtain an expected result or benefit. -
Data documentation and examples that provide the ontology development team with the necessary documentation about the domain to be modelled. The documentation could include datasets, regulations, standards, data formats, APIs specifications, database schemas, etc.
-
The Ontology purpose and scope specification document.
-
Functional ontology requirements that contain, among others, Competency questions (CQs) and Natural language statements, where each requirement unambiguously defines a need that must be included in the ontology.
-
The Ontology Requirements Specification Document (ORSD), which is the final artifact produced. This contains all the functional and non-functional requirements identified in the process and the information associated to them. LOT provides a template for the ORSD.
Ontology Implementation
The ontology is implemented as a UML conceptual model, which is automatically transformed into formal representations, namely OWL2 and SHACL. The rationale for this is explained in the eProcurement ontology architecture and formalisation specifications and in the SEMIC style guide.
The workflow of this stage, depicted below, is different from the one provided in the LOT.
minimize minimise
Image Source: https://lot.linkeddata.es/
Conceptual model proposal activity results in an (early stage) conceptual model expressed in UML that respects the ePO UML conventions. In this step, the ontology editors encode the requirements as UML class diagrams.
Conceptual model completion activity results in a (verified) conceptual model that has been presented to and acknowledged by the domain experts and users. The ontology editor demonstrates, to the working group, how the requirements are fulfilled by the conceptual model.
Where comments or requests for changes are provided by the domain experts or ontology users, the proposed model is updated to accommodate the new information until consensus is reached.
Ontology formalisation is an automated step that results in the formal ontology artefacts. In the case of the ePO, they are: the conventions checking report (UML conformance report), the core layer (OWL representation), the restrictions layer (OWL representation), the data shape layer (SHACL representation).
Ontology evaluation is a manual step as detailed in the LOT methodology and involves
-
Validation, that addresses the following:
-
Conformance of the conceptual model to the UML conventions;
-
Formal correctness: is the OWL and SHACL code correct?
-
Glossary completeness: do we have all the definitions for classes and properties?
-
Detection of bad practices or suboptimal modelling choices
-
Logical consistency
-
-
Verification, which compares the ontology against the ontology specification document (ontology requirements and competency questions), ensuring that the ontology is built correctly (in compliance with the ontology specification requirements collected in the ORSD).
Ontology Publication
The ontology publication stage is very similar to the one defined in the LOT methodology. The workflow is presented in the figure below.
Image Source: https://lot.linkeddata.es/
Publication starts with a proposed release candidate. Once the ontology developers have implemented and evaluated the ontology, the next task is to decide whether the current version will be published on the Web. A version considered worthy of publication is stable, verified, and complete with regard to the established release objectives and coverage. The ePO Versioning methodology and principles are published elsewhere.
In the Ontology documentation step detailed in the LOT methodology, the ontology development team (together with the domain experts) generate the ontology documentation, using the ontology code and potentially other artefacts as input. These include glossaries, conceptual model diagram documentation, requirements specification, tests, and examples.
The ontology is published on the Web following the practices provided by the W3C for publishing vocabularies on the Web. It is accessible via its URI as a file in a formal language and as human-readable documentation using content negotiation.
The documentation of the ontology is maintained in AsciiDoc (source) format and then transformed into HTML format. Once it has been generated, it is published online.
Ontology Maintenance
The goal of this activity is to update the ontology as required during its life cycle. The ontology maintenance stage is described in the LOT methodology.
Image Source: https://lot.linkeddata.es/
Any ePO bugs detected are reported and documented via the ePO GitHub Issues.
Any new requirements can be raised either in the working group meetings or via the ePO GitHub Issues.
The use of GitHub is foreseen to openly and publicly discuss requests that have been submitted. The workflow of the request management is therefore seen as a cycle that starts with each new release.
References
-
Images: https://lot.linkeddata.es/
