eProcurement Ontology Architecture and Formalisation Specifications Version 1.0

Public procurement is undergoing a digital transformation. The EU supports the rethinking of the public procurement process with digital technologies in mind. This goes beyond simply moving to electronic tools; it also reassesses the various pre-award and post-award phases. The aim is to make processes simpler for businesses to participate in and for the public sector to manage. It also allows for the integration of data-based approaches at various stages of the procurement process.

Digital procurement is deeply linked to eGovernment. It is one of the key drivers towards the implementation of the “once-only principle” in public administrations, which is a cornerstone of the EU’s Digital Single Market strategy. In the age of big data, digital procurement is crucial in enabling governments to make data-driven decisions about public spending.

With digital tools, public spending should become more transparent, evidence-oriented, optimised, streamlined and integrated with market conditions. This puts eProcurement at the heart of other changes introduced to public procurement in new EU directives. PSI directive [_27] across the EU is calling for open, unobstructed access to public data in order to improve transparency and to boost innovation via the reuse of public data. Procurement data has been identified as data with a high-reuse potential [_3]. Therefore, making this data available in machine-readable formats, following the "data as a service" paradigm, is required in order to maximise its reuse.

Given the increasing importance of data standards for eProcurement, a number of initiatives driven by the public sector, industry, and academia have been kick-started in recent years. Some have grown organically, while others are the result of standardisation work. The vocabularies and the semantics that they introduce, the phases of public procurement they cover, and the technologies they use, all differ. These differences hamper data interoperability and thus data reuse, by them or the wider public. This creates the need for a common data standard for publishing public procurement data, hence allowing data from different sources to be easily accessed and linked, and consequently reused.

In this context, the Publications Office of the European Union aims to develop an eProcurement ontology. The objective of the eProcurement ontology is to act as this common standard on the conceptual level, based on consensus of the main stakeholders and designed to encompass the major requirements of the eProcurement process in conformance with the Directives and Regulations [_28], [_29], [_26], [_30]).

The target audience of the eProcurement ontology, defined in [_48], consists of the following groups of stakeholders:

