Missing definitions

Discuss GitHub issue 788: Unmappable eForms fields regarding transportation in T02 notice subtypes

Discuss GitHub issue 788: Unmappable eForms fields regarding transportation in T02 notice subtypes

Discuss proposed definitions for the concepts that do not have a definition in ePO 5.1.0

Discuss proposed definitions for the concepts that do not have a definition in ePO 5.1.0

Updated definitions for epo:TaxInformationProvider, epo:EmploymentInformationProvider, epo:EnvironmentalProtectionInformationProvider to fully align with the definitions from the organisation-role codelist.

Added additional information to epo:PlannedProcurementPart: "A Lot or a Procedure can also cover one or more parts of the Planned Procurement."

Removed "Additional Information: This Procurement Criterion can be only Exclusion Ground, Selection Criterion or Award Criterion. Each of these Criteria can contain subcriteria (Criterion class)."" from epo:ProcurementCriterion definition.

Create GitHub issues for:

Discuss proposed definitions for the concepts that do not have a definition in ePO 5.1.0

Discuss Github issues with milestone 5.1.0.

The “Offer” folder in the Conceptual Model file was moved to the sandbox folder because an Offer module is not foreseen due to the fact that epo:Offer is implemented in the ePO-core module.

The eForms mappings map the information on the ProcurementProject as an epo:Procedure which is not correct. There should be a new concept in ePO representing the ProcurementProject accounting for the following fields:

Class epo:PlannedProcurement was created as a subclass of epo:ProcurementElement. It was also made sure that the attributes on epo:ProcurementElement cover the needs of epo:PlannedProcurement.

Concepts epo:hasLegalBasis and epo:hasLegalBasisDescription were moved from epo:ProcurementObject to epo:ProcurementElement.

There is a problem with LocalLegalBasis in the mappings.An eform does not have a locallegalBasis, although it used to be in epo:Notice as a standard form requirement.

A a new concept called epo:LocalLegalBasisInformation was created, with the following attributes and Object properties:

Present the ePayment CM to UBL experts.

The ePayment CM was presented

Github issue Update cardinality of refersToProcedure relation from Notice to Procedure to 0..1 #792 was discussed, and closed as a duplicate of issue #715 which is already implemented for ePO 5.0.0.

To compare the roles between ePO and UBL.

ePayment

A question regarding #757 was made: epo:resolvesReviewRequest appearing in the comments of the github issues should bcome epo:answersReviewRequest

RemittanceAdvice for ePayment was discussed. Specifically, the following UBL terms related to the RemittanceAdviceLine were discussed:

It was noted that a RemittanceAdviceLine does not require a UUID.

Payment Purpose Code: It was discussed that Ontology does not need such a codelist.

IIt was mentioned that UBL concepts 2059-2062 seen below are not needed for the Ontology

It was discussed that the epo-ord:Originator should not be part of ePayment. It will be added in the future if a suitable use-case is found.

It was discussed that all the roles should stay on the epo-pay:RemittanceAdvice level, and not on the RemitanceAdviceLine.

It was mentioned that BuyerCustomerParty is not needed, and the cardinality of a relation from the Advice to the Buyer should be 1.

It was discussed that BillingReference will be implemented for epo-pay:RemittanceAdviceLine level and epo-pay:RemittanceAdvice level, as the attribute epo-pay:hasBillingReference rdf:PlainLiteral [0..1].

epo-ord:hasAccountingCost was removed from the document and the line.

It was discussed thatExchangeRate is not currently needed for ePO. It may be added in the future if a suitable use-case is found.

#773 was discussed: It is currently on hold, because we are still awaiting an answer from Catalogue Domain experts.

#778 It was discussed: It was decided that this is not a requirement for eOrdering, and for further information the eOrdering Specialist should be consulted.

#779 was discussed: It was decided that this is not currently needed for Ontology.

Change epo:resolvesReviewRequest in #757 to epo:answersReviewRequest

Discuss the following Github issues with milestone 5.1.0:

It was discussed that issues #778 and #779 should be discussed next time.

Issue #780 was discussed:

It was discussed that The model2Owl configuration was tested on the epo-conceptual-model repository, and that it will be integrated on the develop branch.

