The relation hasProcurementScopeDividedIntoLot seems strange because one of the prequreistes of the ontology is that all procedures have at least one lot.

We need to explain to users that there is no mapping to II.1.6.1 it is resolved by a query, however the point on hasProcurementScopeDividedIntoLot needs also to be addressed

In the forms indicating joint procurement is not compulsory so if it is not in the xml it does not exclude that joint procurement does not exist. Therefore for example in 163-2021 we cannot assume joint procurement does not occur. Joint procurement cannot be calculated by having many buyers in the procedure see recital 71 of the Directive 2014/24/EU:

Joint procurement can take many different forms, ranging from coordinated procurement through the preparation of common technical specifications for works, supplies or services that will be procured by a number of contracting authorities, each conducting a separate procurement procedure, to situations where the contracting authorities concerned jointly conduct one procurement procedure either by acting together or by entrusting one contracting authority with the management of the procurement procedure on behalf of all contracting authorities.

The field in xml is not a compulsory field so we may draw no conclusions except that joint procurement occurs if it is indicated

I would suggest the mapping from the xml is: if true then in rdf it is also true but if not mentioned in the xml then it should not be mentioned in the rdf

If joint procurement is concerned then all Buyers may or may not be jointly responsible for a given procedure and may or may not be bound by a contract. However in a notice we do not know to which extent a Buyer is involved in a joint procurement. Therefore we cannnot assume "Contract bindsBuyer" is correct the only thing we can assume is that the Procedure involves all the Buyers.

An example of Contract bindsBuyer can be seen in notice 2705-2021.

Therefore it seems this relation is inappropriate in the rdf

In the package/transformation/resources the json files of the authority tables can be found but they are the full authority tables from EU Vocabularies, however the forms do not necessarily use all the concepts found in EU Vocabularies.

For example if we take :

• buyer-legal-type for F03 we only use 6 concepts of the 22 concepts in EU Vocabularies.
• main-activity for F03 we only use 10 concepts out of 21 concepts in EU Vocabularies ( and in other forms the concepts that will be used will be different.

•V.2.13 The mapping in the rdf does not map to the code list as indicated in the mapping excel:
?this epo:playedByBusiness / epo:hasBusinessSize http://publications.europa.eu/resource/authority/economic-operator-size](http://publications.europa.eu/resource/authority/economic-operator-size)

In the rdf there is a boolean.

See example 2705-2021 where it indicates that the Winner is not a business which would be false in this case.

The total value of the contract is mapped to (example 163-2021)

The lowest offer and the highest offer taken into consideration are mapped to ( example 2750-2021)

I have some concerns about the usage of Tender here, especially if negotiations are involved. In the case of the total value in the best case scenario one could argue that the tender value has changed but we have a temporal problem here. However taking the LowestReceivedTenderValue from the SubmissionStatisticalInformation does not seem correct.

In the excel file:
Rules Sheet:
Cell B4
Should read Contracting Authority and not Contracting Entity.

This field will change depending on the Form and Legal Basis. In the case of F03 it should be Contracting Authority

Maybe they are not needed in the ontology as we use the country code.

Tenderer is not used in the notice or the mapping why and how is it instantiated ?

There needs to be a clear documentation explaining how this is implemented. If the answer is no in the xml how should this be interpreted in the rdf? There probably needs to be a general information both inside and outside the excel. One use case could be how many procedures are awarded to a group of economic operators?

When no information is provided for this field in the xml the rdf cannot show the boolean as false see 163-2021

Before finding LotAwardOutcome the usage of this authority table and how to describe the award or not of a contract was not clear

The Publication data I take it will be in the metadata and not the content of the Notice. However the ontology sees it in the Notice class. Since the PPDS needs the Publication Date maybe we should add it in the mapping?

In 131568: Award of Lots muddled and therefore winners financial offer etc attributed to wrong lots. See summary below showing a few of the URI relations:

In the excel the mapping is Lot hasDescription.

However it is missing in the rdf see example
348503-2021

Although the rdf gives the correct weighting the excel file shows cccev:name instead of cccev: weight

The mapping for this element in the excel is:

However in the ontology I see:

I think this section is at Procedure level the mapping indicates it but the ontology indicates at lot level. If this is at lot level is then repeated in each lot?

The xml shows a contract number in the xml however no contract was awarded. The contract number is not provided in the rdf however the rdf is supposed to represent the xml should such corrections be made to follow the ontology?
See 131568-2021 Lots 4 and 5
This also means we are missing the tiel in teh these sections too

http://data.europa.eu/a4g/resource/LotAwardOutcome/2021-S-052-131568/a5941b75-32bc-31c2-a76d-5d5d8bda3d9f
a epo:LotAwardOutcome;
epo:comprisesTenderAwardOutcome http://data.europa.eu/a4g/resource/TenderAwardOutcome/2021-S-052-131568/a586ea4c-6836-37c0-99f5-aa2a3e69d886;
epo:describesLot http://data.europa.eu/a4g/resource/Lot/2021-S-052-131568/a7bff5a3-ac28-3c67-b4c6-67f990704217;
epo:hasAwardStatus http://publications.europa.eu/resource/authority/winner-selection-status/selec-w .

http://data.europa.eu/a4g/resource/Lot/2021-S-052-131568/a7bff5a3-ac28-3c67-b4c6-67f990704217
a epo:Lot;
epo:hasID <http://data.europa.eu/a4g/resource/LotIdentifier/2021-S-052-131568/a7bff5a3-ac28-3c67-b4c6-67f990704217>;

http://data.europa.eu/a4g/resource/LotIdentifier/2021-S-052-131568/a7bff5a3-ac28-3c67-b4c6-67f990704217>
a epo:Identifier;
epo:hasIdentifierValue "5" .

There seems to be a muddle in the non-awarded lots when there is more than one lot

There is an inconsistency here the Review body hasPrimaryContactPoint is missing from 348503-2021 and therefore the internet address is missing however the hasPrimaryContactPoint is present in 163-2021 maybe due to it having other elements and not just the internet address.

I do not understand row 85 of excel file.
This section is about the procedure why do we have hasScopeDividedIntoLots by definition all procedures have at least one lot according to the ontology

Data missing in rdf see example 348503-2021

Does the absence of an OrganisationGroup imply that the contract has not been awarded to a group of economic operators. If so this needs to be clearly indicated somewhere like the fact of lots existing when there is only one lot. It also probably needs to be noted that winner is used instead of contractor.

This concept is found under hasContractSpecificTerm and relates to an authority list not listed in transformation resources. it is visble in other lots as well of other notices

See 19698-2021.
This could be due to the fact that the winner is associated to a tender rather than lot it is possible to provide the winner from the lot rather than the tender (which should probably not be instatiated in the notice as the notice does not mention a tender or tenderer). See association of lot and winner (via LotAwardOutcome) in the diagram below:

When this field is empty in the xml it cannot have a boolean of false in the rdf see 163-2021

See example 19698-2021

See 2705-2021
Maybe the mapping does not foresee the award criteria without weightings but it is a real case

Why is ReviewTerm a LotSpecificTerm?Is this due to eForms if this is the case is it repeated for each lot in the rdf for the current forms?

Need to check different examples. I think often the address of the procurement department will be given not that of the organisation as a whole

missing buyer-legal- tupe19698-2021: The concept in the xml is "other" which is not in the authority table buyer-legal-type. Therefore there should also be a description which is not foreseen in the ontology

What is more the ontology states Organization hasLegalType and the mapping hasBuyerType so there are inconsitencies where the mappings exist.

Also the authority table is floating in some of the diagrams of the ontology

The buyer-legal-type mapping in resources does not foresee the xml element "other"

Is it normal that the URI of different concepts have the same ending see 2705-2021

ResultNotice URI
http://data.europa.eu/a4g/resource/ResultNotice/2021-S-002-002705/58509ec4-99dc-3865-9935-58d7ebd66d29
Procedure URI
http://data.europa.eu/a4g/resource/Procedure/2021-S-002-002705/58509ec4-99dc-3865-9935-58d7ebd66d29

As foreseesContractSpecificTerm is missing in the lots there is no place of performance or options element.

19698-2021 has lots also but does not have this problem

I think the main address URL should be of the organisation not the contact point.

In sections II.1.2. and II.1.2.1 both the Main CPV code and the Supplemenatary CPV code should use the predicate hasMainClassification.

In Sections II.2.2.1 and II.2.2.2 both Main CPV code and the Supplementary CPV code should use the predicate hasAdditionalClassification

Also to be noted is the Supplemenary CPV is missing from the ontology probably due to the fact that it is not used in eForms

II.2.2.1 only one code shown see 348503-2021 also 337360-2021

The mapping has SubmissionStatisticalInformation should be associated to each lot which is not the case see for example 19698-2021

Although the form type is in the metadata of the xml it would make searching in the rdf files more efficient if they included the form type. For current forms ie F03 for the eForms the notice subtype ie 1, 2, 3 etc so some alignement needed

The xml does not foresee an indentifier for the Review body, however the rdf foresees and idenfier and copies the name of the reviewer into the identifier there should be no identifier see348503-2021
The same for Mediator and ReviweProcedureInformationProvider see 56148-202&

Why do for the RDF file for the Reviewer, Mediator and the ReviewProcedureInformationProvider all have an ID which is the same as the name of the organisation?

See 2705-2021 which has no ID for these elements in the xml;

Is this correct to map to the tender for example in the case of a negotiated procedure

A mappin was done to:
all-rej: All tenders, requests to partipate or projects were withdrawn or found inadmissible.

However the xml does not cover withdrawl but does cover:
No tenders, requests to participate or projects were received.

How to map this elment needs to be discussed.

Also in such cases the tender is not instatiated when there could have been a tender, this is another reason for not instantiating the tender because it can not be coherently instantiated. However it is needed for instantiating the foreseesSubcontracting

See examples in 19698-2021

The excel maps correctly to the authority table economic-operator-size however the rdf shows a boolen see 348503-2021

In the rdf (ie in 2705-2021) I notice in the URI there is 1 Buyer and several Additional Buyers, however the rdf:type is Buyer.
Neither in the excel nor in the ontology do I see the concept AdditionalBuyer.

Will the fact that the resource path is different for the different Buyers be ignored ie will this fact have any impact on the meaning of the concept?

It was previously stated
• When having one Buyer, we link main activity & legal type to the organisation of this Buyer
• If we have additional Buyers (many buyers), we need add an Organisation Group: The group hasMember all the organisations (Main & Aditional) and the MainActivity/BuyerLegalType are at the Group Level.

We have no indication in the notices who is the main and who is the additional Buyers.

Further more their is a relationship Contract bindsBuyer we cannot be sure from the notice that the Contract binds the buyer it only binds the buyer that signs the contract not those that may use the contract

The mapping of the NUTS code is via a predicate hasSpecificPlaceOfPerformace however I think this is reserved for the "main place of performance"
The ontology also forsees hasBroadPlaceOfPerformance also via "ContractTerms" which is better suited to the NUTS however it points to another code list

This concerns the description of the lot.
In notice 2705-2021 there is only one lot as the ontology defines all procedures should have at least one lot however this information is missing.

The field in xml concerning the award of a contract by a cpb isnot a compulsory field so we may draw no conclusions except that it is awarded by a cpb when it is indicated as such in the xml.

I would suggest the mapping from the xml is: if true then in rdf it is also true but if not mentioned in the xml then it should not be mentioned in the rdf ie no false indicator as per 373713-2021

In case of true see: 214679-2021