Cumulative content of Working Group Meetings in 2023
Working Group meeting
Date: 14/12/2023
Participants: Pietro Palermo, Ivan Willer, Thomas Pettersen
Model editor: Andreea Pasăre
Note editor: Natalie Muric
Discussion
Definitions were added for the following concepts:
| Project reference identifier | The identifier of the project the order refers to. |
|---|---|
Order validity period |
A group of business terms providing information on the validity period of an Order. |
Order validity end date |
The date at which the order validity period ends. |
Order validity end time |
The time at which the order validity period ends. |
Offer reference |
A group of business terms providing information on a preceding Offer. |
Offer reference identifier |
The identifier of the Offer. |
Offer reference issue date |
The date of formal issuance of the Offer. |
Offer reference issue time |
The time of formal issuance of the Offer. |
Offer issuer identifier |
to be taken from eCatalogue |
Order reference |
A group of business terms providing information on the Order being referenced to. |
Order reference identifier |
The identifier of the referenced Order. |
Order reference issue date |
The date of formal issuance of the referenced Order. |
Order reference issue time |
The time of formal issuance of the referenced Order. |
Originator document reference |
A group of business terms providing information on a document in which the originator describes his needs. |
Originator document reference identifier |
The identifier of the referenced originator document. |
Originator document reference issue date |
The date of formal issuance of the originator document. |
Originator document reference issue time |
The time of formal issuance of the originator document. |
Catalogue reference |
to be taken from eCatalogue |
Catalogue reference identifier |
to be taken from eCatalogue |
Catalogue reference issue date |
to be taken from eCatalogue |
Catalogue reference issue time |
to be taken from eCatalogue |
Additional documents reference |
A group of business terms providing information on one or more referenced documents. |
Additional document reference identifier |
The identifier of the referenced document. |
Additional document reference issue date |
The date of formal issuance of the referenced document. |
Additional document reference issue time |
The time of formal issuance of the referenced document. |
Attached document |
An attached document embedded as binary object or sent together with the Order. |
Attached document Mime code |
The Mime code of the attached document. Allowed mime codes: - application/pdf - image/png - image/jpeg - text/csv - application/vnd.openxmlformatsofficedocument. spreadsheetml.sheet - application/ |
Attached document filename |
The file name of the attached document. |
External document URI |
The URL (Uniform Resource Locator) that identifies where the external document is located. |
Contract information |
To be taken from Pre-Award |
Contract identifier |
To be taken from Pre-Award |
Contract issue date |
To be taken from Pre-Award |
Contract issue time |
To be taken from Pre-Award |
Contract description |
To be taken from Pre-Award |
Buyer information |
A group of business terms providing information on the agent that awards a contract and/or purchases items. |
Party information |
|
Buyer party electronic address |
The identifier of the Buyer’s electronic address from which the Order is sent. |
Scheme identifier |
The identification scheme identifier. |
Party identification |
|
Buyer party identification |
An identifier of the Buyer. |
Scheme identifier |
The identification scheme identifier. |
Party name |
|
Buyer name |
The full name of the Buyer. |
| Buyers legal registration identifier | The identifier issued by an official registrar that identifies the Buyer as a legal entity or person. |
|---|---|
Scheme identifier |
The identification scheme identifier. |
-
Order hasValidityPeriod to be added to the model (column FGH) - need to find a solution for date and datetime
-
Quotation changed to Offer to align with the ontology
-
Offer issuer is changed to Offer issuer identifier
-
All BG descriptions have been harmonised to start with: "A group of business terms providing information on ……"
-
Originator Request: Definiton taken from ontology
-
Attached document, Attached document Mime code, Attached document filename not covered by ontology but will give an external document URI.
Action Points
-
Add epo:Order epo:hasValidityPeriod epo:Period as following:
| epo-ord:Order / epo:Period / xsd:dateTime | ?this epo:hasValidityPeriod / epo:hasEnd ?value . | The date and time at which this period ends. |
|---|---|---|
epo-ord:Order / epo:Period / xsd:dateTime |
?this epo:hasValidityPeriod / epo:hasEnd ?value . |
The date and time at which this period ends. |
-
Investigate a possible solution for date and time implementation in ePO.
Working Group meeting
Date: 12/12/2023
Participants: Paloma Arillo, Klaus Nielsen, Laurent Schoojans, Dragos Stoica, Pascaline Laure Tchienehom, Cristian Vasquez
Model editor: Andreea Pasăre
Note editor: Natalie Muric
Agenda
-
Questions whilst addressing the ESPD Request
-
Review eAccess diagrams to be published in the release candidate
-
eAccess concept definitions
Discussion
Questions whilst addressing the ESPD Request
-
epo-acc:includesNationalCriteria changed to epo:includesNationalCriteria to be aligned with epo:QualificationCriterion.
-
ProcurementCriterion epo:hasConstraint can probably be removed as it is probably not the ProcurementCriterion that has a Constraint and we need to check in the modelling of the notices. This relation is used for standard form mappings:
It was decided to keep epo:ProcurementCriterion epo:hasConstraint cccev:Constraint because removing it would create a major release.
Review eAccess diagrams to be published in the release candidate
-
epo-acc:ESPDRequest epo-acc:concernsProcedure predicate looks redundant since we have epo:Notice epo:refersToProcedure However, the ESPD Request does not have to be associated to a notice so it was decide to keep
epo-acc:ESPDRequest epo-acc:concernsProcedure predicate:
-
A clean-up of the eAccess diagrams has been done, resulting in the removal of redundancies such as:
-
epo:QuestionSubgroup epo:containsQuestion
-
epo:QuestionGroup epo:containsQuestion
-
epo:QuestionGroup does not have to have a QuestionSubgroup, so the cardinality of epo-acc:containsQuestionSubgroup is changed to 0.* instead of 1..*.
-
In an ESPD-Request, a Procurement Criterion must be initiated by a RequirementGroup or a QuestionGroup. Therefore, although both have a cardinality of 0..* from the Procurement Criterion, only one of the two concepts must be present.
The resulting diagram is depicted below:
eAccess concept definitions
-
The following definition was added for epo-acc:Requirement:
“Data that a Buyer requests from a Tenderer.
Additional information:
The Requirement often has a Constraint.
WG approval 12/12/2023”
-
The following definition was added for epo-acc:RequirementGroup:
“A concept that contains one or more related Requirements or Requirement Subgroup.
WG approval 12/12/2023”
-
A proposal to replace the group and subgroup concepts with the use of identifiers was suggested and implemented as depicted below:
Working Group meeting
Date: 28/11/2023
Participants: Paloma Arillo, Pascaline Laure Tchienehom, Cristian Vasquez
Model editor: Andreea Pasăre
Note editor: Andreea Pasăre
Discussion
The models that were requested at the end of the last WGM were presented:
-
Model that includes RequirementGroup, QuestionGroup and QuestionSubgroup concepts:
At instance level:
-
Model without groups and subgroups:
At instance level:
The final proposal during the WG meeting was the following:
Working Group meeting
Date: 21/11/2023
Participants: Paloma Arillo, Eugeniu Costetchi, Pascaline Laure Tchienehom, Cristian Vasquez
Model editor: Andreea Pasăre
Note editor: Natalie Muric
Discussion
Definitions of CCCEV concepts and concepts in the ESPD were discussed.
Definition for epo-acc: Requirement was proposed:
"Data that a Buyer requests of a Tenderer."
In the actual ESPD-EDM Technical Overview model there is no difference in the definitions between the requirement, question and caption. However, the name of the Business element changes in each case.
How the CCCEV deals with entitlement to marriage with regard to legal age was used as an example of the CCCEV works:
In was stated that in the ESPD-EDM model, the Group tags are used to gather information based on semantics. Therefore, we should either specialise everything or nothing at all.
It was noted that in the ESPD-EDM documentation, a Requirement does not need an answer but a question requires an answer.
The ESPD-EDM technical documentation defines the code list CriterionElementType with the following values:
-
REQUIREMENT-→ Remark, rule, restriction or additional information to which the Economic Operator needs to conform or comply with
-
QUESTION-→ A question that requires an answer (a specific datum) from the Economic Operator
We need to write down how the questions are related to a specific set of requirements and can be sequential.
The Requirement Group are "needs", whereas the Question Group is how the "needs" are fufilled.
In the ESPD-EDM there seems to be two dimensions:
-
data representation
-
how the data is used in an application.
However the ontology should just look at the data and not the application.
Therefore, we need to have an XML example of data, both for a given request and its corresponding response.
Examples to be provided for General Yearly Turnover and OTHER-EO-SME Selection Criteria.
The reason behind choosing these two Criteria is because the first one contains Requirement Group that gathers Requirements, Question Subgroups and Questions, while the second one contains only Question Groups and Questions.
Working Group meeting
Date: 07/11/2023
Participants: Asma Adala, Paloma Arillo, Guillaume Jacquet, Giovanni Paolo Sellitto, Pascaline Laure Tchienehom, Cristian Vasquez
Model editor: Andreea Pasăre
Note editor: Natalie Muric
Agenda
-
Modelling of ELI
-
eAccess:
-
Subcriterion
-
Information Requirement: Requirements and questions
-
Modelling of ELI
The modelling of ELI was presented. It was noted that ELI includes Manifestation concept, which is not required within eAccess.
It was discussed that ELI will be imported into the ontology and the concepts required will be reused and not customised:
Since the concepts in the ELI model can be used even if ELI is not implemented in the given Member State the following concepts were removed: cccev:ReferenceFrankework epo-acc:Legistion epo-acc:Article.
Subcriterion
As the subcriterions ar only used for National Criterion it was decided to change the predicate epo-acc:hasSubcriterion to epo-acc:includesNationalCriterion.
Information Requirement: Requirements and questions
To simplify the reading of the model for business people, it was decided to create specialisations of the CCCEV concepts.
If an entity needs to exist you need explicity to show it. An entity should be a whole.
It was suggested to add a composition relation (the idea of one concept containing another) between:
-
RequirementGroup and Requirement
-
QuestionGroup and Question
However, the composition relation type is not foreseen in model2owl.
Working Group meeting
Date:31/10/2023
Participants: Paloma Arillo, Peter van Borresen, Laurent Schoonjans, Pascaline Laure Tchienehom
Model editor: Andreea Pasăre
Note editor: Andreea Pasăre
Discussion
eFulfilment
-
Sent to Peter the spreadsheet example from Ordering data model. He will change his spreadsheets and get back to us to schedule a meeting.
Natural Language Statements (NLS)
Continuing with the NLS:
*
| The Selection Criterion can have a Requirement with an identifier provided. | epo:SelectionCriterion / cccev:InformationRequirement / adms:Identifier / rdf:PlainLiteral | ?this epo-acc:specifiesProcurementCriterion / cccev:hasRequirement / adms:identifier / skos:notation ?value . |
|---|
The Requirement for the Selection Criterion is not mandatory in ESPD version 3.
*
| An ESPD Request has to |
epo-acc:ESPDRequest / epo:ExclusionGround | ?this epo-acc:specifiesProcurementCriterion ?value . |
|---|
-
In the ePO the epo:ExclusionGroundSummary is at the epo:Procedure level, and epo:ExclusionGround is at the epo:Lot level. In the ESPD Request, the Exclusion Grounds are defined per all Lots, meaning per Procedure, even though there is no direct link between a Criterion and the Procedure (check diagram below):
Changing the NLS below to reflect what was mentioned above:
| The Exclusion Ground is related to a |
?this epo:specifiesProcurementCriteriaSummary ?value . | |
|---|---|---|
|
|
|
| The Exclusion Ground has a type code. |
|---|
But epo:ExclusionGroundsSummary is directly a subclass of cccev:Requirement, and not of cccev:Criterion (which is linked to at-voc:criterion) and that is why in ePO we can not provide a type for epo:ExclusionGroundsSummary:
We have 3 option for fixing this in ePO:
-
Either changing the generalisation relation from cccev:Requirement to cccev:Criterion
-
Replicate the at-voc:criterion usage at the epo:ExclusionGroundsSummary level (need to see if epo:ExclusionGroundsSummary can be used for the ESPD Request Exclusion Ground use cases).
-
Create a link epo:Procedure epo:specifiesExclusionGround epo:ExclusionGround as we had in ePO 3.1.0.
Next on:
| The Exclusion Ground can have a Requirement with a description provided. | epo:ExclusionGround / cccev:InformationRequirement / rdf:PlainLiteral | ?this epo-acc:specifiesProcurementCriterion / cccev:hasRequirement / dct:description ?value . |
|---|
General Yearly Turnover
-
Presenting the General Yearly Turnover instantiation diagram with modification at Information Concept skos:prefLabel
Working Group meeting
Date:24/10/2023
Participants: Paloma Arillo, Ansgar Mondorf, Laurent Schoonjans, Pascaline Laure Tchienehom
Model editor: Andreea Pasăre
Note editor: Andreea Pasăre
Agenda
-
Discuss ESPD future OUC presentation
-
Present eAccess user stories and natural language statements
Discussion
ESPD OUC presentation
Paloma presents the calendar of the future ESPD and ePO meetings.
The General Yearly Turnover slides where then worked on for the ESPD-EDM OUC Meeting.
It was noted that the question to ask during the presentation should be: Where is the Threshold per year checkbox in the mock-ups from the ESPD-EDM repository GitHub issue 44?
Pascaline showed that in the ESPD-EDM technical handbook there is another mock-up which seems more up-to-date: https://docs.ted.europa.eu/ESPD-EDM/latest/xml_technical_handbook.html#_turnovers
eAccess user stories
EG_misrepresentation is used to check if the Tenderer has been misrepresented, withheld information, unable to provide required documents and obtained confidential information of this procedure.
All {ADDITIONAL_DESCRIPTION_LINE} tags need to be answered by the Tenderer.
This should not be in the ePO model, but as part of the definition of the misrepresentation element code (exclusion ground) used.
Below is a screenshot from the Belgian ESPD service:
Natural language statements [NLS]
Going through the NLS one by one:
-
As an open question: is this the contact point of the role or of the Organization?
| The Buyer must have a contact point. | epo-acc:ESPDRequest / epo:Procedure / epo:Buyer / org:Organization / cpov:ContactPoint | ?this epo-acc:concernsProcedure / epo:isResponsabilityOfBuyer / epo:playedBy / epo:hasPrimaryContactPoint ?value . |
|---|
This is an open question since in ePO we provide both ways.
An email is sent by Lorent to Marc Christopher to ask this question. To be confirmed with GROW.
-
It is not mandatory for a Procurement Service Provider to be involved in an ESPD Request.
| The Buyer specified in an ESPD Request may use a Service Provider to offer a platform that can be used by both the Buyer and Economic Operator. | epo-acc:ESPDRequest / epo:Procedure / epo:Buyer / epo:ProcurementServiceProvider | ?this epo-acc:concernsProcedure / epo:isResponsabilityOfBuyer / epo:delegatesAncillaryActivitiesTo ?value . |
|---|
-
Is there an use-case where an ESPD Request does not provide both Exclusion Grounds and Selection Criteria? In an ESPD Request only the Exclusion Grounds are mandatory, and generally specifies Selection Criteria.
| An ESPD Request |
epo-acc:ESPDRequest / epo:SelectionCriterion | ?this epo-acc:specifiesProcurementCriterion ?value . |
|---|
-
Can an Exclusion Ground have a REQUIREMENT tag? In general, no, but there might be one or two. (see tax-pay in EG_Contributions)
Working Group meeting
Date:12/10/2023
Participants: Lamya Rafes, Pietro Palermo, Thomas Pettersson, Giovanni Paolo Sellito
Model editor: Andreea Pasăre
Note editor: Natalie Muric
Discussion
How to represent the different concepts and their usage.
Andreea presented the first 50 terms where she has put the ePO class path and the ePO property path.
Cbc:identifier has multiple usages, such as in contract or in catalogue. However, in ePO we need to add the adms:identifier property to each class.
How to number the different business terms and groups was discussed. For example, for the Order data model we can have the following:
BG-ORD-0
BT-ORD-01
It was suggested that the example above should implemented in the other phases. Whereby, if something is missing then the numbering jumps in the given phase.
Usage note clarifies how the concept is to be used.
Specification identification and Business type process type identifier are not part of ePO. It is not clear whether eOrdering will use it. It has been kept so far to be aligned with eInvoicing.
Sales order reference is needed maybe in the response so the seller can give its own identifier to the order.
The predicate hasSellerOrderID is created between epo-ord:Order and adms:Identifer. There is an argumentation that this should not be within the Order Group as it is added later by the Seller, but for ease it is left here for the time being:
epo-ord:hasSellerOrderID
Definition: The identifier of the Order given by the Seller.
Additional Information: This identifier is different than the identifier of the Order given by the Buyer and it is useful for internal purposes.
WG approval 12/10/2023
The ontology needs to address the problem of Order issue date and order issue time the first being mandatory and the secondary being optional. This is the same problem as in notices.
The order itself does not have a currency, but the different monetary values associated to the order do have. Therefore there is no mapping between the order and currency but rather through the individual monetary values.
The Buyer contact is the Buyer Contact point in the ontology. More detailed information on the Buyer is used later, so here the dct:description will be applied.
The ontology will provide the overall map of the concepts used. In the ordering it is not part of the ontology project to provide a model for the different transactions within the ordering phase. The same can be applied to the other modules
The next business term discussed was:
epo-ord:hasSellerOrderID
Definition:
The identifier of the Order given by the Seller.
Additional Information:
This identifier is different than the identifier of the Order given by the Buyer and it is useful for internal purposes.
WG approval 12/10/2023
Working Group meeting
Date:10/10/2023
Participants: Ansgar Mondorf, Pascaline Laure Tchienehom
Model editor: Andreea Pasăre
Note editor: Andreea Pasăre
Agenda
-
Overview of the eAccess
-
Continue discussing the General Yearly Turnover Selection Criteria instantiation
Discussion
eAccess overview
The predicate epo-acc:refersToNotice was added between epo-acc:ESPDRequest and epo:Notice
There is an idea in the ESPD community to remove certain data from the ESPD, since the data is already in the Notice, so the ESPD Request can focus only on the Qualification Criteria.
It was decided that docref-content-type controlled vocabulary is not needed in the ePO.
We should take a decision on whether to remove the epo-acc:concernsProcedure predicate between epo-acc:ESPDRequest and epo:Procedure:
Why are there two relations between cac:TenderingCriterion and cac:ProcurementProjectLot?
They are used to express the different cardinalities between Selection Criterion and Exclusion Ground.
Exclusion Ground is at the Procedure level and not at the Lot level.
The cac:TenderingCriterion concept includes the attribute ProcurementProjectLotReference, but has also links to cac:ProcurementProjectLot class as depicted below:
This should be handled by the ESPD team.
The Legislation concept is only a reference to the actual legislation, so it should not be treated as a Document.
A question once again came up about the Criterion versus Subcriterion. Pascaline asked why don’t we create a special class for SubCriterion or for REQUIREMENT_GROUP. After that it was said that Subcriterion might not really be used in ESPD Request.
It was mentioned that at the ePO level a Subcriterion is just another Criterion and we don’t need to create it. It was decided that at the moment we will keep the model as it is, without differentiating between ProcurementCriterion and Subcriterion.
General Yearly Turnover
The first QUESTION_SUBGROUP for the General Yearly Turnover use-case was discussed:
The proposed instantiation for the above QUESTION_SUBGROUP is:
The second QUESTION_SUBGROUP is presented:
with its proposed instantiation:
Pascaline will look at the rest of 3 question subgroups for the next time.
Continued with presenting where the documentation for the ePO exists.
Action points
-
We need to represent the class – subclass relationships in the ePO glossary.
Working Group meeting
Date: 05/10/2023
Participants: Pascaline Laure Tchienehom
Model editor: Andreea Pasăre
Note editor: Andreea Pasăre
Discussion
The CCCEV explanatory example presented was https://semiceu.github.io/CCCEV/releases/2.00/html/CCCEV_AnExplanatoryExample.pdf
Neither in the ESPD Request nor in the ESPD Response is the Evidence mandatory.
It is the same with CCCEV, as all cardinalities are [0..*].
Reference Framework
Since cccev:ReferenceFramework represents the legislative part in CCCEV, epo-acc:Legislation and epo-acc:Article were added as subclasses of cccev:ReferenceFramework.
This implies that we no longer need epo:ProcurementCriterion epo-acc:implementsLegislation epo-acc:Legislation and epo:ProcurementCriterion epo-acc:implementsArticle epo-acc:Article.
These two relations are deleted and _cccev:Requirement cccev:isDerivedFrom cccev:ReferenceFramework _is implemented instead.
From the explanatory example, we can see that CCCEV uses ELI for the Reference Framework, making them able to point directly to an article by using an URI.
The ESPD Request does not have an use case for providing the issuer of the Criterion.
Question: In the ESPD Request does the LEGISLATION apply to all the concepts nested within a given CRITERION tag?
The only link that the ESPD provide is the link between the CRITERION and LEGISATION. They do not need to represent the links between LEGISLATION and REQUIREMENT or QUESTION.
Question: What is the difference between cccev:InformationRequirement and cccev:InformationConcept?
Definition for Information Requirement is: "Requested data that is to be proven by Evidence."
Definition for Information Concept is: "Piece of information that the Evidence provides or the Requirement needs."
Based on the diagram above, the InformationConcept will be used to link to the SupportedValue of the Evidence in the ESPD Response.
REQUIREMENT_GROUP
(cac::TenderingCriterionPropertyGroup)
In the ESPD Request, cac::TenderingCriterionPropertyGroup is defined as "the sets of properties that can be used to fulfil the tendering criterion."
Financial ratio criterion (finan-rat) has a REQUIREMENT_GROUP with a cardinality of [1..n], meaning that we should have an additional layer between the instance of epo:SelectionCriterion and cccev:InformationRequirement instances. This instance will only provide an Identifier and will group together all the InformationRequirement instances for that specific Criterion.
After discussing the REQUIREMENTS from the ESPD Request side, all the related InformationRequirement instances have been moved at the level of the Group instance as per the diagram below:
The meeting ended with presenting the first QUESTION_SUBGROUP from the General Yearly Turnover: