1. e-procurement ontology workshop
Third Working Group Meeting
24 May 2017

2. Agenda for the third WG meeting
Round table
Introduction and objectives of this meeting
D02.01 Specification of the process and methodology
Conceptual data model
Comments addressed
D02.02 Project Charter
List of use cases identified
Next steps

3. Round table

4. Introduction and objectives of this meeting

5. Introduction and objectives of this meeting
Agree on the different propositions for:
The conceptual data model
The comments addressed in the specification
The comments addressed in the Project Charter
The list of use cases identified
Decide on next steps and planning

6. D02.01 Specification and final conceptual data model

7. Current status of the document
Final draft including:
An updated conceptual data model
Addressed comments from GitHub and on the document itself
18 issues raised on GitHub related to the content of the document:
Conceptual Data Model
Mapping of the Conceptual Data Model entities

9. Conceptual Data Model | Issues and propositions
Link: /issues/3
Description: the Directive 2014/23/EU relates to Contracting authorities and Contracting entities. There needs to be a definition that cites contracting authorities and Contracting entities.
Current situation under discussion: There is now a class Buyer with subclasses Contracting Authority, Public Undertaking and Other Contracting Entity (as per Directive 2014/23/EU, art. 7.1).
Further comments available on GitHub.

10. Conceptual Data Model | Issues and propositions
Link: /issues/4
Description: the 'is bound to' relationship between a Contract and an Economic Operator and a Contracting Authority is difficult to understand.
Current situation under discussion : the relationship ‘is bound to’ has been replaced by relationships of Contract:
Contract 'is contracted by' Buyer
Contract 'is contracted to' Economic Operator

11. Conceptual Data Model | Issues and propositions
Link: /issues/6
Description: the different roles of Contracting Authority need to be modelled. Fore example, a CA can publish and award tenders for its own purchases of goods and services or for the execution of works but it can also act as Central Purchasing Body, awarding contracts that can be used by other public administrations.
Current situation under discussion : There is now a distinction between the Buyer, the entity that enters into the Contract and the 'Procuring Entity', the entity that publishes the Call For Tender.
Further comments available on GitHub.

12. Conceptual Data Model | Issues and propositions
Link: /issues/5
Description: the definition of ‘Payment’ was misleading as it was not concerned by a relation between a 'Tender' (domain) and a 'Call For Tender' (range).
Current situation under discussion : the relationship ‘responds To’ has been replaced by ‘is payment for’
Payment 'is payment for' Invoice

