Relation to ePO

This section provides the motivation for the model2owl software project within the eProcurement Ontology (ePO) project. The business context and the project overview are detailed in the eProcurement ontology architecture and formalisation specifications.

We provide here a working specification of the guidelines and conventions for the eProcurement conceptual model, such that it qualifies as suitable input for the transformation scripts meant to generate the formal eProcurement ontology. The model2owl toolset, which hosts these transformation scripts, is therefore an integral part of the ePO project.

Background

In the eProcurement ontology project, the conceptual model was decided [d2.01-2017] to be represented in Unified Modelling Language (UML) [uml-userguide]. It is a visual representation language that facilitates understanding and convergence between stakeholders towards a common conceptualisation of the model.

Generally, the primary application of UML [fowler2004] for ontology design is in the specification of class diagrams, a design formalism initially conceived for object-oriented software. UML does not define a formal semantics that would permit to determine, from the class diagrams, whether a corresponding ontology is consistent, or to determine the correctness of the ontology implementation. Semantics in UML is therefore subject to interpretation by the stakeholders involved in the development process, and later by the users in the application and integration tasks [grunninger2003].

Yet, UML is closer than more logic-oriented approaches to the programming languages in which software applications — typically enterprise applications — are implemented. For this reason, the current specification establishes conventions for interpretation of the UML-based conceptual model.

The UML Conceptual Model of the eProcurement domain serves as the single source of truth, which means that the formal eProcurement ontology is derived from it through a model transformation process. It is possible to generate automatically the formal ontology in RDF format [rdf11] from the XMI (v.2.5.1) serialisation [xmi2.5.1] of a UML (v.2.5) model [uml2.5], provided that a set of modelling conventions is respected, and that a set of clear transformation rules is established.

This document provides the UML modelling constraints and a set of conventional and technical recommendations for naming and structuring the UML class diagram elements: packages, classes, data types, enumerations, enumeration items, class attributes, association relation and dependency relation. These will be addressed contextually in the subsections of UML conventions specification.

eProcurement conceptual model requirements

The eProcurement conceptual model must fulfil mainly four fundamental objectives.

  • Facilitate understanding/comprehension of the represented system

  • Promote efficient conveyance of system details between team members and external stakeholders.

  • Provide a point of reference for system designers to gather system specifications and documentation.

  • Serve as input for development of a (more) formal model.

In order to support the objectives, the eProcurement conceptual model must fulfil the following requirements:

  • Be available to all stakeholders, to facilitate collaboration and iteration.

  • Be easily changeable, as a continuous reflection of up-to-date information.

  • Contain both visual and written forms of diagramming, to better explain the abstract concepts it may represent.

  • Establish relevant terms and concepts that will be used throughout the project.

  • Define terms and concepts.

  • Provide a basic structure for the conceptual entities of the project.

  • Reduce the ambiguity while maintaining a simple and concise encoding.