In the past years much effort was invested into the eProcurement ontology initiative, including definition of requirements, provision of general specifications, identification of the main use cases, and laborious development of a preliminary shared conceptual model expressed using Unified Modelling Language (UML) ([_8], [_13].

The general methodology for developing the eProcurement ontology is described in [_24], [_3] – [_15]. It describes a process consisting of the following steps:

The ultimate objective of the eProcurement ontology project is to propose a commonly agreed OWL ontology that will conceptualise, formally encode, and make available in an open, structured and machine-readable format data around public procurement, covering end-to-end procurement, i.e. from notification, through tendering, awarding, ordering, and invoicing to payment ([_48]).

Work so far has concentrated on the conceptual modelling of the eNotification phase, taking into consideration the needs of other phases. The UML conceptual model has been created with the forthcoming procurement standard forms (eForms) in mind; the model has not been mapped to the current standard forms.

In the 2020 ISA² work programme a new project has been set up to analyse existing procurement data through the lens of the newly developed conceptual model. This means that the conceptual model needs to be transposed into a formal ontology, and a subset of the existing eProcurement data must be transformed into RDF format such that they instantiate the eProcurement ontology and conform to a set of predefined data shapes. Initially, the notification phase will be considered, while subsequent datasets will be decided at a later stage.

Working under the assumption that Steps 1–4 have been completed, current efforts are channeled towards designing, implementing and executing the necessary tasks to accomplish Step 5 from the above process. Once the formal ontology is created, and the XML data is transformed into RDF representation, the data can be queried to validate its suitability in satisfying the business use cases defined in ([_24], Sec. 3).

This document consists of an architectural specification and implementation guidelines that shall be taken into consideration when developing the formal ontology.

Other related artefacts (i.e. documents, scripts and datasets) are presented in Section 3, where it is described, in detail, the process for accomplishing the generation of the formal eProcurement ontology, transformation of the XML data, and the ontology validation.

There are several aspects that are excluded from the scope of this project stage:

Currently, the following items are in scope:

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [_9].

The key words “MUST (BUT WE KNOW YOU WON’T)”, “SHOULD CONSIDER”, “REALLY SHOULD NOT”, “OUGHT TO”, “WOULD PROBABLY”, “MAY WISH TO”, “COULD”, “POSSIBLE”, and “MIGHT” in this document are to be interpreted as described in RFC 6919 [_59].

The above listed terms are used in lower case form for stylistic and readability reasons.

This document describes normative and non-normative criteria for eProcurement ontology components and artefacts. The scripts, datasets, and the derived formal ontology and data shapes, must align to the normative criteria and may follow non-normative descriptions.

The XSLT stylesheets [_41] must be syntactically valid documents, and be executable with an XSLT engine with predictable output. They may be associated with XSPEC unit tests [_12] to ensure accuracy. The source code must be syntactically valid and compilable/interpretable by the corresponding state-of-the-art compiler/interpreter. The source code may be accompanied by unit tests to ensure accuracy of implementation.

The UML conceptual model must comply with UML standard version 2.5 [_13] and be serialised as XMI document version 2.5.1 [_1]. It also must comply with the conventions agreed with the Publications Office and other stakeholders described in [_14],14.

The core ontology and the formal restrictions components developed under these specifications must be valid OWL 2 documents in conformance with the conditions listed in [_45]. They should be available in at least Turtle and RDF/XML serialisation formats.

The data shapes component must be valid SHACL documents respecting the normative parts of the specification provided in [_43]. The instance datasets must be valid RDF1.1 documents that conform to the specifications [_10].

The URIs adopted under this specification must respect the policy provided in Section 6.

This section provides the main functionalities and use cases that the ontology should support. These requirements are derived from the use cases identified in the report on policy support for eProcurement [_48] and outlined in the eProcurement project chapter proposal [_23].

This section provides the characteristics, qualities and general aspects that the eProcurement ontology should satisfy.

For the purpose of knowledge sharing and interoperation between programs based on a shared conceptualisation, Gruber [_37] proposes a set of preliminary design criteria a formal ontology should follow:

The process starts with authoring two documents laying the foundations of the entire process: the ontology architecture and the UML modelling conventions [_14].

The main purpose of the ontology architecture specifications (this document) is to describe why the ontology is being built, what its intended uses are, who the end-users are, and which requirements the ontology should fulfil. Moreover, it states how the ontology should be structured in order to facilitate maintenance and usage patterns.

The conceptual model must comply with a set of UML modelling conventions making it suitable input for the transformation scripts that implement the same conventions. The two parallel actions starting the process are depicted in Figure 2.

The UML conventions document serves, in the most part, as the requirement specifications for the XSLT script that checks whether the UML conceptual model conforms to the conventions.

The ontology architecture specification (this document) serves, in the most part, as requirement specifications for the development of three XSLT scripts to generate the formal ontology. These scripts can be developed independent of each other as they refer to different aspects of the formal ontology as described in Section 4.1.

The input for these scripts is the UML conceptual model authored using Enterprise Architect and serialised in XMI 2.5.1 format [_1].

The current project runs under the assumption that the conceptual model is organised and expressed in accordance to the UML conventions specified in [_14]. However, the conceptual model was developed well before the UML conventions were established. Therefore, the model needs adjustments to conform to the conventions.

Having this assumption violated is a risk with critical impact. Therefore, an auxiliary process was developed (see Figure 3) to continuously improve and correct the model in case it is non-conforming.

Revision of the conceptual model is an iterative process. A validation script is developed in a preceding step (see Section 3.1). This script it is executed on the current conceptual model outputting a report. This report consists of errors and warnings with detailed descriptions of what the deviation from the UML conventions is. It also provides hints for the conceptual model designer of the necessary actions to resolve issues.

The UML conceptual model constitutes the sole main input for three transformation scripts. Therefore, it is very important to ensure that the conceptual model conforms to the set of UML conventions [_14]. The conventions ensure that the conceptual model represents an adequate input for the transformations script as they are developed based on the same set of conventions and assumptions.

The transformation scripts, developed in a preceding step described in Section 3.1, are:

Each are executed on the current conceptual model resulting in three output artefacts, or three sets of outputs artefacts, that depends on the implementation decisions. Each output corresponds to one of the components of the eProcurement ontology addressed in Section 4.2: the formal core ontology, the SHACL data shapes, and the formal ontology restrictions.

This concludes the ontology generation process depicted in Figure 4.

In the introduction of this document, Section 1.3 explains the necessity of transforming the current eProcurement data from XML format (structured according to the standard forms) into RDF format. This process is depicted in Figure 5.

The data must represent instances of the ontology generated in previous step, explained in Section 3.3, which is structured according to the forthcoming eForms. This means that the transformations script must consider a carefully established conceptual mapping between the two standards in addition to implementing the format transformation itself. Figure 5a reflects that, and in addition, the XSD schemas, to which existent XML data conform, must be consulted and considered in the design and implementation process. Current specification is agnostic to the technology used for implementing data transformation process. A noteworthy candidate is XSLT – a language for expressing XML transformations. Yet, for the standard programming languages such as Java, Python, JavaScript and many others, mature libraries to process XML and RDF are available.

The execution of data transformation process (see Figure 5b) unfolds in three steps as follows. First, the selected data is fed as input to the transformation script. The output RDF data are then validated for conformance to the formal ontology using the SHACL data shapes. The validation output is a report in RDF format listing possible violations of the data. This report is transformed into a human-readable form using a SPARQL query, used to interpret the conformance of the data and eventually spot mistakes in the transformation script of the data shapes. These reports must be used during the transformation script development as additional stress tests for whether the script performs correctly, or whether it needs further adjustments. Of course, these reports may indicate problems stemming from either the transformation script, the input data, or the SHACL shapes. Therefore, a developer’s assessment is necessary to determine the source of the issue and provide the necessary feedback. The script development process may be considered complete when, for a random set of input data, the analysts and developers can assert that only the input data caused the exceptions. The data-driven conformance exceptions constitute an important input in the ontology validation step of the process presented in Section 3.5.

The ontology evaluation process aims at assessing how well the use cases listed in the functional requirements (see Section 2.1) are enabled and supported by the formal ontology, and consequently the conceptual model. The evaluation process needs to be designed elsewhere, but at this stage it is possible to foresee two processes that needs to take place: loading the data into a triple-store and querying the data and analysing the result-set for fitness.

Figure 6 depicts the process of loading data into a triple store. Three components must be ingested before it is ready for query:

The triple-store organisation, whether it acts as an eProcurement data dissemination service, URI de-referencing, or other publications related issue, is not in scope of the current architecture specification. Nevertheless, the data organisation and dissemination should be treated elsewhere in detail considering the best practices for publishing linked data [_7].

For the purposes of the evaluation efforts, the TBox axioms, i.e. the core ontology and the formal restrictions, must be saved in a dedicated graph. It is recommended that the instance data is also partitioned into a set of logical and manageable graphs.

Once the data and the ontology are loaded, the benefits of the underlying logical formalism can be drawn: checking the consistency of the data dn model and inferring new knowledge from the existent one. In case the triple store has an incorporated reasoner it should be enabled following an OWL 2 direct semantics described in Section 5.2. Otherwise, an external reasoner such as Fact++ [_64], Pellet [_62], HermiT [_60] or CB [_42] must be used to enrich the triple-store. A comparison of OWL 2 EL reasoners is provided in [_25]. It is, however, dated, and thorough state-of-the-art research needs to be considered before commencing the work on reasoning.

It is not yet possible at this stage to decide about the range of reasoning capabilities that can be engaged for the eProcurement ontology. Experiments must be conducted on available data to evaluate the speed of reasoning against the expressivity of the considered formalism expressivity and the coverage of inference rules as described in Section 5.4.

In principle, it is possible to engage with the ontology evaluation process directly after the data loading steps, skipping the inferencing step, but the range of potential answers will be limited to an extent which is not possible to evaluate currently.

Once the triple store is enriched with inferred information, it can be used to address the use case related information needs. The process is depicted in Figure 7.

Each use case carries a set of information needs which must be derived and expressed in the form of SPARQL queries. The ontology evaluation process commences with developing a collection of such queries. Then they are executed on the triple-store, and the result sets collected. Empty sets are also important results as they indicate a possibly ill-formed query, a lacuna in the existent data or an incorrectly modelled ontological segment.

The result sets are evaluated and aggregated into a conclusive report explaining the strong and weak points of the developed ontology in addressing the selected use cases given the existent data.

The successful application of an ontology or the development of an ontology-based system depends not just on building a good ontology but also on fitting this into an appropriate development process. All computing information models suffer from a semantic schizophrenia. On the one hand, the model represents the domain; on the other hand, it represents the implemented system, which then represents the domain. These different representation requirements place different demands upon its structure [_53].

One of the common ways to manage this problem is a separation of concerns. OMG’s Model Driven Architecture (MDA) [_63] is a well-documented structure where a model is built for each concern and this is transformed into a different model for a different concern.

Transformation deals with producing different models, viewpoints, or artefacts from a model based on a transformation pattern. In general, transformation can be used to produce one representation from another, or to cross levels of abstraction or architectural layers [_61].

The process described in Section 3 incorporates some of these principles and employs model transformation as means to achieve the project objectives.

This architecture is organised in horizontal layers and vertically slicing components. The components reflect the organisation of the formal ontology based on a logical content division of the UML conceptual model into packages and modules. This division increases the maintainability of entire content. The models and their components are not disconnected from one another. The relations between them are represented in Figure 8 where each component is represented as a UML package. The conceptual model serves as the single source of truth, from which the three components of the formal model are derived. Each of these components can be further divided into modules.

The main ontology packages are: the core ontology, data shapes, and formal ontology restrictions. These formal modules are derived from the conceptual model through model transformations as described in Section 3 following the rules laid out in [_15].

The core ontology is the foundational, and serves as a backbone for the other components. It establishes the identifiers and the basic definitions of classes and properties.

The data shapes represent constraints on how the core ontology can be instantiated, and the set of controlled value lists associated to it.

The formal ontology restrictions cover intentional class and property definitions used for deriving additional knowledge from factual information. Both, the data shapes and the ontology restrictions are defined as extensions that are flashing out the core ontology which plays, in this case the role of a backbone.

The architecture distinguishes the following layers: the conceptual layer, core definition layer, validation layer and reasoning layer. These layers can be thought of as formal languages with well-defined boundaries and extents. The diagram in Figure 9 presents the organisation the ontology layers along two axes: expressivity and detail. The expressivity of a language is the breadth of ideas that can be represented and communicated in that language. The more expressive the language is, the greater the variety and quantity of ideas it can be used to represent.

The design of a language and its formalism involves an inevitable trade-off between the expressive power and its “analysability”, which translates directly into computation difficulty. The more a formalism can express, the harder it becomes to understand, i.e. compute, what instances of it mean.

The detail refers to how much description and aspects of the domain concepts are considered. This dimension plays a pragmatic rather than a formal role. The rationale is that a lower level of detail is useful, and re-usable to a wider public, but only for a set of relatively simple tasks. As the level of detail increases, the difficulty to operate with it also increases thus the user base shrinks, and the task complexity rises. The detail axis starts, on one side, with establishing the concepts of identity, labels, natural language definitions; and continues through establishing relations and constraints; and ends, on the other side, with formulating special logical conditions, implications and inference rules. The conceptual layer accommodates an informal representation of the business objects, places, things, actors in the “real world”, not representations of these things in the information system. It is situated at the base of the diagram with the lowest expressivity because it does not have formal semantics but does have a wide coverage of detail. The dotted line delimits the border between formal and informal layers.

The UML conceptual is situated in the conceptual layer of the model, which is described in Section 4.3. This model is also called the computation independent model because it is informal and its main purpose is to interface the domain experts with an explicit conceptual representation of the domain.

In the formal section of the diagram, the expert knowledge is expressed using descriptive languages with formal semantics (see Section 5.2), which in this architecture are primarily OWL 2[_52] and SHACL[_43].

The core layer is situated in the core ontology, which has as a primary goal, the definition of the main concepts and relations of the ontology. It is limited to the declarative axioms of the ontology and therefore serves primarily for vocabulary and identity establishment. For this reason, it is represented as having the lowest formal expressivity and the lightest level of detail in comparison to other layers. It plays the role of a backbone which is fleshed out by other layers.

The validation layer accommodates declarations of data shapes which represent constraints on the instance data, i.e. the ABox (see Section 5.1). The assertions in this layer are interpreted done under the closed world assumption, making it possible to support validation functionality. The SHACL shapes are situated in this layer and are addressed in detail in Section 4.5. The validation layer is situated immediately above the core definitions, being more expressive but also extending it with additional detail. Therefore, it is shifted, on the detail axis, to the right towards more detail, leaving out the simple axioms as they are already covered in the core later.

The reasoning layer accommodates formal intentional definitions of the classes and properties. In Logics, intentional definition gives the meaning of a term by specifying necessary and sufficient conditions for when the term should be used. This layer is mostly formed of subclass restrictions, complex class definitions, and domain and range specifications for properties. This layer provides assertions necessary to support consistency checking and classification reasoning functionalities for the eProcurement ontology. The formal ontology restrictions component is situated in this layer and is described in Section 4.6.

Just like in the case of the restrictions layer, the reasoning layer extends the core layer with higher level of detail and consists of assertions with a higher expressive power. Therefore, the simple details rest in the core layer permitting this one to focus on other ones. For this reason, it is depicted as shifted towards the right side of the detail axis.

The conceptual model, represented in UML [_8], serves as the single source of truth. Thus, the scope of this architecture is limited by what can be expressed in UML and how that information is utilised to generate formal statements. Each of the above functions will lead to different interpretations of the same UML model.

The primary application of UML [_34] for ontology design is in the specification of class diagrams for object-oriented software. However, UML does not have clearly specified declarative semantics, so it is not possible to determine whether an ontology is consistent, or to determine the correctness of an implementation of the ontology. Semantic integration in such cases becomes a subjective exercise, validated only by the opinions of the human designers involved in the integration effort [_38].

On the other hand, UML is closer than more logic-oriented approaches to the programming languages in which enterprise applications are implemented. For this reason in the current project, we have decided to develop agreements on the informal semantics of the UML-based conceptual model. It consists of a set of explicit conventions for naming and structuring UML elements [_14] and for transforming UML to OWL [_15].

This component constitutes the backbone of the eProcurement ontology. It is the simplest from the formal point of view and is lightest in terms of detail. The main purpose of this component is to declare the classes, properties, data types, and controlled lists. It established the concepts, in a machine-readable format, by assigning each one a URI and decorating it with a human-readable label and descriptions. This represents a mechanism that establishes a common understanding between humans and machine. It is void of any constraints or restrictions and may be used as a formal ontology or as a data exchange vocabulary.

In OWL the constraints are formed at the semantic level so that the logic of the entire knowledge base holds together consistently. It is not always easy or obvious how the constraints should be formed so that they fulfil a business or application requirement. Moreover, often in practice, the kind of constraints necessary are those aiming at the surface representation of the data. Take, XSD for example, it provides a description of how an XML document ought to be structured.

In the eProcurement domain, before the RDF data is utilised as a semantic resource, it must first respect more formal conventions on how it is instantiated and organised. There is a need for the XSD counterpart for the RDF graphs.

Shapes Constraint Language (SHACL) [_43] is a specification for validating graph-based data against a set of conditions. It provides a concise, uniform syntax for both describing and constraining the contents of an RDF graph. Among others, SHACL includes features to express conditions that constrain the number of values that a property may have, the type of such values, numeric ranges, string matching patterns, and logical combinations of such constraints.

Application profiles (AP) impose a set of constraints on the logical model tying it to a particular system implementation. The application profiles in this project must be expressed using SHACL language. The approach taken by the Publications Office to develop APs is described in [_16]. The same style should be maintained for the eProcurement APs.

The AP must be conceived as extending the core ontology and fleshing out the classes and properties with node and property shapes (see [_43], Sec 2.2–2.3). The constraints available in the conceptual model are generic and should be automatically generated. However, when it comes to integration with specific systems, these constraints may not be sufficient, possibly being too rigid at times. Therefore, it is recommended to conceptualise the data shapes not as a single-fits-all AP, but rather to create specific APs as the need arises.

This component accommodates formal intentional definitions of the classes and properties. It is mostly formed of subclass restrictions, complex class definitions, and domain and range specifications for properties, which can be derived from the conceptual model.

This component provides the rules and logical conditions for reasoning with eProcurement ontology. Therefore, the statements from this component play the role of necessary and sufficient conditions to support consistency checking and classification reasoning functionalities for eProcurement ontology.

Mostly expressions in OWL 2 should be acceptable for the reasoning purposes of eProcurement ontology. It is possible, however, that OWL 2 is too expressive, leading to slow reasoning, and thus downgrading to an OWL dialect (EL, QL, RL) might be necessary. This implies that multiple variants of these components should be generated, one for each OWL dialect as described in Section 5.4. Each of these variants shall be tested, and the most appropriate choice selected for reasoning in the validation phase (see Section 3.5).

DL ontologies are structured into two sets: ABox and TBox. The ABox consists of all (class or property) instance assertions. The TBox consists of all terminological axioms, i.e., of all subclass inclusion axioms. The ABox provides information about concrete individuals while the TBox describes general rules that hold for all individuals. In consequence, ABoxes tend to be much larger than TBoxes [_44].In Figure 10 depicts the delimitation and relations between the TBox and box ABox components of the eProcurement ontology.

To explain the relevance of each component in Figure 10, two arbitrary datasets are brought in as examples. They instantiate the core ontology, which means that they consist of factual statements of concrete entities of eProcurement classes. In order to ensure that the instance data follow the intended ontology design minimally, they need to comply with a set of data shapes. Once this condition is satisfied, then given the domain inference rules, new knowledge can be inferred from the facts provided. The new knowledge is mainly oriented towards solving the classification task and does not cover other types of inference. It is important to note that the data shapes fall out of the TBox as they serve the validation function, and are based on a different set of assumptions. Firstly, they are interpreted under the closed world assumption, like in XML or RDBM contexts (see Section 5.3). Secondly, they follow RDF graph based semantics 5.2.

Users of OWL [_52] can actually select between two slightly different semantics: direct semantics that corresponds to the Description Logics (DL) [_4], and RDF-based semantics which is based on translation of the OWL axioms into directed graphs. In this document we assume, by default, direct semantics. In particular cases (i.e. SPARQL entailments and SHACL data shapes) RDF-based semantics is adopted, and is explicitly mentioned in the document.

Description logics provide a concise language for OWL axioms and expressions. DLs are characterised by their expressive features. The description logic that supports all class expressions with >, ⊥, u, t, ¬, ∃ and ∀ is known as ALC (which originally used to be an abbreviation for Attribute Language with Complement). For a formal introduction into DL please consult [_4].

Inverse properties are not supported by ALC, and the DL we have introduced above is actually called ALCI (for ALC with inverses) [_44]. Many description logics can be defined by simply listing their supported features. The letter S is often used as an abbreviation for the “basic” DL consisting of ALC extended with transitive roles (which in the AL naming scheme would be called ALCR+ ).

The letter H represents sub-roles (role Hierarchies), "O" represents nominals (nOminals), "I" represents inverse roles (Inverse), "N" represent number restrictions (Number), and "Q" represent qualified number restrictions (Qualified). The integration of a concrete domain/datatype is indicated by appending its name in parenthesis, but sometimes a “generic” D is used to express that some concrete domain/datatype has been integrated. The DL corresponding to the OWL DL ontology language includes all of these constructors and is therefore called SHOIN (D). We will use this notation when discussing degrees of expressivity for the ontology layers in Section 5.4.

Computing all interesting logical conclusions of an OWL ontology can be a challenging problem, and reasoning is typically multi-exponential or even undecidable. To address this problem, the recent update of OWL 2 in the W3C standard [_55], [_52] introduced three profiles: OWL EL, OWL RL, and OWL QL. These lightweight sub-languages of OWL restrict the available modelling features to simplify reasoning. This has led to large improvements in performance and scalability, which has made the OWL 2 profiles very attractive for practitioners [_44].

On the other hand, the validation data shapes are expressed using Shapes Constraint Language (SHACL) [_43]. Its semantics is based on RDF graphs; full RDFS inferencing is not required. SHACL processors may operate on RDF graphs that include RDF entailments [_54] and SPARQL specific entailments [_51]. The entailment regime specifies conditions that address the fourth condition on extensions of basic graph pattern matching [_39], [_54].

This architecture delimits different concerns in Section 4.2 in a stack of layers and assigns levels of expressivity to each of the layers in Section 5.4.

In formal systems of logic used for knowledge representation, reasoning is the process through which logical conclusions are derived from a set of premises known to be true, or assumed to be true, by the laws of valid inference (inference rules).

In the eProcurement ontology checking consistency and deriving new knowledge is foreseen as valuable functionality beyond the establishment of knowledge representation and interoperability.

Inferencing is impacted by what is assumed about the knowledge base. The important assumptions to consider are: (a) whether the knowledge base is considered complete – the closed-world assumption (CWA); or (b) whether the knowledge base (proper knowledge base) is in a state of continuous progression – the open-world assumption (OWA) [_19].

Under the closed-world assumption it is presumed that a statement that is true is also known to be true. Therefore, conversely, what is not currently known to be true, is false <<_58>. The opposite of the closed-world assumption is the open-world assumption stating that lack of knowledge does not imply falsity. The truth value of a statement may be true irrespective of whether it is known to be true.

The eProcurement data is fragmented across information systems. It represents concerns specific to different steps in the procurement process. Performing local reasoning with such incomplete knowledge is therefore necessary functionality for the eProcurement project.

Semantic Web languages, including OWL, make the open-world assumption. The absence of a particular statement within the web means, in principle, that the statement has not been made explicitly yet, irrespective of whether it would be true or not, and irrespective of whether we believe that it would be true or not. This stance is also very convenient for decentralised knowledge bases over the internet, where information may be accessible, outdated, contradictory, inaccessible or missing [_19]. For validation purposes, in particular, a closed world assumption needs to be made.

This concerns the data shapes expressed in SHACL language. In this case, the knowledge base must be considered complete in order to assess whether it fulfils the imposed constraints or recommended shapes. Therefore, everything that is not known to be true must be considered as false.

The eProcurement data must be validated within its local context. The data conform to the information needs and aspects specific to the procurement phase and, possibly, to the information system that handles it. It is, therefore, foreseeable that multiple validation schemes and application profiles have to be developed specific to different phases and aspects of the procurement process. These schemes must extend and broaden the core ontology, which is the ontology backbone, with levels of specificity and detail as necessary.

In the layered approach described in Section 4.2, different expressivity levels are necessary for each layer. This section briefly describes these levels of expressivity and relate them to OWL sub-languages [_20] and profiles [_49].

Table 1 summarises the recommended sub-language for each component, gradually advancing from the lightest towards the more expressive ones. The last item, special inference rules, is mentioned, but falls out of the scope of the current specification. It may be considered in the ontology validation process (see Section 3.5) involving Semantic Web Rule Language (SWRL) expressions. SWRL [_40] is more expressive than OWL 2. It allows inequality and equality expressions (IE). Punning (PN) is included, which means that class terms can be used as properties. Language overview, and a few flavours of SWRL, are discussed in [_47].

The conceptual model must be expressed in UML. It is mostly scoped to class diagrams and corresponding elements, but additional ones may be employed, provided that there is a clear convention on their interpretation.

The core ontology must be expressed in the simplest OWL language - OWL Lite [_20]. [_20], Sec.8.3] describes the extent of the language in detail specifying what type of axioms are permitted and which are not. Anyway, this language is beyond the expressivity needs of this component, which are enumerated in Section 4.4.

