Report - ePO 3.0.0

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.

gfNuyNbjcSc1QAAAABJRU5ErkJggg==

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.

B7UsB8MhDtDeAAAAAElFTkSuQmCC

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.

oeX3EEAAAAAAAAwIAAAAAAAAAAAAADAgAAAAAAAAAADAgAAAAAAAAAADAgAAAAAAAAAADAgAAAAAAAAAAAAAMCAAAAAAAAAAAMCAAAAAAAAAAAMCAAAAAAAAAAAMCAAAAAAAAAAAAAAwF4xK5oyBBOmwAAAABJRU5ErkJggg==

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).

8yazKhahtygAAAAASUVORK5CYII=

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).

hfgEJ8b1QbtrQAAAABJRU5ErkJggg==

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.

BH2gTHDXgsY0JASpoE2ATM8A4YCnglgJ0ECYE4gLPJoT5iaj5H6s5T9yEDk68AAAAAElFTkSuQmCC

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.

z4RYDGOZyFlIJsFSJiTDQZkQZqBMCDP+H0V13NbBj64nAAAAAElFTkSuQmCC

Figure 7. Package-based grouping of ePO concepts

The new structure of the ePO model provides hierarchy and relations diagrams.

g84HWA81XvtSQAAAABJRU5ErkJggg==

Figure 8. Hierarchy diagram (focus on the abstraction)

hF8w4AAAAAAAAAAIDBJQAAAAAAAAAAgA4QAAAAAAAAAABABwgAAAAAAAAAAKADBAAAAAAAAAAA0AECAAAAAAAAAADoAAEAAAAAAAAAAHSAAAAAAAAAAAAAOkAAAAAAAAAAAAAd8D9NDCaya6r1KwAAAABJRU5ErkJggg==

Figure 9. Relations diagram (focus on the connections)
There are diagrams used for a scoped view versus a wide view of the model. It is useful to distinguish these scope diagrams because you can see how they are connected to other concepts, some show only the relations, some show only the hierarchy. So, even if the concepts are repeated across various diagrams this makes it easier to follow the logical model construction.

Evolution of 2.0.1 to 3.0.0

There is a considerable amount of changes introduced in this evolution. Among the most noteworthy changes are listed below. The detailed differences are provided in a diff report elsewhere.

  • UML/UBL data types were migrated to XSD data types.

bEQEyVAAAAAElFTkSuQmCC

Figure 10. xsd data types used

yoN3j3izh472o099qO95l923gAdB8AAAAACgdAQPAAAAAEpH8AAAAACgdAQPAAAAAEpH8AAAAACgdAQPAAAAAEpH8AAAAACgdAQPAAAAAEpH8AAAAACgdAQPAAAAAEpH8AAAAACgdAQPAAAAAEpH8AAAAACgdAQPAAAAAEpH8AAAAACgdAQPAAAAAEr3X1cF7ARMOskjAAAAAElFTkSuQmCC

Figure 11. Example of transitioning from old UML/UBL data types to new XSD data types

  • In the past the properties of a class the attribute type ‘Code’ was associated with the class where needed. Currently these attributes type code have been removed and there are only relations.

D8Bg1AZ6TuAsQAAAABJRU5ErkJggg==

Figure 12. Removal of “Code” type attributes

  • The naming conventions are harmonised for predicates and class names. The source class is connected with the target class by using a verb.

0V2Fq3a+x9Qo2wt3HYYPAAAAABJRU5ErkJggg==

Figure 13. Harmonisation of predicates and class names

  • The definitions of classes and attributes were completed for version 3.0.0.

  • Efforts were made to align to core vocabularies. The following core vocabularies were re-used:

    • Core Location Vocabulary

    • Core Person Vocabulary

    • Core Public Organisation Vocabulary

    • Core Criterion and Core Evidence Vocabulary

    • Core Public Service Vocabulary Application Profile

  • Another important part of the development was focused on the reification of the roles. After many discussions, the agent in role design pattern seemed to be the optimal approach for this.

cw1AAAAAElFTkSuQmCC

Figure 14. Agent In Role pattern
In version 3.0.0, the roles are represented as a hierarchical structure of concepts, with the superclass being the AgentInRole concept (following teh agent in role design pattern). The agent in role is played by an agent and it is contextualised by a procurement object (for example, lot or procedure).

Zd4Ly12vKadZ7w6US6NkhasiMIBELVyPb1a9v9lyaSh0zq5SMVCQw6je4Mb5ZvXMqHocl5jVr5XjKpv9jKiWAgCJpV3a9TuyWSqPNDAIGA5XdMvm8iQZl8vEy9j0z+DwQTxZSAND6jAAAAAElFTkSuQmCC

Figure 15. Roles hierarchy