Feedback F23 PIN (issue 4, TM): II.2 whole section is wrongly mapped as it is mapped to refersToLot which is the case for the ResultNotice

[valexande]

II.2 According to the ontology CompetitionNotice announcesLot. Therefore this whole section is wrongly mapped as it is mapped to refersToLot which is the case for the ResultNotice.

[costezki]

We will implement a TripleMap for each class: epo:Notice, epo:CompetitionNotice, epo:ResultNotice

[muricna]

Be careful note we also have the Contract Modification Notice F20 there is a similar point in the comments of F20

[muricna]

We will also need the Planning Notices. However the ontology does not cope with all the relations yet

[csnyulas]

To complement what @costezki said above, this is what we agreed we should do:

We should add the announces/refersTo properties related to both Lot and Procedure not at generic Notice level, but depending on particular subclass of Notices, as the following:

• epo:CompetitionNotices will use announcesLot and announcesProcedure
• epo:ResultNotices will use refersToLot and refersToProcedure
• Currently both epo:PlanningNotices and epo:ContractModificationNotices use refersToLot and refersToProcedure, and we will keep it like that until we find a more appropriate way of deciding what properties would be best in what cases.

@muricna will this solution be correct? Do you think it will work for all the 8 forms that we mapped so far?

On a related note: Regarding Roles, we are always using the epo:announcesRole property, because we realized that it would be extremely difficult to define the (possibly very complicated) conditions that would help identify with certainty the cases where a given role can be simply referred to, as it was (or must have been) announced in some previous notice(s).

[csnyulas]

Also related to #326