The Requirements that need to be implemented for the ePO workflow implementation were discussed.

To organize a meeting with the eFulfilment working group.

Create a github issue to add purpose to planning notice.

Discuss the upcoming ePayment module

The ePayment ORSD was discussed.

ePO 5.1.0 github issues were discussed:

Issue #774 was discussed:

Issue #640 was discussed, closed, and converted to an alignment discussion.

Issue #711 was discussed. And was put back in milestone 5.0.0 since it was implemented then.

Issue #787 was discussed, and converted to an alignment discussion.

To fill in the ePayment ORSD by next WGM.

To discuss the RemittanceAdviceLine in the next WGM.

Discuss the upcoming ePayment module

The remittance advice and remittance advice amount diagrams were discussed. Both diagrams were based on UBL’s Remittance Advice. Looking at the UBL-RemittanceAdvice-2.4 model, the following assumptions were made for the ePO model:

It was mentioned Invoice Period is 0..n in UBL because it may refer to many lines.

Billing Reference: A billing document is similar to an invoice. We can use the epo:hasAccountingCost datatype property (on the level of the epo-pay:RemittanceAdvice) for this.

It was mentioned that the RemittanceAdvice is a specialization of epo-cat:PostAwardDocument.

Predicate epo:isSupportedByForTender linking epo-sub:ESPD to epo:Tender was deleted, because Tender exists in ePO core, and ESPD in eSubmission. In its place, predicate epo-sub:isContainedinTender was created linking epo-sub:ESPD to epo:Tender

Class PaymentExecutor was removed from eInvoicing since it was not necessairy.

It was noted that the following UBL concepts are not currently needed for ePO:

PaymentID is useful. We need to create this Identifier:

ServiceLevelCode this is the same as these we have in the eEnvoicing module.

It was noted that the RemittanceDocumentDistribution concept is the contact point of the remitance Advice Receiver.

Schedule a followup WGM on the eInvoicing module on the 20th of May.

Discuss the eQualification, eAwarding, and eRequest diagrams.

The eQualification Diagram "evidence request, submission and receipt" was presented, discussed, and approved.

The eQualification Diagram "qualification response" was presented, discussed, and approved.

It was argued whether class cccev:Evidence should point at the epo:ProcurementCriterion class. It was decided that this is not necessary.

It was also noted that epo:ProcurementCriterion is already linked to the epo:Lot class.

Attribute epo:isQualified was added on class epo-qua:QualificationDecisionInformation.

The eAwarding diagram "award decision notification" was presented, discussed, and approved.

Attribute epo-awa:hasStandStillPeriodEndDate was added at the level of epo-awa:AwardDecisionNotification

The eRequest diagram "request for offer" was presented, discussed, and approved.

UBL request for Quotation (used for eRequest) was discussed.

After presenting all the diagrams, the WG decided that eQualification, eAwarding and eRequest modules can be published.

It was decided that the epo-eva:UniqueResponsibleOfTheProcurement should be moved to ePO core.

A number of remarks for PEPPOL’s use of UBL transactions were made. Specifically:

To revisit the PEPPOL mappings when ePO 5.0.0 is released.

To check the latest versions of the CEN PEPPOL mappings documents.

To create a ticket to revisit the "request for offer" diagram and investigate the privacyCode for UBL’s request for quotation in ePO 5.2.0.

eRequest ORSD

eQualification ORSD and eAwarding ORSD

Discuss Announces vs. RefersTo #781 discussion

Announces vs. RefersTo #781 discussion

The eQualification ORSD and eAwarding ORSDs were reviewed and discussed.

Create a ticket: Predicate epo:announcesRole from class epo-not:ContractModificationNotice to class epo:AgentInRole to be changed to epo:refersTo.

To update the diagram of the offering party to include Candidate and any other roles currently missing from the diagram.

To continue fixes in the eQualification ORSD.

eForms Requirements:

Discuss eOrdering requirements.

Discuss eFulfilment requirements

The eOrdering requirements were discussed:

eFulfilment requirements:

The following github issues for ePO 6.0.0 were discussed.

Review related issues:

It was decided that the following issues will be moved to 5.1.0:

It was decided that Problem with associations from Tender to Lot and LotGroup #683 will be moved to 6.0.0 as further discussions are needed as to whether a change is required in the Ontology.

Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726 : Although all the changes to the Ontology needed to accommodate the unmappable fields were implemented, they need to be reviewed.

Announces vs. RefersTo #781 discussion: The WG decided to create a spreadsheet that indicates what predicate should be used for each Notice – Entity pair.

Update the Mappings to the eOrdering data models.

Create a Github Issue: The ESPD should become independent of the ESPD request. link it to #701 Remove Predicate epo-sub:relatesToESPDRequest

To follow up with the open Github issues on eCatalogue.

create a Github Issue: We need a way to represent indefinite durations for standard forms for 5.2.0.

Create a spreadsheet for Announces vs. RefersTo #781

Create a Github issue to model E1 (premarket consultation) notice.

To review Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726.

Discuss the mappings between fields from the TC440 Order Data model to ePO concepts.

OrderResponse field BT-ORL-5 Maximum backorder quantity was discussed:

OrderResponse field BT-ROL-2 Referenced Order line status code was discussed.

OrderCancelation

OrderChange

It was agreed that the OrderResponseConfirmation, OrderResponseRejection and OrderResponseSimple data-models can be modelled using epo-ord:OrderResponse.

For attribute epo-ord:hasDownloadURL, the following definition was added: "Location where the resource can be downloaded".

ePO tickets 743 and 611 were described, answered and closed.

Discuss the mappings between fields from the TC440 Order Data model to ePO concepts.

Field BT-OHI-6 : The field represents a reference of the Order. We are going to delete the existing epo-ord:hasCustomerReference attribute, and turn it into a predicate connecting epo:PostAwardDocument to adms:Identifier.

Field BG-ADR: Question: Is this a Document, or a PostAwardDocument?

Field BG-IPSP: What role should we use for that? We should create the epo-ord:Invoicee role and not just use buyer as mentioned in https://docs.ted.europa.eu/epo-wgm/notes/2023-02-21-eord.html#_agenda.

Predicate epo:specifiesInvoicee was added.

Predicates epo:exposesInvoiceeChannel, and IndicatesInvoiceeContactPoint from epo:Buyer were removed.

Field BT-ODI-1-4-8

Field BG-ODT: the solution provided in the ePO Github issue #623 was explained.

ePO Github issue #767 was discussed and marked as completed for the fields:

Field BT-OTO-5 in Github Issue #696 was discussed, updated and closed.

Field BT-OL-6-5 should only be used in the Order Change. Was removed.

Field BT-OL-10 implemented as discussed in Github issue #766, and the solution provided was acknowledged by the Working Group.

Field BT-OL-11: It was decided to re-use attribute epo-ordhasAccountingCost at the level of the OrderLine.

Field BT-II-10-3: To create a GitHub issue to ask about the ItemNameCode. (Code for the item property according to a property code system)

Fields: BT-OAHI-10, BT-OCAREHI-10, BT-OCACOHI-10, etc. :It was agreed that we shall use attribute epo:hasAdditionalInformation at the level of epo:Document for these fields.

The diagrams for the OrderChange, OrderCancellation and OrderAgreement were presented:

Regarding Order Response:

To Reply to #695

Add a github issue for Item Property code.

Discuss the eOrdering module extensions:

The Order Cancelation diagram was developed, containing the new Classes epo-ord:Cancellation, epo-ord:OrderCancellationRejection and epo-ord:CancellationConfirmation as seen on the diagram below:

OrderAgreement: The Working Group struggled to understand this concept, and what is the difference with Order. After consulting PEPPOL’s OrderAgreement data model, the Working Group concluded that Order Agreement is an alternative Order.The diagram for the Order Agreement is displayed below:

Predicate epo-ord:comprisesOrderLine, linking epo-ord:Order to epo-ord:OrderLine became epo-ord:comprises in order to be used by all subclasses of epo-ord:Order and epo-ord:OrderLine.

epo-ord:hasStatus was added at the level of epo-ord:OrderLine so it can be referenced by the epo-ord:OrderChangeLine if needed.

Classes epo-ord:OrderChangeRejection and epo-ord:OrderChangeConfirmation were added as seen in the diagram below:

Discuss the Following Github Issues:

Issue #744 was discussed: Attribute epo:hasCalculationMethod was added to the class epo-cat:EnvironmentalEmissionInformation.

Issue #730 was discussed:

Issue #722 was discussed: The expert for the Catalogue concepts was pointed to the issue for review.

Issue #549 was discussed: epo:hasProcurementScopeDividedIntoLot Definition was updated to: “Defines Lot”.

Issue #605 was discussed: it was agreed to remove attribute epo:hasOJSType and change the datatype for epo:hasOJSIssueNumber from xsd:integer to rdf:PlainLiteral

Issue #662 was discussed: Since in eForms, the Subcontractors are referenced at the level of the Organization, as of ePO 5.0.0 the following implementation is adopted:

Issue #610 was discussed: The name of the concept epo:VehicleInformation was changed to epo:CleanVehicleDirectiveInformation as depicted below:

Issues #743 and #443 were discussed: epo-ord:hasAcceptanceStatus was renamed to epo-ord:hasResponseStatus.

Issue #623 was discussed:

Create a ticket to get all the values that are relevant to procurement that the at-voc-new:document-type code list contains.

Fix Issue #623 and create another issue about Document status if needed.

Discuss epo 5.0.0 github issues.

epo:hasCurrency cardinality was changed from [0..1] to 1.

epo-cat:hasTaxScheme cardinality was changed from [0..1] to 1.

Properties epo-ful:hasOnCarriageShipmentStage and epo-ful:hasPreCarriageShipmentStage were deleted.

Property epo-ful:hasMainCarriageShipmentStage was renamed to epo-ful:hasCarriageShipmentStage.

Definition of epo-ful:hasCarriageShipmentStage was modified to: "The Shipment Stage for the last mile covered in a transport chain."

The main question is, if from a Business point of view, the Financing and Payer party should be at the level of epo:LotResult or at the level of the Result Notice.

They were put on the epo:LotResult Level because not all Lots mentioned in a Result Notice are always awarded.

It was discussed that this issue could be treated in ePO 5.1.0.

Finally, it was agreed that epo:BudgetProvider and epo:PaymentExecutor should be mapped using epo:AgentInRole epo:conceptualisedBy epo:Lot. It can also be used for a epo:PlannedProcurementPart and epo:Procedure since they all are subclasses of epo:ProcurementElement.

Field OPT-093-Review: An Identifier for a Review. It was not defined well, and no one has used this as of now (no data).

Fields OPA-36-Lot-Number, OPA-98-Lot-Number, OPA-36-Part-Number: These are Attributes of other fields currently not in use in eForms. They were designed to hold a number, but were discarded because eForms typically uses 2 fields to do this: One field has the measure and is coupled with another field that has the unit value.

Another option is to rename epo:hasScopeDividedIntoLot to epo:aggregatesLot.

The issue was left open to be discussed in a future WGM.

There was a second request in the ticket:

A a number of attributes and Predicates were moved from the level of epo:ProcurementObject and epo:Lot, to the level of epo:ProcurementElement, in order to them usable by epo:PlannedProcurementPart.

A more detailed explanation on the changes will be given as a comment of Issue #764.

To discuss #765 with the eForms team.

Discuss new Github Issues related to eForms.

After checking eForms fields BT-808 and BT-807, predicate epo:specifiesReviewRequester was added on the level of epo:ReviewDecision.

Maybe in the future we can replace predicates epo:specifiesReviewer and epo:specifiesReviewRequester with just an epo:specifiesRole predicate.

Class epo:ReviewInformation was created.

Predicate epo:relatestoEFormsSectionIdentifier was added with domain epo:ReviewInformation and range adms:Identifier.

Attribute epo:hasElementReference was removed from epo:Document and added to epo:ReviewInformation.

Predicate epo:resolvesReviewRequest was renamed to epo:answersReviewRequest.

Indeed code list at-voc:received-submission-type seems to be redundant.

All the values of the code list were analysed and it was made sure that for each value of the code list there is an attribute on class epo:SubmissionStatisticalInformation that represents it.

The codelist at-voc:received-submission-type was removed.

epo:ProcedureSpecificTerm, epo:ContractSpecificTerm and epo:LotSpecificTerm classes were deleted and all terms that were specialisations of these classes are now specializations of epo:Term.

However, there are diagrams that show different points of view of specific terms. Eg, all the terms that were under epo:ProcedureSpecificTerm appear on a specific diagram as seen below. To discuss the business value for these diagrams in the future.

To create a diagram with all the relationships of epo:LotGroup

Discuss new Github Issues related to eForms.

The problem with the ticket is that apparently the ND-ModificationSection is repeatable.

The Modification Justification Vocabulary was consulted.

A possible solution would be to extend the cardinality for the predicate (referring to Modified Notice Part Reference).

A use case was given: When the publications office changed name to OP, all the contracts had to be amended.

Predicate’s epo:relatesToEFormSectionIdentifier linking epo-con:ContractModificationInformation to adms:Identifier. cardinality was changed from [0..1] to [0..*].

Issue #758 was discussed:

Issue #755 was discussed:

It was discussed whether that attribute epo:isProcurementDocumentRestricted of class epo:AccessTerm is needed, because it can be inferred from the Ontology.

Reviewing and refining ORSD for eAwarding.

Questions about selected GitHub tickets. Discussions

A question was raised regarding outstanding GitHub issues that were to be prepared by the mappings team. It was clarified that the tickets had not yet been prepared.

The activities description for eAwarding ORSD was discussed.

The participants worked on the ORSD for eQualification module.

It was determined that the Call for Competition corresponds to the CompetitionNotice and appears to already be covered.

The use cases and natural language statements that were initially created for eAwarding were transferred to the ORSD for eQualification.

The eAwarding use cases and natural language statements were revised.

The possibility of releasing a patch was discussed regarding ticket #476. It was noted that the ticket does not clearly specify the nature of the bug. A question was raised regarding why the ticket is included in the scope of version 5.0.0.

Ticket #711 was reviewed. It was noted that a decision had already been made during a past meeting.

Ticket #374 was analysed. It was stated that the issue is not of concern if it is harmless. Nonetheless, a suggestion was made to remove the attributes mentioned in the ticket if they do not serve a specific use case. A decision was made to remove these attributes, and the decision was documented in the ticket.

GitHub issue fixing for “aux: mapping” label.

“aux: mapping” label

TC440 Order data model latest updates were discussed Specifically it was asked that the ePO team:

During the discussion, it was mentioned that the Quotation concept is not different from a Catalogue.

Account for all open issues with milestone ePO 5.0.0

Pre-award Catalogue

eAwarding

eRequest

epo-cat:ProductSpecification was moved on the level of epo:Document and not epo-cat:PostAwardDocument.

At-voc-new:document-type was moved to the level of epo:Document.

Predicate epo-cat:hasDocumentType was renamed as epo:documentUsedInPublicProcurement

Attribute epo-cat:hasHazardousClass of class epo-cat:AbstractItem was removed

Predicate Epo-cat:hasHazardousClassID was created with domain epo-cat:AbstractItem and range adms:Identifier.

Attribute epo-cat:hasClassificationCode [0..1] was added at the epo-cat:ItemProperty.

Predicate adms:identifier with domain epo-cat:ItemProperty and range adms:Identifier was added.

As seen in the diagram below,Class Epo:ProcurementDocumentsProvisionLine was created.

PreAwardCatalogueRequestLine was added.

Create Github issues for 5.0.0:

Close 623 github issue.

to Investigate the reasoning behind the use of “ procurement documents provision” naming and not ”call for tenders”.

eAwarding

eRequest

GitHub issue fixing for “aux: mapping” label

During the meeting, the 'request for offer' diagram was discussed, and expanded.

Regarding the above diagram, the following notes were made:

Regarding GitHub issue fixing for “aux: mapping” label:

eAwarding

eRequest

During the meeting, the eRequest ORSD was developed.

During the meeting, the eAwarding ORSD was further developed.

The Award Decision Notification diagram for the eAwarding module was presented and expanded. By the end of the WGM the diagram looked like this:

In the above diagram epo-awa:AwardDecisionNotification was defined.

AwardDecision Attribute hasAdditionalNonAwardJustification became hasAwardJustification.

Fill in the rest of the eRequest ORSD Fill in the rest of the eAwarding ORSD