The formal ontology restrictions are divided into four variants. Three variants must be generated for each of the OWL 2 sub-languages. The transformation rules that require more complex statements must be omitted when generating these (simpler) variants.

OWL 2 EL is a lightweight language with polynomial time reasoning, which guarantees very fast termination time.

OWL 2 QL is specifically designed for efficient database integration where the amount of instance data is very large.

OWL 2 RL is designed for compatibility with rule-based inference tools. An in-depth analysis of each dialect is available in [_44]. The complete set of restrictions should be expressed using OWL 2 language, which offers “maximum” expressivity while keeping reasoning problems decidable, but still very expensive. The reason these variants are mentioned, is that reasoning configuration for eProcurement is still difficult to decide, as was explained in Section 4.6. Each variant must be generated from the UML model, of course, limited to the level of detail available in the UML model, and to the expressivity of each sub-language indicated in Table 1.

Data shapes must be expressed in SHACL language. No particular restrictions apply to this component as the SHACL engines are known to perform in polynomial time.

There is a five-star rating system[_6] to measure published data reusability. This rating system is based on four design principles proposed in [_5], to which eProcurement ontology subscribes.

Moreover, the eProcurement URI scheme must subscribe to the “Cool URIs” recommendations [_17] and ensure that they don’t change [_11].

The ISA² study on persistent URIs [_2] provides a set of design and management principles. They are completed by a more recent study on URI design patterns [_21], in the context of promoting semantic interoperability, identified good design practices for the local part of URIs under the http://data.europa.eu domain (see Section 6.2).

In 2014, the ISA Programme supported an informal Task Force working on a common policy for the management of persistent, HTTP-based URIs of EU institutions comparable to the virtues of DOI identification scheme[_22]. A Persistent URI Service on the http://data.europa.eu sub-domain was established that is responsible for the registration and management of persistent URI namespaces and the forwarding of HTTP requests (URI redirection) towards the Publications Office local register for the eProcurement ontology (see Section 6.3).

The Publications Office was allocated http://data.europa.eu/a4g URI namespaces for usage in the context of eProcurement ontology. Section 6.3 provides the specifications on the URI structure and the local part organisation.

Regarding URI design, the main consideration of creators should be that when a URI is created, all its parts should be resistant to change. For instance, locations and organisation names can change, and therefore should not be used in URIs. First and foremost, when introducing semantics in URIs, the strings used need to reflect what the resources are (i.e. intrinsic characteristics such as the type or nature), not who owns them or where they are [_21].

When creating a URI, its owner can never be certain of who will be using it and can therefore not notify every concerned individual of future changes. It is therefore paramount that URIs are designed carefully with the specific goal of making them persistent, in theory forever [_11]. Persistence is a vital component of URI design. Since the local part of a URI is under the control of the institution that owns it (in this case Publications Office), it is up to the owners to ensure that the way they design local IDs enables the persistence of the URI as a whole.

