Working Group meeting 21/01/2021

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Veit Jahns (TC440), Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: eCatalogue

  • The WG started summarising the last meeting on eCatalogue. Here the diagram produced on 12th January:

  • The WG discussed on not to have in this diagram the ProcurementSituation class and to have just the specialisation of this class named ProcurementSituation. The problem is that hiding the ProcurementSituation class some properties will be also hidden. The WG analysed if the class linked exclusively to ProcurementSituation are also needed for the CatalogueSituation.

  • The WG simplified the eCatalogue diagram just leaving on it those classes that are needed for eCatalogue.

  • In order to represent in the model that a CatalogueSitatuion has a CatalogueReceiver, two classes were connected through the property epo-ecat:hasCatalogueReceiver with cardinality 0..*. This new property is a subproperty of the property "epo:hasRole" which links the ProcurementSituation to the epo:Role;

  • The WG also said that a CatalogueSituation has always a Catalogue, therefore the two classes were connected through the property epo-ecat:hasProvidedCatalogue with cardinality 1.

  • The class Contract was also added in the diagram and linked to the CatalogueSituation class. As well, the FrameworkAgreement.

  • The WG discussed whether the ProcurementSituation should be refersToLot. The WG remove the relation from the Lot class to the ProcurementSituation because the decision was that the Lot class is an owl:Thing class and the ProcurementSituation epo:hasContext owl:Thing.

  • The WG saw that the properties from Contract to Period are wrong. A Contract does not have a DurationEvaluationPeriod. It is the Lot which has the DurationEvaluationPeriod. Also, the property that links the Lot to the Contract is wrong (hasContractDuration). The WG modified the issue #267, https://github.com/eprocurementontology/eprocurementontology/issues/267 regarding this particular point.

  • Continuing with the eCatalogue model, the WG decided to add the class owl:Thing to the eCatalogue UML diagram. The Catalogue class is also a specialisation of the owl:Thing.

  • The Catalogue was linked to the Contract through the property epo-ecat:isSubordinatedTo.

  • The property epo-cat:hasCatalogue (epo-cat:CatalogueSituation - epo-cat:Catalogue) is a subproperty of the epo:hasContext (epo:ProcurementSituation - owl:Thing).

  • The WG saw that some important aspects need to be documented in the Reification documentation.

  • The Period class was also dropped in the diagram and linked to the Catalogue. The property name is epo-cat:hasValidity.

  • The WG decided that the ContactPoint will be reviewed and discussed later. The WG does not have a clear idea of whether Contact Points are actually needed in the context of eCatalogue transactions. TBD.

  • The discussion ends with the following version of the eCatalogue diagram:

Topic of discussion: Definition of Catalogue Provider * The WG worked on the definitions of the following terms based on the definitions provided by TC440 (taken from TC440, UBL, and PEPPOL): > * CatalogueProvider: A role of an agent compiling and supplying a catalogue.

Additional Information

The catalogue provider role is usually played by the agent that acts as a seller, or by another agent that acts on behalf of the seller.

WG Approval 28/01/2021