Create a github issue: To look and check for the semantic wording for all the classes in the Ontology that have a composite naming.

Model the Qualification Resolution found here: https://docs.oasis-open.org/ubl/os-UBL-2.4/mod/summary/reports/UBL-TendererQualificationResponse-2.4.html#Table-QualificationResolution.Details

Model the TenderReceipt: Model the https://docs.oasis-open.org/ubl/os-UBL-2.4/mod/summary/reports/UBL-TenderReceipt-2.4.html

ESPD

eRequest

Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

It was mentioned that information such as the one mentioned in the ticket should be Additional Information.

It was decided this should not be of class cccev:Evidence, as it is currently modeled and it should be modeled differently.

There is a need for a superclass other than Evidence.

It is a request for an offer in a Framework agreement, and its response. It is also related with mini-competition.

Class epo:ReviewObject was removed.

Attribute epo:hasNumberOfReviewRequests of class epo:ReviewRequest was removed.

Attribute epo:hasRequestDate of class epo:ReviewRequest was removed.

Attribute epo:hasDecisionDate of class epo:ReviewDecision was removed.

Class epo:ReviewRequest became a specialization of epo:Document.

Class epo:ReviewDecision became a specialization of epo:Document.

Predicate epo:specifiesReviewRequester [0..1] with domain epo:ReviewRequest and range epo:ReviewRequester was added.

Predicate epo:specifiesReviewer [0..1] with domain epo:ReviewDecision and range epo:Reviewer was added.

Attribute epo:hasElementReference xsd:anyURI [0..*] was added to class epo:Document.

Attribute epo:hasNumberOfReviewRequests xsd:integer [1] was added to class epo:ReviewRequestSummary.

Predicate epo:announcesReviewObject [0..*] with domain epo-not:CompletionNotice and range epo:ReviewObject was removed.

Predicate epo:refersToReviewRequest [0..*] with domain epo-not:CompletionNotice and range epo:ReviewRequest was added.

Predicate epo:announcesReviewObject [0..*] with domain epo-not:ResultNotice and range epo:ReviewObject was removed.

Predicate epo:announcesReviewRequest [0..*] with domain epo-not:ResultNotice and range epo:ReviewRequest was added.

Create github issue for TED mappings repository informing for the changes done in this WGM regarding the review concepts.

eAwarding discussions

Unique Responsible of the Procurement – played by a Person; it is part of the Buyer’s Organization (the head of the Organisation; the person that has the final decision)

Buyer

Tenderer

Winner

Candidate

eFulfilment Receipt advice data model.

Further Questions regarding the fields of the Receipt advice data model were answered.

Add a Github Issue about renaming that highlighted property seen in the diagram above in order to cover for the parts mentionerd in the https://github.com/OP-TED/ESPD-EDM/issues/413 depicted in the figures below. A possible name could be epo:canProvideEvidence Also the attribute coversAllSelectionCriteria should be at the level of the evidence.

Create a Github Issue to implement Object Line Identifier with the predicate SalesOrderLineID.

Add a Github Issue about renaming that highlighted property mentioned above.

eAwarding ORSD

#423:

#413

Alignment with PEPPOL for eFulfilment #569.

Alignment with PEPPOL for eFulfilment #569.

Create a Github Issue: Harmonize all post award document classes such as despatch advise to use
The epo:associatedWith rather than a direct link to an epo:Document.
Also add a link from the lines to a document.

Create a ticket This at-voc-new:RespoonseStatus should be renamed and aligned with https://docs.peppol.eu/logistics/2024-Q1/codelist/UNCL4343_T128/

Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

BT-776 did not have any impact on the Ontology.

BT-810

BT-811

Create two diagrams in ePO (1 for competiton and 1 for Lot-result) for epo:EnergyEfficiencyInformation class.

813 and 814 are paired.

BT-814 :

eFulfilment meeting regarding Receipt Advice.

Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]

Phttps://github.com/OP-TED/ePO/issues/529[otential problem with modelling of epo:Period ]ePO #529

Mapping of at-voc:timeperiod to the OWL Time Ontology ePO #681

Examples of T01 , and T02 eForms were given to the WGM.