It is recommended to identify all eProcurement resources with URIs which have opaque local identifiers. However, in the case of TBox resources, such as the ontology and the data shapes, mnemonic local segments may be used.

The URIs are best maintained using a predefined set of patterns and templates. This section defines the URI templates that, together, form a URI scheme.

A simple syntax is adopted to express the scheme templates in terms of URI path patterns. A path pattern comprises a sequence of delimited segments, such as segment1/segment2/segment3. Each advancement by a segment leads to creation of a new hierarchically positioned namespace.

The segment denomination can be literal or variable. The literal segment means that the value provided is constant and must appear as such in the indicated position.

The variable segments are marked by curly brackets ( { } ) and represent the name of the slot which must be filled with a concrete value when a new URI is minted in the implementation process. For example, the pattern segment/{varSegment} can be instantiated as segment/123.

It is possible to indicate that a path sub-sequence is optional by wrapping it in square brackets ( [ ] ). For example segment/[{varSubSegment\}]varSubSubSegment pattern can be instantiated either as segment/abc/123 or segment/123.

This section defines templates for two dedicated PURI (Persistent Uniform Identifier) namespaces corresponding roughly to TBox–ABox distinction in the ontology structure, or the model–data delimitation, which is explained in Section 5.1. The first namespace, baseVoc, is dedicated to the ontology vocabulary and modelling artefacts; while the second, baseData, is foreseen to accommodate the large volume of instance data.

