Patrizia Cannuli would like to propose a use case on behalf of Consip on the topic written below. They are working on the use case in order to submit something to the working group.

Do you have any comment regarding this proposition?

Patrizia Cannuli proposed the following issue on behalf of Consip:
"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 provided for in Article 33 of Directive 2014/24/EU and specific contract based on a dynamic purchasing system as provided for in Article 34 of that Directive). The framework agreements are awarded by Central Purchasing Body while specific contracts are awarded by other Contracting Authorities."

How should we handle this distinction? What relationships should be created or removed?

Jáchym Hercher submitted the following use case to be further developed:
Businesses need to participate in procurement, i.e. follow the e-procurement phases described in the Project Charter (e.g. search opportunities and automatically receive suggestions; send expressions of interests, request to participate, tenders, tenders within mini-tenders, complaints, signed contracts; receive calls for tender in two-stage procedures, call-offs, information on whether they have been awarded a contract and how many points they received in the evaluation etc. etc.).

1. Relating to providing information for Contract Registries
   2 A general use case too 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.

Claude Schmit proposed that 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.

Claude Schmit proposed a new use case:

In the special report "The EU Institutions can do more to facilitate access to their public procurement" in 2016, the Court of Auditors (ECA) made the recommendation n°7 : "To allow effective ex post monitoring of their procurement activities, the EU institutions should set up a single public repository of information related to their procurement contracts". A use case about an auditor doing a long term analysis about the evolution of procurement activities in the EU Institutions could be developed.

During the third working group meeting, it was explained that a Payment could be made to other parties than Economic Operator. Consequently, which relations should the Class Payment have except the existing relations with Buyer, Economic Operator, Evidence and Monetary Value?

This issue is related to issue 28 for which the latest version of the conceptual data model included a realtionship between Evidence and Payment.

In the second working group meeting, a new use case was proposed: "Detect fraud and compliance with procurement criteria" (i.e. use case 1.4 in the landscaping document)

This issue will group the input received regarding this use case. Please share your input below.

Claude Schmit proposed the creation of a new class "Lot".
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).

Claude Schmit raised the issue that several groups of "contracting authority" should be expressed : "joint call for tender", "in the name of" (or "on behalf of") and "central purchasing body".

I have a clarifying question on the scope of the ontology: does the ontology aim to cover all data necessary for meeting the use cases, or just published (=publicly available) data?

I've always assumed the former, e.g. because one of the problems the ontology is supposed to solve is
"the relations between the different concepts in the procurement chain and data flow are not fully documented, therefore data and data relationships cannot be reused directly in a flexible and comparable manner;". (Quoting from https://joinup.ec.europa.eu/asset/eprocurementontology/document/report-policy-support-e-procurement).

However, the same document also states that "This creates the need for a common data standard for publishing procurement data, hence allowing data from different sources to be easily accessed and linked, and consequently reused. The e-Procurement ontology (henceforth referred to as the ePO) introduced by this study aspires to play this role.", which to me sounds more like only published data

In the third working group meeting, it was discussed whether the class Catalogue Request from UBL should be considered in the ontology as a generalisation of tendering terms for specific call for tenders.

This issue is related to issue 30:

@claudeschmit:

asked about the difference between "procurement criterion" and "tendering terms (UBL)"

and

@makxdekkers:

replied that there is no direct correspondence between the Procurement Criterion here 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.
The UBL definitions could be taken into account when further detailing the Procurement Criteria.

Template for the tables:

To be removed if not relevant for your issue. Please remove the columns/rows that are not needed and use the "Preview" tab above to see your changes.

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

Comment from JH: "Definitions may vary above and below threshold. We need to try to make definitions, for example, more general than in the directives, so that they can be applied also for below-threshold!"

Jáchym Hercher submitted the following use case to be further developed:
Regulators (ministries, review bodies, etc.), citizens, journalists, NGOs, academics, buyers, etc. use the data to answer policy-relevant questions. This includes

1. Accessing information created by other use cases such as 'Businesses need to participate in procurement', 'Buyers need to buy things' or 'Other public entities are directly involved in the e-procurement phases described in the Project Charter'.
2. Accessing information created specifically to be used only in this use case.
3. 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 use cases related to 'Businesses need to participate in procurement'.)
   - contract registers (to allow answering more sophisticated questions, e.g. linked to the full text of contracts).

A more granular approach to milestones should be taken ie so many use cases or concepts to be treated in a given amount of time.

Question to the working group: should the model foresee a relationship between Economic Operator and Contract Award Notice?

From JH: "Isn't the "number of times a contract notice has been read" a very important indicator for knowing where is the problem with attracting bidders? ("People do not know we are running tenders!" vs. "People know we are buying, they read the notice, but then decide not to apply, because our selection criteria are too strict!"

The relationship is difficult to understand

I would like to propose 2 new Use Cases :

• A data journalist wants to analyse the success rate of the procurement process and the reasons for failure, as well as estimate the costs associated. He wants to discover any recurrent patterns based on various dimensions (country, type of procurement, value of contract, cause of failure, number of recours, …). He needs to easily identify several calls for tender related to the same business opportunity.

• In the special report "The EU Institutions can do more to facilitate access to their public procurement" in 2016, the Court of Auditors (ECA) made the recommendation n°7 : "To allow effective ex post monitoring of their procurement activities, the EU institutions should set up a single public repository of information related to their procurement contracts". A use case about an auditor doing a long term analysis about the evolution of procurement activities in the EU Institutions could be developed.

Claude Schmit, Publications Office

The second use case described in the document 'D02.01 Specification of the process and methodology' about an automated matchmaking of procured services and products with businesses has similarities with the LOD 2 work package as identified by @JachymHercher in the commented version of the specification available in the issue #14 .

How should the relationship between the two sources of information be considered and how should it influence the use case 2?

The instructions file appears to be in Microsoft Word format.

When I try to open it on a Mac it looks like this.

If I use LibreOffice, I get a warning about embedded macros.

Would it be possible to get this converted to an Open Format? Ideally HTML / markdown, or perhaps ODT?

Improvement of an existing concept

Current Definition:

A process where the time limit for receipt of tenders can be reduced due to a state of urgency.

New Definition:

A procurement procedure where the time limit for receipt of tenders can be reduced due to a state of urgency or some administrative steps of the tendering procedure can be skipped due to a state of emergency.

Reason:

The current definition is incomplete: The proposed definition covers the two cases for which the procedure can be accelerated: urgency and emergency.

Natalie Muric proposed to develop a general use case on 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.

A contract award notice does not award a tender. It announces the award of a contract.

Claude Schmit said that there are many types of notices, "contract award notice" is not a standalone class : probably we need a class "notice" with sub classes "award", "contract", "prior", …

|Element|Description|
|---|---||Title|A short phrase that can be used to refer to the use case|
|Category|The type of use case; one of: 1. Transparency and monitoring 2. Innovation & value added services 3. Interconnection of public procurement systems|
|Actors|Further details on the agents (persons, organisations or software programs) involved in the use case|
|Final recipients|The actors that receive the results or benefits from the use case|
|Preconditions|Anything that can be said about the situation before the use case begins|
|Flow|A step-by-step description of the actions taken and responses received by the user|
|Comments|Any other observation related to the use case|
Public understandability

Patrizia Cannuli proposed the following issue on behalf of Consip:
"We suggest to extend the Use Cases, adding new class, properties and relationship, to detail the different roles of Contracting Authority. In fact, 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 (CA)."

How should we integrate Central Purchasing Body and are there other roles that should be taken into account?

Patrizia Cannuli would like to propose a use case on behalf of Consip. It would be based on the use case 1.3 "Monitor the money flow" from the Landscaping report. They would like to analyse deeper this use case in the short-term.

Description from the Landscaping report:
In order to obtain an exhaustive and unified view of the flow of public money, from tax collection and budget over to procurement until spending, e-Procurement data should be integrated with other datasets such as budget, spending and location data. A common ontology such as the ePO is necessary in order to interlink such datasets, and help with the creation of a unified view over the flow of public money.
Example:
A procurement watchdog is analysing the flow of public money during an interval of two years. Using the ePO as the common model for representing data, allows the watchdog to find their way through the different sources that have to be consulted, e.g. budget dataset, calls for tender and procurement notices, and to interlink the data in order to identify the trails. Examples of the data to be interlinked by the watchdog, in order to discover the flow of money could be:

• the value of the contract;
• the name of the awarded tender;
• the location of the awarded tender; and
• the department of the public administration that awarded the tender.

• Of the ePO to model all procurement process data e.g. calls for tenders, notices etc.;
• Of the ePO to model economic operator data e.g. name, location etc.;
• Of the ePO to model contract data e.g. contract value;
• Of the ePO to model exclusion criteria etc.;
• Of the ePO to link to other datasets e.g. budget datasets, spending datasets, tax information datasets.

Do you have any reactions regarding this proposition?

Claude Schmit said that the related classes of "order" and "delivery note" are missing.

I would like to submit a few comments on the conceptual data model :

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

• 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. For instance, the notion of "invoice line" does not exist. There is always a "price schedule" per "contract" which can be complex. An invoice always regroups 1..n "line" x quantity based on the price schedule.

• The related classes of "order" and "delivery note" are also missing.

• Several groups of "contracting authority" should be expressed : "joint call for tender", "in the name of" (or "on behalf of") and "central purchasing body"

• Class "evidence" : what does it mean ? some proving metadata about the "payment" ? so it should be linked to class "payment", not "contracting authority"

• There are many types of notices, "contract award notice" is not a standalone class : probably we need a class "notice" with sub classes "award", "contract", "prior", …

• 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" ?

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

• In the detailed textual descriptions of the classes, properties and relationships, it could be more efficient 1) to propose the best found description (instead of leaving it in blank); 2) also to mention all synonyms; and 3) 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.

Claude Schmit, Publications Office

Jáchym Hercher submitted the following use case to be further developed:
Other public entities are directly involved in the e-procurement phases described in the Project Charter. This includes:

1. Creating new information (e.g. review authority freezing the procurement process, rejecting a complaint, or awarding damages).
2. 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.

I have read the document "D04.07 Report on policy support for e-Procurement" and the use cases currently listed in the wiki as pilots. Thanks a lot for preparing and sharing all of this and please find some comments below.

In my opinion, the current 12 use cases are hard to use for the intended purpose, mainly because they are not clear enough, they are not on the same level of generality, and they are nor mutually exclusive nor collective exhaustive. This makes it very hard to identify what is covered and what needs to be added. Please find examples of problems below:

1. [Overlap]: Use case 2.4. ("Data analytics") covers all analysis of data. This encompasses many other use cases: in particular 1.2., 1.3., 1.4., 1.5. (This is even reflected in the description of the 2.4. use cases, which lists all other users and use cases: "In the field of e-Procurement, applying data analytics could be advantageous for economic operators, contacting authorities and external parties such as journalists and watchdogs.")

2. [Overlap]: Use cases 1.2 ("Data journalism") cover also use case 1.3 ("Monitor the money flow") as well as 1.4. ("Detect fraud and compliance with procurement criteria") – essentially every article on public procurement monitors the money flow (e.g. http://www.economist.com/news/europe/21710315-government-contracting-growing-less-competitive-and-often-more-corrupt-rigging-bids) or is about some sort of fraud.

   Reading the description, the main point of this use case seems to be that the scope of the ontology should cover "other datasets such as budget, spending and location data". I agree, but this should be in the scope section, not the use case section.

   (This points to a general shortcoming of the scope section so far, which is that it describes the "length" of the process (from "identify needs" to "e-payment") but not it's breadth (e.g. planning or payment sections of the process should perhaps also include links to data on budget; the sections on e-awarding and contracting should contain information about complaints and resolutions by remedy bodies; etc.)

3. [Overlap]: Use case 2.1 "Automated matchmaking of procured services and products with businesses" is about "matching the products and services of economic operators to the needs of contracting authorities"; while use case 2.3 "Alerting services" is about "Through the use of alerting services, economic operators are informed about published call for tenders that match their profile". Re-reading the descriptions multiple times, I can't find a difference between these two.

   (Note that there are of course different aspects of it, e.g. matching products (e.g. classification of products) vs. matching companies (e.g. necessary minimal turnover). However, these seem to be just different sides of the same use case and I don't see such a distinction being made in the current distinctions anyway.)

4. [Clarity]: Reading use case 1.1 ("Public understandability") several times, I think it is about joining data across platforms, so that it can be presented more simply for non-sophisticated users. If this is the case, then the first part of this use case ("allow providers of procurement data to link their data") is covered also by several other use cases, e.g. 3.1.; while I do not think the second part of the use case ("make [data] available in ways which will be easier for the non-technical consumer to interpret and reuse") is a use case for the ontology as such, because having a nice website is possible over a small pile of local data as well as a big pile of interconnected data. Generally speaking, the use cases should be described much more simply, without repetitions.

For these types of reasons, I found it very hard to identify gaps in the 12 use cases and propose additional ones. As one approach, I tried writing my own "use cases" – see the result below. This could be used to cross-check whether the current use cases cover everything that is needed, or not. (Since I wrote it down off the top of my head just now, I'm sure there are mistakes and omissions. However, I do think they are at least mutually exclusive, collective exhaustive, and, hopefully, understandable.)

Use cases:

1. Businesses need to participate in procurement, i.e. follow the e-procurement phases described in the Project Charter (e.g. search opportunities and automatically receive suggestions; send expressions of interests, request to participate, tenders, tenders within mini-tenders, complaints, signed contracts; receive calls for tender in two-stage procedures, call-offs, information on whether they have been awarded a contract and how many points they received in the evaluation etc. etc.).

2. Buyers need to buy things, which means following the e-procurement phases described in the Project Charter (e.g. publishing notices, sending information about who won a contract, signing contracts, drafting and archiving individual procurement reports in the sense of 2014/24/EU Art. 84 etc. etc.). This includes:

   1. Creating new information (e.g. description of the procurement, giving points for award criteria).
   2. Reusing information from different databases and domains, such as
      1. business registries (to reduce administrative burden and ensure consistency of information);
      2. tax, social payments, etc. systems (to verify that potential contractors meet selection criteria).
   3. (Sending information to other systems to ensure transparency etc. requirements are met, e.g. contract registers).

3. Other public entities are directly involved in the e-procurement phases described in the Project Charter. This includes:

   1. Creating new information (e.g. review authority freezing the procurement process, rejecting a complaint, or awarding damages).
   2. 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.

4. Regulators (ministries, review bodies, etc.), citizens, journalists, NGOs, academics, buyers, etc. use the data to answer policy-relevant questions. This includes

   1. Accessing information created by the use cases above.
   2. Accessing information created specifically to be used only in this use case.
   3. Connecting this information with other information, in particular:
      1. 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.)
      2. contract registers (to allow answering more sophisticated questions, e.g. linked to the full text of contracts).

(Unnecessary reminder: all the use cases above apply both within-country contexts and cross-country contexts. For example, opportunities are searched on the whole EU single market; the once only principle works across Member States; foreign companies participating in local public procurement may be audited by local auditors and complain to local review bodies; questions may be asked on benchmarking procurement performance across authorities in individual countries.)

Drafting the list above opened two more questions for me:

1. What level of generality should use cases have? In the use cases proposed right now, each use case is at a different level of generality, which creates confusion. In my list above, different approaches could be taken – e.g. use cases could be based on the top level, mid-level, or low level bullets; or also include the examples given in parentheses.

2. How will information requirements be specified on the basis of the use cases? In particular, will the ontology team go find and speak with authorities, companies, data journalists, and policy makers? Or will just secondary sources be used (existing legislation and systems; popular and academic articles and reports that used procurement data)? Or do we draft on their behalf and then hope they will correct us during the review phase?

   If the plan is to speak with the actual authors, we can help by providing various contacts. The same goes also for secondary sources to be examined.

Patrizia Cannuli would like to propose a use case on behalf of Consip. It would be based on the use case 2.3 "Alerting services" from the Landscaping report. They would like to analyse deeper this use case in the short-term.

Description from the Landscaping report:
Contracting authorities announce and publish the calls for tender to economic operators, citizens and third parties. Through the use of alerting services, economic operators are informed about published call for tenders that match their profile. In order to automate alerting services, e-Procurement data such as tenders and information about economic operators should be machine processable, so they can be integrated, matched, and the right data should be delivered to the right person (depending on their subscription to the alerting services).
Example:
A Spanish public administration procures stationery and textbooks for the forthcoming year. The public administration publishes the call for tenders on an online platform. Since the call for tenders is published in a machine-readable format, following the structure of the ePO, third-party applications can process the call for tender and send alerts to interested parties who are subscribed in their client bases. Usually, such third party applications offer their clients the ability to define criteria for which they want to be automatically alerted.
Information requirements:
In this case it would be required:

• Of the ePO to model the calls for tenders and the details within it.

Do you have any reactions regarding this proposition?

Claude Schmit asked about 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" ?

Template for the tables:

To be removed if not relevant for your issue. Please remove the columns/rows that are not needed and use the "Preview" tab above to see your changes.

Should there be a direct relationship between the Contract Award Notice and the Buyer, given that there already is a direct relationship with Procuring Entity? How do we define that relationship?

The directive 23 relates to Contracting authorities and Contracting entities. There needs to be a definition that cites contracting authorities and Contracting entities. Suggestions have been made to use the term by "buyer" or "Contracting body". However it is not necessarily as simple as that as a contracting authority is not equal to a contracting entity as although they are both buyers they buy different things.

This issue follows up on the side discussion of issue #20, i.e. whether the ontology should be resource-oriented or event-oriented.

Summarising the earlier discussion:
@JachymHercher:

Isn't the "number of times a contract notice has been read" a very important indicator for knowing where is the problem with attracting bidders? ("People do not know we are running tenders!" vs. "People know we are buying, they read the notice, but then decide not to apply, because our selection criteria are too strict!"

@makxdekkers:

The fact that an Economic Operator 'opens' Contract Award Notice is a process transaction not a property of the data

@JachymHercher:

This is a very interesting point and I would be grateful for a deeper clarification. My thinking is: 1) someone opening a contract notice is part of the eNotification phase of procurement; 2) this information can be stored as data (about the use of a website on public procurement); 3) this information can be used to answer a policy relevant question from public procurement (see the first post). Thus, I would think it should be covered in the ontology.
If it shouldn't be covered, then this should be clear from the scope section of the ontology document. I think it currently isn't?

Claude Schmit said that in the detailed textual descriptions of the classes, properties and relationships, it could be more efficient:

1. to propose the best found description (instead of leaving it in blank);
2. also to mention all synonyms; and
3. 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.

Claude Schmit asked 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. For instance, the notion of "invoice line" does not exist. There is always a "price schedule" per "contract" which can be complex. An invoice always regroups 1..n "line" x quantity based on the price schedule.

The link to the conceptual data model is broken (doesn't work).

Template for the tables:

To be removed if not relevant for your issue. Please remove the columns/rows that are not needed and use the "Preview" tab above to see your changes.

Claude Schmit proposed a new use case:

"A data journalist wants to analyse the success rate of the procurement process and the reasons for failure, as well as estimate the costs associated. He wants to discover any recurrent patterns based on various dimensions (country, type of procurement, value of contract, cause of failure, number of recours, …). He needs to easily identify several calls for tender related to the same business opportunity."

Natalie Muric proposed to develop a use case on "Relating to providing information for Contract Registries".

Jáchym Hercher submitted the following use case to be further developed:
Buyers need to buy things, which means following the e-procurement phases described in the Project Charter (e.g. publishing notices, sending information about who won a contract, signing contracts, drafting and archiving individual procurement reports in the sense of 2014/24/EU Art. 84 etc. etc.). This includes:

1. Creating new information (e.g. description of the procurement, giving points for award criteria).
2. Reusing information from different databases and domains, such as
   - business registries (to reduce administrative burden and ensure consistency of information);
   - tax, social payments, etc. systems (to verify that potential contractors meet selection criteria).
3. (Sending information to other systems to ensure transparency etc. requirements are met, e.g. contract registers).

Claude Schmit asked for the class "evidence" : what does it mean ? some proving metadata about the "payment" ? so it should be linked to class "payment", not "contracting authority"

Should there be a direct relationship between the Call for Tender and the Buyer, given that there already is a direct relationship with Procuring Entity? How do we define that relationship?

I have read the document d02.01_specification_of_the_process_and_methodology_v0.12_1. Thank you very much for making the overview available. Please find some comments in the Word document uploaded at the end of this post. I apologize for not opening a separate GitHub issue for each comment, but it would take too long. Also, I think most of the comments do not perhaps need to have their own thread for discussion. (If you think otherwise, I would kindly ask the administrators to open the necessary issues based on the comments.)

Just to highlight the most important comment: I'm new to this area so perhaps I misunderstood a basic feature of the methodology, but I'm not really sure how relationships and properties are being used. They are named as if they should be general (which is, I think, correct), e.g. hasVAT, publishes. However, the definitions (and domains and ranges) limit the use to only one specific situation. For example, hasVAT is defined as "This property specifies an amount of Value Added Tax charged on an invoice.", which excludes it's use for values of notices, lots, contracts, etc.; publishes is defined as "This property links a contracting authority to a call for tender that it makes available", which excludes publications by contracting entities, review bodies, other types of buyers, etc. and other types of documents, such as corrections, contract awards, modifications, etc. I would expect the definitions of relationships and properties to be context independent, so that they can be used to describe relationships between many different classes?

Other comments include comments on terminology (esp. consistency in its use), examples, other existing projects, etc.

d02.01_specification_of_the_process_and_methodology_v0.12_1_jh.docx

The definition is a little strange 'the payement' is not concerned by a relation between a 'Tender' (domain) and a 'Call for tender' (range).