Working Group meeting 04/11/2021

Date: 04/11/2021
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
Note editor: Andreea Pasăre


  • Present where the recent WG notes are found

  • Go through the errors discovered by the constraints checker

    • Out of sync connectors types and roles

    • Attribute names for the Code lists

    • Missing target roles

    • Missing multiplicity

  • Elaborate on “has” relationship

    • epo:has (4)

      • epo:Address → epo:LocationCoordinate [0..1]

        • hasLocationCoordinate

      • epo:Subcontract [,0..*] ← epo:AwardDecision

        • hasSubcontract

      • epo:ContactPoint → epo:Channel [0..*]

        • hasChannel

      • epo:ProcurementRole → epo:ContactPoint [0..*]

        • hasContactPoint

  • How to reduce redundancy on code lists?

    • Either attribute→Code goes away

    • Or the relation to the enumeration goes away == (Future Agenda)

  • Go through the errors discovered by the constraints checker

    • Missing target roles

    • Missing multiplicity

  • Discuss the principles on specifying the cardinality constraints (in the model and in AP)

  • Present roles as adjunct instances

  • What shall be used as context?

    • Context / Situation / Frame / Event / Process / Organisation

    • Most likely the context nature differ by “groups of roles”

    • Also the context possibly differs by role participation (e.g. Buyer always participates) or role assignation (e.g. information provider is not participating but is assigned to offer information at some point in the future)

    • Also the context differs by the role types, for example organisational roles e.g. group leader, are different from participation roles.

  • Shall we capture the situation frames or not?

    • Set of participants vs situation of a single agent

    • Distinction between actual(factual & time bound) & future(obligation, possibility, necessity)?

    • Frame of the event vs event outcome

      • E.g. Award Decision vs Awarding Action

    • Example: Awarding

      • the party that is performing the awarding: “the awarder” / “buyer”

      • the party that is awarded: “the awardee” / “winner”

      • the lot being awarded: “the object”

    • Contract signing

      • the signee on the side of the buyer: “…​” / buyer

      • the signee on the side of the winner: “…​” / winner

      • the contract being signed: “the object” == Discussion

  • Presenting proposed eForms UML model. Business groups are sets of attributes used to describe entities of business types.

  • Presenting the WG meeting notes link to the group.

How to reduce redundancy on code lists?

In the model itself we can leave it as an attribute. When we do the actual mapping to eForms we should include the relationships.

Leave relationships and get rid of the attribute and update the transformation script. In the model, whenever such a relationship is found it should say that it is a code. In the SHACL shape we can say it has to be a Code or an enumeration.

Disadvantage: lose the automated generation of SHACL shapes that are precisely constraining on those code lists.

Some of the enumerations do not exist as AT tables. (~3-4)
at-voc: it means this is published by EUVOC
epo: it means it’s not published, but it might be after review.


  • The remaining “epo:has” relationships should be left to revise later. (hasLocationCoordinate, hasSubcontract, hasChannel, hasContactPoint)

  • Moving old WG meeting minutes from github to Ted Developer docs.

    • At some point in time

  • Write sub-notes for each WG meeting from the History page.

  • Move definition from attribute (epo:BuyerType) to relationship and add the URI of the controlled list. Add the URI to the enumeration as well.

The codelist to be used is at-voc:buyer-legal-type which is available at _[_]

  • Keep the enumerations and all their values (e.g. epo:notification-phases-content-types) documented in the model even if they don’t exist in EU-Vocabularies

  • Review the enumerations to check if they should be added by EUVOC.

    • At some point in time == Questions:

  • Should we ask EUVOC to add those missing AT for our missing enumerations? Yes, at some point in the future