The instance datasets are generated by a range of institutions. Therefore, each agent should be delegated minting URIs in a controlled and conflict free manner. One way to do that is to allocate dedicated base PURI spaces.

Table 2: Base PURIs employed by the eProcurement ontology

For the purpose of eProcurement ontology eight scopes have been identified and each is ascribed a path segment in order to form a separate namespace. They are as follows: ontology (/ontology), controlled list (/reference), data shapes (/shape), reasoning restrictions (/rule), XML schemas (/schema), instance data (/resource), metadata descriptions (/metadata), and data services (/service).

Ontology core

The ontology documents and content should be situated under the "/ontology" path segment. Three patterns are of relevance here: to refer to the root of the ontology content space, provided as xml:base / xmlns; (b) to refer to the document of the ontology or fragment/module, the subject of the ontology header; and (c) one to refer to each resource defined within the ontology, such as classes, properties and special individuals. Table 3 defines the patterns.

Table 3: URI patterns for the ontology namespace

Controlled list

The controlled list should replicate the current approach taken by Publications Office for reference data as described in Table 4. Optionally the controlled lists may be managed entirely by the Standardisation and Metadata Unit, including publishing them in the established namespace for reference data.

http://publications.europa.eu/resource/authority.

Table 4: URI patterns for the reference data namespace

