tx1-2: notice type handling

[costezki]

[N Muric]

In notices covering Contract Award Notices and other types of notices, the mappings are made in each case to the Result Notice which creates a wrong mapping to the other types of notices

[costezki]

In F21, F22, F23 Forms, we will use the type attribute in element when present.

The following correspondence rules will be used

award_contarct -> epo:ResultNotice
contract -> epo:CompetitionNotice
concession_award_contract -> epo:ResultNotice
pri_call_competition -> epo:CompetitionNotice
pri -> epo:CompetitionNotice

Note: "qualification system" and "periodic indicative notice" shall be considered as well as they are needed in F22

F13, which does not have a notice type, will be mapped to epo:ResultNotice.

[csnyulas]

AFAICT, Qualification systems can be recognized from the presence of one of the following XPaths:
LEFTI/QUALIFICATION,
OBJECT_CONTRACT/OBJECT_DESCR/QS/,
OBJECT_CONTRACT/OBJECT_DESCR/RENEWAL, and
OBJECT_CONTRACT/OBJECT_DESCR/RENEWAL_DESC

Is checking for this XPaths is sufficient to identify if a notice is regarding a Qualification System?
Can it happen that all these fields are missing and still be a notice about a QS?
Is there a better, more secure, way to identify that a notice is a QS, based on the information available in the XML, than checking for these XPaths? The TYPE attribute of the NOTICE element does not seem to give us any indication about this.

Is there a specific class, or a single (dedicated) property in EPO that can be used to identify a QS, or it is checked through the presence of any of these properties: epo:hasQualificationSystemDuration, epo:hasQualificationSystemPeriod, epo:hasQualificationSystemRenewalDescription ?

[csnyulas]

Note that the epo:Notice instances created from forms that don't have the "NOTICE TYPE" attribute, should also get a second type (a subclass of epo:Notice), based on the main nature of the form. For example, for F03, F06, F25 and F13 it will be epo:ResultNotice, while for form F20 it will be epo:ContractModificationNotice.

[csnyulas]

Other Notice type values to be mapped (all collected from our sample data):

Form F01:
<NOTICE TYPE="PRI_CALL_COMPETITION"/>
<NOTICE TYPE="PRI_ONLY"/>
<NOTICE TYPE="PRI_REDUCING_TIME_LIMITS"/>

Form F04:
<NOTICE TYPE="PER_CALL_COMPETITION"/>
<NOTICE TYPE="PER_ONLY"/>
<NOTICE TYPE="PER_REDUCING_TIME_LIMITS"/>

Form F07:
<NOTICE TYPE="QSU_CALL_COMPETITION"/>

Form F21:
<NOTICE TYPE="AWARD_CONTRACT"/>
<NOTICE TYPE="CONTRACT"/>
<NOTICE TYPE="PRI_CALL_COMPETITION"/>

Form F22:
<NOTICE TYPE="AWARD_CONTRACT"/>
<NOTICE TYPE="CONTRACT"/>

Form F23:
<NOTICE TYPE="CONCESSION_AWARD_CONTRACT"/> 
<NOTICE TYPE="PRI"/>

[csnyulas]

In addition to the above, in other samples we also found:
<NOTICE TYPE="QSU_ONLY"/>

This also answers the question for how to identify "Qualification systems" and "Call for competition for Qualification systems" (with notice type QSU_ONLY and QSU_CALL_COMPETITION). These are the values that we should map for F22, for example, despite the fact that it does not appear in our test data.

BTW, the fourth possible notice type for F21 is "PRI_ONLY" despite not appearing in out test data.

This ticket can be marked fixed for the purpose of addressing the TX1.2 feedback, but before we can close it, we should also map the other notice value types, namely:

• PRI_ONLY
• QSU_ONLY
• QSU_CALL_COMPETITION
  and preferably also the following ones, needed in future forms:
• PRI_REDUCING_TIME_LIMITS
• PER_ONLY
• PER_CALL_COMPETITION
• PER_REDUCING_TIME_LIMITS

[costezki]

PRI_ONLY  -> epo:PlanningNotice
QSU_ONLY -> epo:CompetitionNotice
QSU_CALL_COMPETITION -> epo:CompetitionNotice
PRI_REDUCING_TIME_LIMITS -> epo:PlanningNotice
PER_ONLY -> epo:PlanningNotice
PER_CALL_COMPETITION -> epo:CompetitionNotice
PER_REDUCING_TIME_LIMITS -> epo:PlanningNotice

if(../NOTICE/@TYPE='AWARD_CONTRACT' or ../NOTICE/@TYPE='CONCESSION_AWARD_CONTRACT') then 'http://data.europa.eu/a4g/ontology#ResultNotice' else 
if (../NOTICE/@TYPE='CONTRACT' or ../NOTICE/@TYPE='PRI' or ../NOTICE/@TYPE='PRI_CALL_COMPETITION') then 'http://data.europa.eu/a4g/ontology#CompetitionNotice' 
else null ";

[csnyulas]

Closing this, as it has been fully fixed. Opened an issue, #268, about implementing a potential improvement (related to performance an manageability) on the current solution.

[muricna]

In competition Notices according to the ontology the CompetitionNotice announcesRole and the ResultNotice refersToRole or in other cases announcesRole this is not reflected in the mapping. The same can be said for announcesProcedure and refersToProcedure.
The ontology should be informed that the Notice refersToProcedure predicate should be from ResultNotice
This comment applies to all of section I and it is up to the contractor to ensure the other sections are correct for other forms and for other classes such as Lot

[csnyulas]

Related to the last comment from @muricna: I created a separate issue for it (#326), because the problem described in the comment is different from what this issue was about. This issue is about attaching the appropriate Notice subclasses as a secondary rdf:type statement to the Notice instance. That has been fixed and tested, as can be seen in the linked commits. This is why we closed this ticket.
We will mark again this issue as Fixed, and further improvements/fixes will be addressed in issue #326.