Development Methodology
Some of the rules that were followed while advancing on the development of the ePO are the following:
-
A source management methodology was adopted so that we know how the development is advancing and inform others that are not involved on a weekly basis.
-
Ontology development based on a set of rules:
-
The concepts are modelled considering the temporal aspect of the procurement process (the process itself is not in scope, however)
-
Use an upper-level ontology as an anchor and decide what is the proper underpinning, ontological commitment and level of abstraction (the upper model is left outside of the ontology, however)
-
A few modelling principles are set in palace and applied consistently (wrt naming, relation directions, design patterns applied, etc.)
-
-
Scope set to include the concepts in the current TED standard forms and those from the eForms.
-
Adopting a modular structure of the ePO will provide an easier way of maintaining the model === Source management methodology
Good development practices were used for the development of the ontology: to use branches and tags in GIT. The main branch is the master. In order to introduce changes into the model, the development will be done in a different branch. After validation, this new branch will be merged with the master.
Figure 1. Source management methodology
Time phase approach
Some objects of the ontology are time agnostic (a buyer for example). When coming to the stage of describing, some properties have to take into account the phase of the procurement when these properties happen.
Figure 2. ePO phases in time
Upper-level organisation
Having an upper level of definition is important and helpful. The example below shows how an agent is the higher or abstract level and person is a lower level and more concrete.
Figure 3. Upper-level organisation of ePO
Principle-based perspective
The development of the eProcurement ontology is oriented by a principle based perspective. One example of a principle is that once something is created / instantiated it is not possible to modify it to something else completely different. (e.g. an organisation should be created only once and it is not repeated in a different way on the model).
Figure 4. Principles for ePO development
eForms coverage
One goal for ePO is that all eForms business terms (BT) are found somehow, somewhere in the ontology. This means that BTs become attributes of a class or relations (predicates).
Figure 5. eForms coverage
Modularity
It is possible to put all concepts of ontology together eCatalogue, eEvaluation, etc. but it makes the other phases too heavy. The modular approach makes it possible to focus on the core of each phase. This is a work in progress.
Figure 6. Modular approach of ePO (work in progress)
Technical aspects
Enterprise Architect (EA) is the tool used to design the conceptual model. The ontology is designed as UML model and Class diagrams offer thematic views on the model.
The ontology architecture is described in this report. It covers the main building blocks of the ontology, how it is layered (core, restrictions and shapes), and what output artefacts are created for each layer.
The UML model follows a set of conventions so that it can be transformed automatically into OWL, and SHACL representations (using model2owl toolchain).
Model refactoring
The new version adopts a package-based grouping of concepts. Also, there are more diagrams introduced than at the beginning of the ePO development. This makes it easier to avoid getting distracted by neighbouring concepts.
Figure 7. Package-based grouping of ePO concepts
The new structure of the ePO model provides hierarchy and relations diagrams.