In order to keep maintainability of PURIs (Persistent Uniform Identifier)high and fenced off from the risk of agencies clashing to maintain a common PURI, new base namespaces can be requested from the PURI committee. This risk is particularly high for controlled lists and should be carefully considered at conception.

Data shapes

The data shape files should be situated in the "/shape" space. The data shapes are extending the core ontology and are intrinsically bound to it. Therefore, the ontology name must be used in the content root. Table 5 defines the patterns.

Table 5: URI patterns for the data shape namespace

Ontology restrictions

The restrictions are in fact part of the ontology definition, simply corresponding to the more complex part of it. Therefore, the restrictions belong in the same namespace as the ontology. The document reference, however, can be distinguished and placed in the /rule namespace, where, eventually SWRL [_40] and other types of reasoning related artefacts may be placed. Table 6 reflects these patterns.

Table 6: URI patterns for the restrictions namespace

XML schema

In eProcurement domain, usage of XML data is a de facto approach at the moment. In order to support current practices and help establish a technological change, a space for managing XML schemas id designed within the same PURI (Persistent Uniform Identifier) space must be created. Schemas namespaces can be minted using a baseVoc/schema/schemaName pattern.

Table 7: URI patterns for the instance data namespace

Instance data

Concrete eProcurement data instantiating the eProcurement and related ontologies must be minted in the "/resource" namespace. The data files are best conceptualised as datasets, bulks or fragments. Therefore, the possibility to organise a dataset as a set of fragments as described in the VOID specification [_18] has been anticipated. Table 7 reflects these patterns.

Metadata Data catalogues and work descriptions should be organised and well described using the established standards such as DCAT [_66], VOID [_18], Dublin Core [_46] or other representations such as FRBR [_50] and the CDM [_36], [_35]]. The metadata resources must be minted in the "/metadata" namespace following the patterns provided in Table 8.

Table 8: URI patterns for the metadata resources namespace

Services

It is very important to provide endpoints where the data are accessible. These endpoints can be identified through URIs as well combined with a 303 HTTP redirection [_33] to resolve the URI to the current URL where the service is accessible. Service URIs should be minted in the "/service" namespace as described in Table 9.

Table 9: URI patterns for the namespace of the services