F20: Delete `epo:refersToLot` relation originating from the Notice instance

[csnyulas]

In ContractModificationNotice, generated from form F20, remove the epo:refersToLot relationship linking a Lot instance to the Notice instance. This is unnecessary (because one can get to the lot through the Notice epo:announcesContract Contract epo:includesLot Lot property path), and in case of the ContractModificationNotice it is also conceptually wrong (as epo:refersToLot should be used only on ResultNotices).

[csnyulas]

Closing this, as the solution, and the generated output have been checked, and they are correct.

[muricna]

@csnyulas @costezki According to version 2.1.1.rc1 the conceptual and technical mapping still goes through Notice refersToLot which is not in line with the ontology.

[csnyulas]

Indeed, there was a mistake in 2.1.1.rc1, as we removed the wrong row ("epo:Procedure epo:hasProcurementScopeDividedIntoLot epo:Lot" instead of "epo:Notice epo:refersToLot epo:Lot") from the Conceptual Mapping of F20 . However, the technical mapping was correct. I.e. there is no relationship epo:refersToLot between the epo:Notice and epo:Lot instances in any of the F20 outputs. As specified in the description of this GH issue, the problem was discovered in F20, which used to have the epo:refersToLot relationship between epo-not:ContractModificationNotice and epo:Lot instances, although, according to EPO 3.1.0, the epo:refersToLot relation links only the epo-not:ResultNotice class to the epo:Lot class.

So, this issue was not about removing the epo:refersToLot relation between all epo:Notice and epo:Lot instances, therefore, removing the relation in other forms, such as F03, F06, etc. was not necessary. As long as they are of type epo-not:ResultNotice. It is true that our solution is incomplete, as in case of some forms that can represent also notices that are not of type epo-not:ResultNotice, e.g. epo-not:PlanningNotice or epo-not:CompetitionNotice (such as forms F21 or F22), we still create this relationship. However, those were not covered by the scope of the current mappings, and will be fixed later.
I created a separate issue for that: #430