13. Conceptual Data Model | Issues and propositions
Link: /issues/7
Description: The call for tender should be detailed in order to distinguish between first and second phase of negotiation (i.e. a contract based on a framework agreements and specific contract based on a dynamic purchasing system.
Current situation under discussion : the definition of Call For Tender contains a sentence: “Depending on further use cases, it may be necessary to distinguish between Framework Agreements and Specific Contracts.”

14. Conceptual Data Model | Issues and propositions
Link: /issues/14
Description: the definitions (and domains and ranges) of relationships and properties limit the use to only one specific situation.
Current situation under discussion : the suggestion to make the domain and ranges more general has been taken into account. The changes in the conceptual model are marked “Comments JH”.

15. Conceptual Data Model | Issues and propositions
Link: /issues/20
Description: currently, the relationship between Contract Award Notice and Economic Operator is indirect:
Contract Award Notice 'awards' Tender
Tender 'is submitted by' Economic Operator
Current situation under discussion : Should the model foresee a direct relationship between Economic Operator and Contract Award Notice?

16. Conceptual Data Model | Issues and propositions
Link: /issues/21
Description: What should be the primary source of definitions?
The methodology states: "In the e-procurement ontology, definitions should to the extent possible come from legislation, such as the e-procurement and e-invoicing directives. If legislation does not provide suitable definitions, definitions from established business vocabularies such as UBL or XBRL should be used."
Current situation under discussion : create definitions at a  general level that respects legislation, so that they can be applied also below-threshold.

17. Conceptual Data Model | Issues and propositions
Link: /issues/24
Description: the notion of class “Lot" is important and often implicit. It does not appear under “Call For Tender", it's a 1..n cardinality and many classes will fall under each “Lot" like “Tender" and “Contract". Also one “Lot" can have several “Contracts" (cascade).
Current situation under discussion : The definition of Call For Tender includes the sentence: “The relationship between Call For Tender and Lots needs to be further detailed.”

18. Conceptual Data Model | Issues and propositions
Link: /issues/25
Description: What represents the “Value" class? The total amount of an invoice? This level of detail is probably sufficient in this first phase, but the ultimate goal is to provide transparency up to the lowest level of detail.
Current situation under discussion : The definition of Invoice includes the sentence: “Note: it may be necessary to define smaller parts of Invoices in cases where an invoice contains ‘invoice lines’ related to specific items.”

19. Conceptual Data Model | Issues and propositions
Link: /issues/26
Description: the related classes of ‘Order’ and ‘Delivery Note’ are also missing.
Proposed resolution: these additional classes should be further defined by the Working Group.

20. Conceptual Data Model | Issues and propositions
Link: /issues/27
Description: several groups of ‘Contracting Authority’ should be expressed: ‘Joint Call For Tender’, ‘in The Name Of’ (or ‘on Behalf Of’) and ‘Central Purchasing Body’
Proposed resolution: There is now a distinction between the Procuring Entity (which could be a Central Purchasing Body) and the Buyer. If the situation can occur that the Call For Tender is published by more than one organisation, there may need to be a 1..n relationship between Call For Tender and Procuring Entity, or a particular type of Procuring Entity might be a grouping of organisations.
This issue needs to be further discussed in the Working Group.

21. Conceptual Data Model | Issues and propositions
Link: /issues/28
Description: class ‘Evidence': what does it mean? some proving metadata about the ‘Payment'? so it should be linked to class ‘Payment', not ‘Contracting Authority'
Proposed resolution: this is resolved by the revised model. The Payment now has a relationship ‘is evidenced by’ an Evidence.

22. Conceptual Data Model | Issues and propositions
Link: /issues/29
Description: there are many types of notices, ‘Contract Award Notice' is not a standalone class: a class ‘Notice' would probably be needed with sub classes ‘Award', ‘Contract', ‘Prior', etc.
Proposed resolution: if there is a set of properties that apply to all those ‘notices’, there could be a superclass for it. However, it needs to be determined what the role of such a superclass is in the model.
This can be discussed by the Working Group.

23. Conceptual Data Model | Issues and propositions
Link: /issues/30
Description: What is the difference between 'procurement criterion' and 'tendering terms (UBL)'? Are the first computable metadata and the second textual description about what is requested in the 'call for tender'?
Current situation under discussion : there is no direct correspondence between the Procurement Criterion and UBL. The UBL Tendering Terms combine ‘computable’ conditions (e.g. for Quantities, Codes and Indicators) and textual descriptions. Procurement Criterion may also include both types of criteria.

24. Conceptual Data Model | Issues and propositions
Link: /issues/31
Description: useful code lists could already appear based on the use cases: CPV (+supplementary code), NUTS, contract type, procedure type, country, … Code lists can have 1..n cardinality and should be identified as enumeration pseudo-classes.
Current situation under discussion : the specification should mention CPV as the preferred controlled vocabulary for Classification and NUTS for Country.
Please note that the current modelling does not use 'code lists' in the sense of short strings like ISO country codes, CPV codes or NUTS codes, but works from the principle that the things that the codes stand for are identified by URIs.

25. Conceptual Data Model | Issues and propositions
Link: /issues/32
Description: in the detailed textual descriptions of the classes, properties and relationships, it could be more efficient
to propose the best found description (instead of leaving it in blank);
also to mention all synonyms; and
flag in which use cases they are used. Many "foreseen/probable" properties could be added and evaluated later if no use cases refers to them.
Proposed resolution:
the latest model includes proposed definitions for all classes and properties
synonyms can be added as soon as the definitions have been agreed
a cross-reference among requirements, model elements and use cases is already available in Table 6

26. Conceptual Data Model | Issues and propositions
Link: /issues/39 and /issues/40
Current situation under discussion : currently, there is no direct relationship between Call for Tender and Contract Award Notice and Buyer
Should the model foresee such direct relationships? E.g.
Call For Tender 'is procured for' Buyer and
Contract Award Notice 'is procured for' Buyer
Should the model foresee both Procuring Entity and Buyer?

27. Mapping of the Conceptual Data entities
OWL file created and available.
As mentioned in the Project Charter, it can be opened with Protégé.
Domains, ranges, cardinalities have not been included in the OWL file but will be inserted in the next phase.

28. Questions ?

29. D02.02 Project Charter

30. Current status of the document
Final draft including the comments from GitHub
16 issues raised on GitHub related to the content of the document:
1 on the Cost, Timing and Milestones
15 on the use cases to be developed

31. Comments addressed
Link: /issues/19
Description: A more granular approach to milestones should be taken i.e. so many use cases or concepts to be treated in a given amount of time.
Proposed resolution: in Table 6, a column was added with indicative activities for the different working group meetings during the next phase.

32. List of use cases to be developed
e-tendering process: /issues/8
Analysing e-procurement procedures, /issues/11
Increase cross-domain interoperability in terms of (financial) exclusion grounds among Member States, /issues/13
Public understandability (Use case to be derived from interviews with transparency watchdogs and similar stakeholders)
Monitor the money flow, /issues/9

33. List of use cases to be developed
Detect fraud and compliance with procurement criteria, /issues/42
Alerting services, /issues/10
Introduce automated classification systems in public procurement (not a real use case but a set of ideas for classification systems to be gathered)
Businesses need to participate in procurement, /issues/35

34. List of use cases to be developed
Buyers need to buy things, which means following the e- procurement phases, /issues/36. This use case includes (and therefore could be broken down into other use cases at a lower granular level):
Creating new information (e.g. description of the procurement, giving points for award criteria).
Reusing information from different databases and domains, such as
business registries (to reduce administrative burden and ensure consistency of information); and
tax, social payments, etc. systems (to verify that potential contractors meet selection criteria).
(Sending information to other systems to ensure transparency etc. requirements are met, e.g. contract registers).

35. List of use cases to be developed
Other public entities are directly involved in the e-procurement phases, /issues/37. This use case includes (and therefore could be broken down into other use cases at a lower granular level):
Creating new information (e.g. review authority freezing the procurement process, rejecting a complaint, or awarding damages).
Exchanging data between e-procurement systems and systems used by auditors and review bodies, so that it is easier for them to check the validity of the procurement process.

36. List of use cases to be developed
Regulators (ministries, review bodies, etc.), citizens, journalists, NGOs, academics, buyers, etc. use the data to answer policy- relevant questions, /issues/38. This use case includes (and therefore could be broken down into other use cases at a lower granular level):
Accessing information created by the use cases above.
Accessing information created specifically to be used only in this use case.
Connecting this information with other information, in particular:
budget systems (to answer questions linked to following the money). (Note: e-invoicing is not included in this section, because it falls within the scope of "e-procurement phases described in the Project Charter", i.e. the first use cases in this list.); and
contract registers (to allow answering more sophisticated questions, e.g. linked to the full text of contracts).

37. List of use cases to be developed
Analyse the success rate of the procurement process and the reasons for failure, as well as estimate the costs associated, /issues/33
Long term analysis about the evolution of procurement activities in the EU Institutions, /issues/34
Providing information for Contract Registries, /issues/22
Enable the publication of notices as linked open data to enable the exploitation of the corresponding data through the semantic web in ways yet to be envisaged, /issues/23

38. Questions ?

39. Next steps

40. Next steps Today Third Meeting of the Working Group
Mid-June (finalising this phase)
Update of D02.01 with references to Github issues to be further addressed in the next phase of the project
Update of D02.02: project charter. Does the working group agree with increasing the editor’s role?
Over summer
Editor & chair propose a list of definitions for all classes and properties in the ontology. Input from the Working Group can be provided via Github.
Working Group & editor elaborate on the use cases Who can we contact?
September 2017 – June 2018
Development of the ontology

41. Questions ?

42. e-Procurement Ontology
Join the e-Procurement Community
Contact us: