Contract Notice mapping

[jseguraf]

The 20th and 22nd August, during the Working Group meeting, we had a new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions made were. Note that the mapping and the modifications have been implemented in the Contract Notice diagram:

• BT-61 EU funds indicator is mapped as Procedure has Lot, Lot is funded by Fund (procedure has Lot, Lot is funded by Fund). • BT-1374 Funds Identifier exist in the ePO Ontology: Procedure has Lot, Lot has identifier, Lot is funded by Fund. • BT-03 Cross Border Law is already covered through the property Cross Border Law from Procedure class to Legislation class. • BT-105 Procedure Type is already mapped as attribute of the Procedure class. A new definition has been created replacing the previous one (07/09/2018): “The categorisation of the set of activities of the procedure according to the Law. Additional Information: For example "Open Procedure", "Restricted", "Negotiated without Publicity", etc. (see code list "procurement-procedure-type" WG Approval 20/08/2019”. • BT-88 Procedure Features is already mapped. Procedure has Procedure Main Features. The definition is: “Main features of the procedure and information about where the full rules for the procedure can be found. Additional Information: This information should be given when the procedure is not one of those mentioned in the procurement directives. This can be the case for example for concessions, for social and other specific services, and in case of voluntary publication of procurement procedures below the EU procurement thresholds.” • BT-106 Procedure Accelerated is already mapped. Procedure has Accelerated. The definition has been modified and approved by the WG: “Statement about the fact that the procedure will be reduced due to a state of urgency. Additional Information: This modifies the time limit for the receipt of requests to participate or the receipt of tenders. WG Approval 20/08/2019”. • BT-136 Procedure Accelerated Justification. It is already mapped as the “Accelerated Procedure Further Justification” attribute of the Procedure class. The WG approved the definition: “Explanation about why the choice of an accelerated procedure is lawful. WG Approval 20/08/2019”. • BT-31 Lot Max Allowed. It is already mapped as the "Lot Submission Limit" attribute within the Procedure class. • BT-763 Lots All Required. It is mapped through the “Lot Minimum Submission” attribute. A definition has been created: “The minimum number of lots for which one tenderer must submit tenders. Additional Information: This can be used to state that a tenderer has to submit the maximum number of lots announced in the contract notice (i.e. in this case the Lot Minimum Submission would equal to the Lot Submission Limit).” • Within the Procedure class, the property "Maximum Number of Lots Awarded to One Tenderer" has been rephrased as "Maximum Number of Lots to Be Awarded". • Regarding the BT-1375 the attendees think that it is not correct. It should refer to the individual Lot Identifiers, not to the identifier of the group. • The predicate from Economic Operator Short List to Economic Operator has been rephrased as “has Expressed Interest” instead of “pre-selected Economic Operators. This modelling decision has been carried out within the “Procedure” diagram. • The triple "Candidate Short List qualified Economic Operator" has been added within the “Procedure” diagram. • The definition of the “Economic Operator Short List” has been rephrased by “The Economic Operators that are considered for a given procedure”. • A new class named "Multiple-Stage Procedure Terms" has been created and the attributes from the “Candidate Shor List” class have been moved. The attribute "Successive Reduction" from "Evaluation Terms" has been also moved into "Multiple-Stage Procedure Terms". Moreover, the attribute "No Negotiation Needed" has been added in the class "Multiple-Stage Procedure Terms" but a further discussion is needed in order to see whether this is related to "multiple-stage procedures".

[jseguraf]

The 27th and 29th August - new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions were made. Please note that the mapping and the modifications have been implemented in the Contract Notice diagram:

• The Economic Operator class has been added within the diagram Evaluation Result and those properties no needed in the diagram have been hide.

• The expected candidates attribute from the multiple-stage class has been removed due the fact that there is a maximum and minimum number of candidates and the expected candidates attribute is not needed.

• BG-704 Reward and Jury. The property from the Evaluation Board class and the Evaluation Report is not meaningful (Evaluation Board proposes an Evaluation Report). Instead of it, a new relationship from Evaluation Board to Lot has been created, saying that the evaluation board assigns 1 or + lots, and Lot is assigned to Evaluation Board. The Evaluation Board class has been dropped within the Contract Notice class.

• There is a need to analyse where the Evaluation Board is necessary or not. It will take place during the eEvaluation.

• BT-1377 . The design contest class has been drop within the Contract Notice. The Design Contest class has been renamed by Design Contest Regime Terms according with the Article 78 Directive 24.

• A new Diagram named "Competition Design" has been created in order to:

  1. Better align the Ontology to the eForms;
  2. Separate entities that are specific of a concrete sub-group of elements that are not necessary in other situations, e.g. Design-related classes that are not needed unless the procedure is a design contest;
  3. To better keep the "history/progression/deltas" between different types of competitions (as they do in eForms);

• A new class named Prize has been created and some of the attributes have been moved, (See the definitions provided by the WG for this attribute, which is slightly different from the ones in eForms):

  • Prize Value;
  • Prize Rank.

• A consultation with DG GROW is necessary for the following:

  1. We don't find any reference to "competitive dialogue" in eForms...
  2. How to cater for competitive dialogues specifying prizes? via a General Contract Notice, and if so, how?
  3. Does "prize" refer to the same concept in competitive dialogues and design contest?

• There was the need of creating a new class named "Contract Follow-up Terms" in order not to duplicate data that are used both by the classes "Contract Terms" and "Prize" (at least). This derives from the observation that in eForms they have the contract follow up inside the Prize (and it has also to be related to the procedure in general). This class Contract Follow-up Terms has the following attributes and properties:

  • Follow-up Contract: Indicator, (definition: Any subsequent service contract will be awarded to the winner or, in the case of a design contest, winners);
  • Follow-up Contract Information: Text
  • Follow-upContractTerms applyTo Lot
    • Lot rewardedWith Prize

[JachymHercher]

1. We don't find any reference to "competitive dialogue" in eForms...

It's one of the codelist values for Procedure Type (BT-105).

2. How to cater for competitive dialogues specifying prizes? via a General Contract Notice, and if so, how?

They would be modeled the same as prizes for innovation partnerships (and essentially also design contests). That is via a contract award, but with a Tender Rank (BT-171) higher than one.

However, you have correctly identified a shortcoming in eForms: the definition of BT-171 does not mention competitive dialogues. (Also, Prize (BG-44) could potentially be kept as an optional field for contract notices, so that people could use it to specify at that moment prizes in innovation partnerships and competitive dialogues.)

Too late to change it now; and these are very very very corner cases, so we take note of it for future versions of eForms (which should be quite regular, in any case.)

Does "prize" refer to the same concept in competitive dialogues and design contest?

Essentially yes. Just in a design contest, you'd have prizes for the 1st, 2nd, 3rd etc. place; while in a competitive dialogue / innovative partnership the first place would get the contract, while the remaining places would get prizes. Consequently, design contests will typically have prizes, while for INP/COD we don't really know how often it happens.

This derives from the observation that in eForms they have the contract follow up inside the Prize (and it has also to be related to the procedure in general)

Concerning contract follow-up, I'm not sure why it includes "Lot RewardedWith Prize"? That information is announced at the competition moment and takes place at the contract award moment, not later.

[jseguraf]

@JachymHercher, thank you very much for the comments provided. We will analyse them during the next Working Group meeting and we will reply you if more clarifications are needed.

[jseguraf]

The 10th and 12th September - new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions were made. Please note that the mapping and the modifications have been implemented in the Contract Notice diagram:

• BT-7531 Selection Criteria Second Stage Number Weight. It is already covered through the ESPD Request class. The ESPD Request has Selection Criterion which applies to Lot, and Selection Criterion has the Weight Type code list.

• BT-7532 Selection Criteria Second Stage Number Threshold. It is already covered through the Threshold Type code list which is linked to Selection Criterion class.

• BT-71 Reserved Participation. It is already covered through the reserved-procurement code list which is linked to Lot.

• BT-79 Performing Staff Qualification. eForms is changing this into a Code. This is covered in the ESPD by criterion #47 (Educational and professional qualifications, code CRITERION.SELECTION.TECHNICAL_PROFESSIONAL_ABILITY.TECHNICAL.PROFESSIONAL_QUALIFICATIONS), which is a selection criterion. However we need to discuss (e.g. in the F2F meeting 2019/10/10-11, in Luxembourg) how the information that should go into the ESPD is to be covered/referred to/etc. in the case an ESPD is not provided). So the mapping is left open.

• BT-578 Security Clearance. The Security Clearance Terms class has been dropped within the Contract Notice diagram. Lot class is linked to Security Clearance Terms through the property "requires". Note, that the fact that the property "requires" is used (i.e. instantiated by Lot) implies that an instance of the class SecurityClearanceTerms exist and therefore the indicator is true.

• BT-78 Security Clearance Deadline. It is already covered through the Deadline attribute within the Security Clearance Terms class. A new definition for "Deadline" has been created -"The deadline by which the security clearance must be submitted to the buyer."-

• BT-732 Security Clearance Description. It is covered through the "Description" attribute within the Security Clearance Terms class. However, some internal decisions have been taken: 1. We have come up with a more granular view of this because - We have separated the clearance to access documents from the access to sites;- We specify the type of the addressee security clearance.

• BT-736 Reserved Execution. Similar data is also present in the ESPD. However we understand that this code is also necessary in the CN as it is acting as a kind of indicator that triggers the need in the ESPD for the EO to include additional data like the percentage of disabled or disadvantaged workers, etc. So, in the ePO CN we keep also this BT as a code. Decision: we change the term naming in the ePO from "Sheltered Employment Usage:Code" to "Reserved Execution:Code". Additionally in the ePO we were using the code list "usage" (used, not-used, not-yet-known) and adopt eForms codelist "applicability" (yes, not, unknown).

• BT-761 Tenderer Legal Form. The "Post-Award Terms" class has been renamed as "Contract Terms". Moreover, an attribute named "Contract Legal Form Requirement (Indicator)" has been added to the Contract Terms class in order to cover the BT-761

• BT-76 Tenderer Legal Form Description. A new atribute named "Contractor Legal Form Requirement Description" has been created within the Contract Terms class. A definition for the new attribute has been created adopting the definition of eForms -"A constraint concerning the legal form that must be adopted by a tenderer composed of a group of economic operators once it has been awarded a contract."-. Nevertheless, it has to be discussed further with eForms.

• BT-77 Terms Financial. A new attribute named "Payment Arrangements" has been added within the Contract Terms class. Moreover, a new definition has been created for the attribute. However, it still needs a further discussion with eForms. See the definition: "Information about financial clauses that will govern some economic aspects of the execution of the contract. Additional Information: These clauses usually refer to financial and payment provisions. This type of information should be structured instead of a free text in order to reuse it an ideal world. Unfortunately this is an information that in the real life no one is willing to provide pro-actively."

[jpmckinney]

BT-79 Performing Staff Qualification

BT-79 Performing Staff Qualification. eForms is changing this into a Code. This is covered in the ESPD by criterion #47 (Educational and professional qualifications, code CRITERION.SELECTION.TECHNICAL_PROFESSIONAL_ABILITY.TECHNICAL.PROFESSIONAL_QUALIFICATIONS), which is a selection criterion. However we need to discuss (e.g. in the F2F meeting 2019/10/10-11, in Luxembourg) how the information that should go into the ESPD is to be covered/referred to/etc. in the case an ESPD is not provided). So the mapping is left open.

BT-79 Performing Staff Qualification is described as:

The names and professional qualifications of the staff assigned to perform the contract must be given.

The current standard procurement forms have:

Obligation to indicate the names and professional qualifications of the staff assigned to performing the contract

ESPD, on the other hand, has:

The following educational and professional qualifications are held by the service provider or the contractor itself, and/or (depending on the requirements set out in the relevant notice or the procurement documents by its managerial staff.

The semantics between ESPD and eForms/TED are different. In eForms/TED, it's a requirement for the economic operator to list names and qualifications in their submission. In ESPD, it's a description of the required qualifications that the economic operator must meet. Furthermore, TED puts this field under "Conditions related to the contract" not under "Conditions for participation" (i.e. selection criteria). Therefore, I don't think the above correspondence is correct.

BT-736 Reserved Execution

This is not in ESPD. See in particular this comment by @SellittoGiampaolo which disambiguates between selection criteria (covered by ESPD) and contract terms (which is what reserved execution is about) https://github.com/eForms/eForms/issues/296#issuecomment-472861002

[jseguraf]

The 17th and 19th September - new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions were made. Please note that the mapping and the modifications have been implemented in the Contract Notice diagram:

• During the meeting it was decided that in the documentation to the ontology it should be noted that the definitions refer to the last element in the concept

• During this meeting carried on with the mapping of the Contract Notice a specific model exists for this and at the same time it is aligned with the rest of the ontology. Below is the extract from the mapping file to show the decisions made by the working group:

ID eformsBT	eForms Definition	Ontology Comments and inheritances	Ontology concept
BT-65	Subcontracting Obligation	Procedure has Lot, Lot has Contract Terms, Contract Terms has Subcontract Terms, Subontract Terms hasSubcontractingObligation Code	Procedure.Lot.ContractTerms.SubcontractTerms.SubcontractingObligation
BT-64	Subcontracting Obligation Minimum	Procedure has Lot, Lot has Contract Terms, Contract Terms has Subcontract Terms, SubcontractTerms hasMinimumShare	Procedure.Lot.ContractTerms.SubcontractTerms.MinimumShare
BT-729	Subcontracting Obligation Maximum	Procedure has Lot, Lot has Contract Terms, Contract Terms has Subcontract Terms, Succontract Terms hasMaximumShare	Procedure.Lot.ContractTerms.SubcontractTerms.MaximumShare
BG-707	Award Criteria	Procedure has Lot, Award Criterion isUsedToAward Lot, OR Award Criterion isUsedToAward GroupLot	Procedure.Lot.AwardCriterion OR AwardCriterion.GroupLot
BT-13710	Award Criteria Lot Identifier	Procedure has Lot, Award Criterion isUsedToAward Lot, Lot hasID Identifier, OR Award Criterion isUsedToAward GroupLot, GroupLot hasID Identifier	Procedure.Lot.AwardCriterion.Lot.ID OR AwardCriterion.GroupLot.ID
BT-539	Award Criterion Type	Procedure has Lot, Lot has AwardCriterion, AwardCriterion has award-criterion-type which is inherited from Procurement Criterion and Criterion	Procedure.Lot.AwardCriterion.award-criterion-type
BT-734	Award Criterion Name	Procedure has Lot, Lot has AwardCriterion, AwardCriterion hasName Text which inherited from Criterion	Procedure.Lot.AwarCriterion.Name
BT-540	Award Criterion Description	Procedure has Lot, Lot has AwardCriterion, AwardCriterion hasDescription Text which inherited from Criterion	Procedure.Lot.AwarCriterion.Description
BT-541	Award Criterion Number	Procedure has Lot, Lot has AwardCriterion, AwardCriterion hasValue Numeric	Procedure.Lot.AwardCriterion.Value
BT-5421	Award Criterion Number Weight	Procedure has Lot, Lot has AwardCriterion, AwardCriterion hasWeightValue which is inherited from Procurement Criterion and Criterion, and uses the code list number-weight	Procedure.Lot.AwardCriterion.WeightValue.number-weight
BT-5422	Award Criterion Number Fixed	Procedure has Lot, Lot has AwardCriterion, AwardCriterion hasFixedValue Code and uses the code list number-fixed	Procedure.Lot.AwardCriterion.FixedValue.number-fixed
BT-5423	Award Criterion Number Threshold	Procedure has Lot, Lot has AwardCriterion, AwardCriterion hasThresholdValue and uses the code list number-threshold	Procedure.Lot.AwardCriterion.ThresholdValue.number-threshold

• BT-543 Award Criteria Complicated. It is covered through the “Formula” attribute within the Award Criterion class. A new definition for “formula” has been created and approved: The expression used to find a result. Additional information: This expression is usually a mathematical formula, but it can be an informal description of the way in which the result will be calculated.

• BT-733 Award Criteria Order Justification. It is covered through the “Weighting Justification” attribute which is inherited from the Criterion class. The original name of this attribute from cccev was “Weighting Consideration Description”. The definition of Weighting Justification has been reviewed: Explanation about why the actual weighting model is chosen. Additional information: In eNotification: This property is specifically used to describe why the order of importance is used over another weighting model. In ESPD: This is used to explain other complex models of weighting for transparency reasons.

• BT-765 Framework Agreement. It is covered through the Framework Agreement Type code lists. A new definition for the “Framework Agreement Type” property has been added: The form of framework agreement used in a procurement procedure. As a result of the mapping of the BG-706 Techniques, a new definition for Technique class has been added: Methods used for conducting procurement procedure. Additional information: Several techniques can be combined in one single procurement procedure (e.g. eAuction can be carried out in a Framework Agreement or DPS).

As a result of the eForms mapping some questions have arisen and they need the support from DG GROW: BT-736 / BT-113 (issue to be created).

(a) can you help us to understand what this number refers to and how is it used in the case of FA? We understand this is CM in CN General because it is mentioned at the end of the Annex listing the information that must go in the CN, at the end of paragraph (a):

In the case of a framework agreement, indication of the planned duration of the framework agreement, stating, where appropriate, the reasons for any duration exceeding four years; as far as possible, indication of value or order of magnitude and frequency of contracts to be awarded, number and, where appropriate, proposed maximum number of economic operators to participate.

Questions:

1. Some members of our WG think that this may refer to the maximum number of members of a Consortium.
2. Others think this refers to the maximum number of EOs that can tender for a FA.
3. If 2, would that be equivalent to the maximum number of EOs that are acceptable for the procedure where the FA is used?
4. If 2, could this number vary per Lot or Group of Lots?
5. Any example of the meaning of "where appropriate"?

[JachymHercher]

Just not to lose track: the last section of https://github.com/eprocurementontology/eprocurementontology/issues/216#issuecomment-535908040 above (dealing with BT-736 / BT-113), has already been discussed and closed in https://github.com/eprocurementontology/eprocurementontology/issues/222.

[jseguraf]

The 30th September and 1st October - new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions were made. Please note that the mapping and the modifications have been implemented in the Contract Notice diagram:

• BT-766 Dynamic Purchase System. The WG was discussing the issue #223 about how to deal with the combination of heterogeneous elements in one code list such as DPS, CPB, lists of buyers (see https://github.com/eprocurementontology/eprocurementontology/issues/223) • BT-13712. It is covered through the Lot ID, Lot uses ElectronicMeansofCommunication. • BT-127 Future Notice. It is just for planning therefore is not needed for the Contract Notice. • BT-631 and BT-130. EstimatedInvitationToTender has been created as an attribute of the multiple-stage class. Dispatch Invitation Tender is no need since we are in the Contract Notice context. It is used in sed in PINs CFC. • BT-99. It is covered through the "review deadline information" attribute within the "review terms" class. In addition a new definition for the attribute has been created: The description of the time limits for review procedures. • The class review terms has been dropped within the contract notice diagram. • The Procurement Document has been dropped within Contract Notice diagram and it has been linked to Lot through the property "referredToIn". • The documentreference class has been created within the UBL package and the Document class inherits from this one.

[jseguraf]

The 15th October - new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions were made. Please note that the mapping and the modifications have been implemented in the Contract Notice diagram:

• BT-726 Suitable for SMEs. We added an attribute named a SME suitable within the class Lot and the definition of it is the following: "The Lot is suitable for small and medium enterprises (SMEs).

Additional Information

This allows the buyer to make emphasis on the fact that the procedure has been designed having SMEs in mind. This indicator is also to be reflected in the selection criteria.

For example, number of employees and turnover are applicable to the definition of an SME.

WG Approval 15/10/2019" • BT-115 GPA Coverage. It is covered through the attribute "GPA Usage" within the Lot class. The definition of GPA Usage has been worked and updated: "Specifies whether the Agreement on Government Procurement (GPA) applies.

Additional information: The GPA aims to establish a multilateral framework of balanced rights and obligations relating to public contracts with a view to achieving the liberalization and expansion of world trade.

WG Approval 15/10/2019"

• BT-300 Additional Information. We added the attribute additional information within the Lot class. A new definition has been created: "Supplementary data about the instance of the concept.

Additional Information

For example, information about the Lot not specified elsewhere in the Notice.

WG Approval 15/10/2019". • The download url property has been moved to Access Terms.

[jseguraf]

The 26th September, during the Working Group meeting, we had a new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions made were. Note that the mapping and the modifications have been implemented in the Contract Notice diagram: • BT-736 Framework Maximum Participants. WG decides that it make sense to map this BT to our Framework Agreement Terms Maximum Number of Awarded Tenderers". In addition, the issue #222 related to this BT has been commented and closed. See https://github.com/eprocurementontology/eprocurementontology/issues/222 • BT-113 Framework Maximum Participants Number. It is covered through the "MaximumNumberOfAwardedTenderers" attribute within the "FrameworkAgreementTerms" class. In the Ontology the existence of the property hasMaximumNumberOfAwardTenderers supersedes the need for an indicator. • BT-109 Framework Duration Justification. It is covered through the "DurationExtensionJustification" attribute within the "FrameworkAgreementTerms" class. According to the eForms definition and the definition of the "Extension Justification" they are the same. • BT-766 Dynamic Purchasing System. An issue has been created in the ePO GitHub to check with eForms how to deal with the combination of heterogeneous elements in one code list such as DPS, CPB, List of Buyers. See issue #223 https://github.com/eprocurementontology/eprocurementontology/issues/223 ”

[jseguraf]

The 3rd October, during the Working Group meeting, we had a new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions made were. Note that the mapping and the modifications have been implemented in the Contract Notice diagram:

During this meeting carried on with the mapping of the Contract Notice a specific model exists for Contract Notice Below is the extract from the mapping file to show the decisions made by the working group: It was deceided that TB-14 and BT-707 should be discussed further in the face-2-face meeting next week as the access restrictions need to be global rather than per document which could mean quite some changes. The diagram eSubmission was renamed Submission

ID eformsBT	eForms Name	Ontology Comments and inheritances	Ontology concept	Ontology definition
BT-708	Documents Official Language	Procedure refersTo Document, Document hasOfficalLanguage Code	Procedure.Document, Document.LanguageType	The language(s) in which the instances of the given concepts are officially available. These linguistic versions are equally legally valid. WG Approval 03/10/2019
BT-13	Additional Information Deadline	Procedure has eAccessTerms, eAccessTerms hasAdditionalInformationDeadline dateTime	Procedure.eAccessTerms, eAccessTerms.AdditionalInformationDeadline	The time limit for requesting further information. WG Approval 03/10/2019
BG-102	Submission Terms	Procedure has Lot, Lot has SubmissionTerms	Procedure.Lot.SubmissionTerms	Conditions and stipulations defining particularities of submitting tenders. WG Approval 03/10/2019
BT-13719	Submission Lot Identifier	Procedure has Lot, SubmissionTerms appliesTo Lot, Lot hasID Identifier	Procedure.Lot, Lot.SubmissionTerms, Lot.ID
BT-17	Submission Electronic	Procedure has Lot, Lot applied SubmissionTerms, SubmissionTerms haseSubmissionPermission	Procedure.Lot, Lot.SubmissionTerms, SubmissionTerms.permission	The requirements as to what extent electronic submission is allowed. WG Approval 03/10/2019
BT-19	Submission Nonelectronic Justification	Procedure has Lot, Lot applies SubmissionTerms, SubmissionTerms hasnon-Electronic Submission Justification Code (communication-justification)	Procedure.Lot, Lot.SubmissionTerms, SubmissionTerms.communication-justification	Reason for not accepting electronic tenders. WG Approval 03/10/2019
BT-745	Submission Nonelectronic Description	Procedure has Lot, Lot has SubmissionTerms, SubmissionTerms hasnon-ElectronicSubmissionDescription Text	Procedure.Lot, Lot.SubmissionTerms, SubmissionTerms.ElectronicSubmissionDescription	Textual explanation of how non-electronic tenders are to be presented. WG Approval 03/10/2019
BT-18	Submission URL	Procedure has Lot, Lot has SubmissionTerms, SubmissionTerms has ElectronicMeansofCommunication, EllectronicMeansofCommunication hasURL URI     In the Enterprise architecture file a relationship was created between Submission Terms and Electronic Means of Communication	Procedure.Lot, Lot.SubmissionTerms, SubmissionTerms.ElectronicMeansofCommunication, ElectronicMeansofCommunication.URL	The identifier of a resource. Additional Information For example: 1. The URL of the system from where to access the procurement documents; 2. The URL of the system for the submission of tender documents; 3. The URL of the system from where to download a tool to communicate with the Buyer; 4. The URL of the system used by a Technique to allow Economic Operators to exchange information with the Buyer (e.g. eAuction and DPS Systems) 5. The URL of the system used to exchange information between Buyer and EO for questions and clarifications; WG Approval 30/09/2019
BT-97	Submission Language	Procedure has Lot, Lot applies SubmissionTerms, SubmissionTerms hasTenderLanguage Code (LanguageType)   The Document language was renamed Tender Language	Procedure.Lot, Lot.SubmissionTerms, SubmissionTerms.TenderLanguage.Code	Language in which the tender is to be expressed. WG Approval 03/10/2019
BT-764	Submission Electronic Catalogue	Procedure has Lot, SubmissionTerms appliesTo Lot, SubmissionTerms haseCataloguePermission Code	Procedure.Lot, SubmissionTerms.Lot, SubmissionTerms.eCataloguePermission.Code	The extent to which electronic catalogues may be used in tenders. WG Approval 03/10/2019

[jseguraf]

The 17th October, during the Working Group meeting, we had a new session to map the eForms terms with the ePO Ontology within the context of Contract Notice. In this session, the following modelling decisions made were. Note that the mapping and the modifications have been implemented in the Contract Notice diagram.

During this meeting carried on with the mapping of the Contract Notice a specific model exists for Contract Notice Below is the extract from the mapping file to show the decisions made by the working group:

ID eformsBT	eForms Name	Ontology Comments and inheritances	Ontology concept	Ontology definition	Discussion points/Action Points
BT-718	Change Procurement Documents	Procedure refersTo Document, Document hasChanged Change, Change hasProcurementDocumentsChanged Indicator	Procedure.Document, Document.Change, Change.ProcurementDocumentsChanged	The Contract Notice informs that one more procurement documents available online have changed. WG Approval 17/10/2019	Originally we decided to have it in the class Access Terms (20191015), but as per 20191017 we saw that having it in the class Change could be a better solution because: (1) everything about the change is in one single place; (2) it can be linked to the particular document(s) that have been changed; and (3) the changes are also related to the specific resources that changed (link to class Resource Element).
BT-719	Change Procurement Documents Date	Procedure refersTo Document, Document hasChanged Change, Change hasChangeDate Date	Procedure.Document, Document.Change, Change.ProcurementDocumentsChanged	The Contract Notice informs that one more procurement documents available online have changed.   WG Approval 17/10/2019	Everything about the change is now in class Change
BT-140	Change Reason Code	Procedure refersTo Document, Document hasChanged Change, Change hasChangeReason	Procedure.Document, Document.Change, Change.ChangeReason	The main reason for the change in the notice compared to the original notice. WG Approval 17-10-2019	The code list “Change corrig justification” from EU vocabularies is to be incorporated into the Conceptual model.  See: https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/change-corrig-justification   It should be noted that all the code lists except CPV and NUTS used in eForms can be found at : https://op.europa.eu/en/web/eu-vocabularies/e-procurement/tables
BT-762	Change Reason Descripition	Procedure refersTo Document, Document has Change, Change hasChangeDescription Text	Procedure.Document, Document.Change, Change.Change Description	Information about the change.   Additional Information   Used, for example, to explain the main reason for the change in a document compared to the original document.   WG Approval 17/10/2019

From the above discussion it is clear that a solid document on how the Document/Resource is to be implemented needs to be drawn up. It is hoped that the presentation of Enric on how and whether we should use the FRBR model will put us on the good route. His presentation on whether the FRBR model or other models to be used in ontology will be on 22/10/2019. As it was considered that the majority of terms for the Contract Notice had been treated. Natalie presented her concerns on the representation of the mappings to eForms. After a discussion the following conclusions were made:

1. The column AW “Comments and inheritances” represents the rdf based syntax
2. The column AX “Concept” represents the Object oriented programming (OOP) syntax The decision:
3. An ontology only requires the rdf based syntax therefore the OOP syntax will be removed;
4. The definitions to be supplied in the ontology-eForms mapping is that of the property in its context ie for the ID in the Procedure class the definition of Procedure ID should be given. The composite parts to be defined should be highlighted ie Procedure hasID
5. A class with a property directly attributed to it is represented by the the term”hasXxx” where Xxxx is the property ie Procedure hasID
6. An inheritance is represented by isA Xxxx where Xxxx is the property. Ie ContractNotice isA Notice: The two tables below represent the ontology-eForms mapping in light of the above for Procedure Identifier and Notice identifier Table 1: Procedure Identifier for CN only

Table 2: Notice Identifier for CN only

The discussion then went on to discuss how the Contract Notices, Prior information Notices and Contract Notices Could be represented without having to do a copy paste of all the terms and increase the probability of incoherencies due to non update of all data in the case of corrections. In the example below it was decided to take NoticeID as it is the highest granularity before the division into PIN, CN and CAN. The following ideas were formulated: Table 3: Notice Identifier for PIN, CN, CAN

Although this seemed to be a good solution when the same principle was applied to Procedure Identifer complications appeared: Table 4: Procedure Identifier for PIN, CN, CAN

One of the suggested solutions was to split the table further showing the different types of forms and notices: Table 5: Procedure Identifier for the different form and notice types

It was decided that Enric would consider the different proposals and present one or more solutions (whether already proposed or not) on Thursday 24 October 2019 on “How the ontology should best represent the different types of notices both within the diagrams and the overall model itself”. Natalie would continue harmonising the Rdf based syntax which could be adapted later according to the decisions taken with regard to the representation chosen. Afterthought: We need to see how these definitions are to be represented in the glossary are composite forms represented in the ontology.

[andreea-pasare]

We have ensured that ePO v4.0.0-rc.1 covers the COMMISSION IMPLEMENTING REGULATION (EU) 2022/2303 of 24 November 2022 amending Implementing Regulation (EU) 2019/1780 establishing standard forms for the publication of notices in the field of public procurement, EUR-Lex - 32022R2303 - EN - EUR-Lex (europa.eu)