Regarding the following fields: Τhey are just for T02 and are about a Tender, so they should be put in a class on the level of epo:TenderAwardOutcome. This class should be named epo:TenderAwardOutcomeInformation. Another class: epo:ContractCondition was added.

BT-127-Notice:No modification will happen for now.

Create a Github issue: For the Receipt Advice ePO diagram: To represent the action-code and reject-reasons codelists also at the level of the epo-ful:ReceiptAdvice.

Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

An example of a Call For Expressions Of Interest document was presented (F_CEI_EN_DRAFT_2019-03-25.pdf). The ePO team used the document to create a CM diagram for Call For Expressions Of Interest.

The latest Notice-types.json eforms document was consulted.

Class epo-not:PINTransportationNotice was created as seen on the diagram below.

Class epo-not:CANTransportationNotice was created as seen on the diagram below.

It appears that class epo-not:CallForExpressionOfInterest was already implemented in the ePO as epo-not:NoticeCEI. To discuss the removal of epo-not:CallForExpressionOfInterest in a future WGM.

The Customer-service codelist was found and does not currently exist in ePO and will be added.

It was mentioned that For T02 and T01, epo:LotGroup is Forbidden

Class epo:QualityTargetInformation was created; it should always be linked to an epo:ContractTerm.

at-voc:customer-service was created on the level of epo:QualityTargetInformation. They are both mandatory.

Attribute epo:hasQualityTargetDescription was created.

OPP-020-Contract: Assets related contract extension indicator. Class epo:Asset was created.

OPP-021-Contract: Used asset Added dct:description [0..1] for epo:Asset.

OPP-022-Contract: Significance (%): Added attribute epo:hasSignificance rdf:PlainLiteral. To be further discussed as concept name may change in the future

OPP-023-Contract: Predominance (%): Added attribute epo:hasPredominance rdf:PlainLiteral. To be further discussed as concept name may change in the future

EPO team to look at the F_CEI_EN_DRAFT_2019-03-25.pdf

Document and Investigate actual T01,T02 and CEI Notices to confirm that the new ePO diagrams including attribute types are correct.

To discuss the removal of epo-not:CallForExpressionOfInterest Class on 28/01/2025 WGM.

Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

Alignment with PEPPOL for eFulfilment #569.

Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Potential problem with modelling of epo:Period #529

Mapping of at-voc:timeperiod to the OWL Time Ontology #681

BT-749: It was discussed that although BT-749 was removed from the regulation, no removal of an ePO concept was needed.

BT-681: An attribute for epo:ProcurementElement was added for this. epo:appliesForeignSubsidiesRegulation xsd:boolean[0..1]

BT-682 should be implemented as the foreign Subsidy Measure Conclusion vocabulary connected to Class epo:TenderAwardOutcome as a codelist, using the predicate epo:specifiesForeignSubsidiesMeasureConclusion.

A use-case is required to find out in what procurement phase should this codelist be used. This will be done in the future as part of describing the Procurement Process. A link to the Digigrow guide on how to use this codelist was provided: https://code.europa.eu/eproc/eforms/docs/-/blob/main/guides/gde_001_fsr.md?ref_type=heads

BT-684: It was decided that this BT will not be implemented for now.

BT-681 : Should points to epo:LotAwardOutcome. .

BT-685 is for the Tender. There is currently no codelist for this. It should go directly to the epo:LotAwardOutcome class. (via the epo:InternationalProcurementInstrumentMeasuresInformation Class seen in the diagram below)

BT-686 : Attribute epo:hasNumberOfTendersConcerned as seen in the diagram below.

BT-687 : at-voc:international-procurement-instrument-application As seen in the diagram below.

BT-688 :Attribute epo:hasPublicInterestExceptionJustification as seen in the diagram below.

The International Procurement Instrument Application vocabulary was consulted. It was mentioned that the Digigrow guide (link above) better explains the above mentioned BTs.

It is important to note that these IPIs are for third world countries or Tenders that have third country subsidiaries.

Lot tenderingTerms Fields were discussed:

Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

The following IDs are mandatory in UBL but not required in eForms, so there is no need to map them to ePO either for Lot or Part:

The following Classes were implemented: (also depicted on the diagram below) For the following fields:

#691