Cumulative content of Working Group Meetings in 2021
Working group meeting 14/12/2021
Date: 14/12/2021
Participants: Hilde Kjølset, Natalie Muric
Model editor: Eugen Costezki
*Note editor: *Andreea Pasăre
Agenda:
-
Continue discussing a new approach on structuring ePO:
-
Present Situations, Roles, Notice taxonomy, Notice Content model.
-
Present an example of instantiation of the Submission/Awarding situation. === (Future agenda)
-
-
Continue discussing the attributes in the eCatalogue from GH Issue #284
-
Process control: Information about the specification that applies to the transaction.
-
Business process type identifier: Identifies the business process context in which the transaction appears. It enables the buyer to process the invoice in an appropriate way.
-
Specification identification: An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms. This identifies the European invoice norm, as well as any extensions applied. The identification may include the version of the specification.
-
Catalogue validity period: A time interval or a duration of a catalogue’s validity.
-
Contract reference: A reference to a contract the catalogue is based on.
-
Contract identifier: The identifier of the referenced contract.
-
Contract type: The type of a contract that is being referred to (such as framework agreement) expressed as a code.
-
Contract issue date: The date on which the contract comes into effect.
-
Contract subdivision: A relevant subdivision of the contract a catalogue refers to.
-
Discussion:
Giving the same presentation as the one from the last meeting, since some of the domain experts could not participate then.
Going through the set of roles features that were analyzed by the Working Group. Only some of them are relevant to the ePO.
The new approach: a Role is a class that is played by an Agent. We can not instantiate a Role without stating the Agent that is playing that Role.
Roles overview diagram:
Award Decision Situation diagram:
A situation is a relational context as shown in the below diagram:
All the terms that we already have in the ePO model are actually a description of a StipulatedSituationTerm.
Presenting an Awarding example at the instance level.
Working group meeting 14/12/2021
Date: 14/12/2021
Participants: Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
*Note editor: *Andreea Pasăre
Agenda:
-
Continue discussing a new approach on structuring ePO:
-
Present Situations, Roles, Notice taxonomy, Notice Content model.
-
Present an example of instantiation of the Submission/Awarding situation. === (Future agenda)
-
-
Continue discussing the attributes in the eCatalogue from GH Issue #284
-
Process control: Information about the specification that applies to the transaction.
-
Business process type identifier: Identifies the business process context in which the transaction appears. It enables the buyer to process the invoice in an appropriate way.
-
Specification identification: An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms. This identifies the European invoice norm, as well as any extensions applied. The identification may include the version of the specification.
-
Catalogue validity period: A time interval or a duration of a catalogue’s validity.
-
Contract reference: A reference to a contract the catalogue is based on.
-
Contract identifier: The identifier of the referenced contract.
-
Contract type: The type of a contract that is being referred to (such as framework agreement) expressed as a code.
-
Contract issue date: The date on which the contract comes into effect.
-
Contract subdivision: A relevant subdivision of the contract a catalogue refers to.
-
Discussion:
Argumentation on whether we should split ePO into different modules or keep all inside one big model.
If we add all modules inside ePO module, maintenance will be a mess in the future.
An idea is not to split everything per process, but per a domain.
Further discuss with domain experts on how to structure the module splitting.
Continue discussing a new approach on structuring ePO:
Roles overview diagram:
Most of the things in this new approach are not different than the old approach in ePO model version 2.0.0
The Role is a class that always is attached to a particular agent that fulfills that role.
The Role always has exactly one Context
We divided the Roles into three groups:
-
Procurement Role - those that are directly involved in a procurement
-
ProcurementSubrole- additional roles that are played by agents that are already playing another role in the procurement
-
RelatedRole - roles that need to be taken into consideration but they are not directly involved (some information providers)
It is important to make a distinction between Awarder Central Purchasing Body and Acquiring Central Purchasing Body.
This is not really a Role. Is the impersonification of an Agent in that Role.
A Role is something you can assign.
Properties that a Role should have in order to fulfill all the needs:
-
A role comes with its own properties and behavior
-
Roles depend on relationships.
-
An object may play different roles simultaneously
-
An object may play the same role several times, simultaneously.
-
The sequence in which roles may be acquired and relinquished can be subject to restrictions.
-
Objects of unrelated types can play the same role.
-
The state of an object can be role-specific.
-
Different roles may share structure and behavior.
-
An object and its roles have different identities.
There are three things that need to be taken into consideration when we are talking about Situation:
-
Brute fact, independent of the context
-
Observer relative fact
-
Context as the observer
AwardDecisionSituation diagram:
One limitation to have the Agent related to the Situation:
If we have to specify Tenderer and the Tenderer Receiver (the situation has two roles) it becomes difficult to manage what Role is for what Situation.
This approach provides not the situation of a specific Agent, but is that a Situation can provide you all the participants to this.
ContractSigningSituation diagram:
The difference between the old approach and the new one is that the old approach could have more Agents connected to one situation, making it impossible to find the Agent in some use cases.
Award decision phase instantiation:
Presenting Notices module.
We should separate the core module from eNotification.
This kind of approach will help us to double check the consistency of the model.
Competition Notice Content diagram:
Notices module should be separately in an application profile.
Working group meeting 07/12/2021
Date: 07/12/2021
Participants: Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
*Note editor: *Andreea Pasăre
Agenda:
-
Proposes a new approach on WGM.
-
Redundancy links to enumerations were merged into master branch.
-
The eCatalogue module was merged into the master branch.
-
Announce a proposal to structure the EPO model.
-
Present Situations, Roles, Notice taxonomy, Notice Content model.
-
Present an example of instantiation of the Submission/Awarding situation. === (Future agenda)
-
-
Continue discussing the attributes in the eCatalogue from GH Issue #284
-
Process control: Information about the specification that applies to the transaction.
-
Business process type identifier: Identifies the business process context in which the transaction appears. It enables the buyer to process the invoice in an appropriate way.
-
Specification identification: An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms. This identifies the European invoice norm, as well as any extensions applied. The identification may include the version of the specification.
-
Catalogue validity period: A time interval or a duration of a catalogue’s validity.
-
Contract reference: A reference to a contract the catalogue is based on.
-
Contract identifier: The identifier of the referenced contract.
-
Contract type: The type of a contract that is being referred to (such as framework agreement) expressed as a code.
-
Contract issue date: The date on which the contract comes into effect.
-
Contract subdivision: A relevant subdivision of the contract a catalogue refers to.
-
Discussion on Locations/Geometry/Address
-
We need to provide coordinates, address or a named reference.
-
Location class
-
Geographical name
-
May have a geometry
-
-
Place of performance requires a location (in the notices NUTS code is required, and a text field for more info).
-
Use the core location namespace.
-
Use the naming conventions from the core.
-
Use “fullAddress” field in the address class
-
Some properties are differently called
-
adminLevel1 == country code
-
adminLevel2 == region/state/county
-
… === Decision on redundant code attributes
-
-
Decision: update the conversion & conventions checking script and the documentation so that
-
There is no more handling of code attributes (i.e. attributes with type Code/skos:Concept)
-
The dependency relations between the class and enumerations
-
In the core-model file the dependency relation shall have the range skos:Concept (regardless of the enumeration URI)
-
In the shack-shape file the dependency relation shall be checked for the precise controlled list. Those are warnings not errors.
-
-
-
Update the documentation accordingly === Discussion on eCatalogue
-
Module-specific should be used
-
In other modules other namespace should be used
-
-
An investigation must be done on deciding what is the “core” of epo and what is in the notification module or other ones.
Discussion on Situations, Roles, Notice taxonomy, Notice Content model.
Presenting Role modeled with subclasses: ProcurementRole ProcurementSubrole and RelatedRoles:
Situation in DOLCE acts as a relational context just as the Term classes in the below diagram:
Discussing the Awarding example at an instance level provided.
Checking the definition of Buyer from EPO model:
“A role of an agent that awards a contract and/or purchases items.”
Presenting the SubmissionActualSituation example diagram:
Submission phase per lot - instance level diagram:
Award decision phase for a lot the was not awarded diagram:
Working group meeting 18/11/2021
Date: 18/11/2021
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
*Note editor: *Andreea Pasăre
Future agenda:
-
Continue discussing the attributes in the eCatalogue from GH Issue #284
-
Process control: Information about the specification that applies to the transaction.
-
Business process type identifier: Identifies the business process context in which the transaction appears. It enables the buyer to process the invoice in an appropriate way.
-
Specification identification: An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms. This identifies the European invoice norm, as well as any extensions applied. The identification may include the version of the specification.
-
Catalogue validity period: A time interval or a duration of a catalogue’s validity.
-
Contract reference: A reference to a contract the catalogue is based on.
-
Contract identifier: The identifier of the referenced contract.
-
Contract type: The type of a contract that is being referred to (such as framework agreement) expressed as a code.
-
Contract issue date: The date on which the contract comes into effect.
-
Contract subdivision: A relevant subdivision of the contract a catalogue refers to. === Discussion
-
Issue 284 - https://github.com/OP-TED/ePO/issues/284
-
Catalogue version - will map to the new added attribute epo:hasDocumentVersion.
We could adopt the FRBR model. We don’t need to incorporate the entire model.
We should probably add a version to epo:Document. The argument for not adding is that if we have a new version it means it is a new Document.
The limitation of UML is that it does not allow us to import at runtime only without polluting the target model.
Work for this issue on a feature branch and then move it in the master branch.
-
*Catalogue Issue Date *maps to the already existing epo:hasPublicationDate in epo:Notice
epo:hasPublicationDate will be epo:hasIssuedDate in the new version.
Move epo:hasPublicationDate from epo:Notice to epo:Document.
Change epo:hasIssuedDate back to epo:hasPublicationDate in the new version.
Leave a comment to ask for more clarifications regarding this attribute.
-
Catalogue action code
-
Source catalogue identifier
-
General payment conditions - Ask if the catalogue is linked directly to Lot. If yes, the mapping will be epo:Lot epo:isSubjectToTerm epo:ContractTerm epo:hasPaymentArrangement.
Decisions:
-
Export eCatalogue model and import it into the master branch on GitHub to be easier to edit.
-
When we publish a new version of the UML model we should take out the eCatalogue module and reinclude it in the master branch after publishing.
-
Added epo:hasVersion attribute (epo:Text type [0 1])to epo:Document class with the following definition: “A number that identifies a specific state of a document.
WG Approval 18/11/2021” -
Move epo:hasPublicationDate from epo:Notice to epo:Document. Change epo:hasIssuedDate back to epo:hasPublicationDate in the new version.
Change definition to the one from Dublin Core:
“ Date of formal issuance of the document.
Note: this attribute is equivalent to dct:issued.
(WG approval 18/11/2021)”
Working group meeting 16/11/2021
Date: 16/11/2021
Participants: Cecile Guasch, Giorgia Lodi, Hilde Kjølset, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
*Note editor: *Andreea Pasăre
Discussion
Issue 315 - https://github.com/OP-TED/ePO/issues/315
epo:Organisation - epo:hasName does not have a good definition.
Checking Core Business Vocabulary for Legal Entity → legalName.
-
Add a new predicate epo:hasLegalLocation between epo:Organisation and epo:Location that can be mapped to cac:RegistrationAddress.
-
cbc:RegistrationName maps to epo:hasLegalName, attribute of epo:Organisation
-
cbc:CompanyID maps to epo:hasID, attribute of epo:Agent
Issue 316 - https://github.com/OP-TED/ePO/issues/316
The ontology must cover as many pre-award and post-award use cases. The restriction you mention above is specific to the catalogue use case and therefore need to be dealt with in a dedicated application profile. Such restrictions are not in the scope of the ontology.
Issue 319 - https://github.com/OP-TED/ePO/issues/319
In the current version of the model, we have an epo:isPersonOfCcontact relation from epo:ProcurementRole to the epo:ContactPoint. epo:ContactPoint class has the attribute epo:hasDescription which can be used to specify the name of the person.
This part of the model is under revision and we will take into consideration your point.
Decisions:
-
Add epo:hasLegalName as attribute to epo:Organisation (epo:Text) with the following definition: “The officially registered name of an Organisation.
WG Approval 16/11/2021“ -
Change definition for all epo:hasName attributes to all the classes in ePO: Channel, Fund, Item, Organisation, ProcurementCriterion, System “A short text by which a thing is known or referred to.
WG Approval 16/11/2021” -
Add a new predicate epo:hasLegalLocation between epo:Organisation and epo:Location with the following definition: “The officially registered location of an Organisation.
WG Approval 16/11/2021“ -
Add definition for epo:hasLocation: “A place where an organisation is situated.
Additional information:
This is not the registered location.
WG Approval 16/11/2021”
-
Issue 317 - to be resolved offline.
Working Group meeting 11/11/2021
Date: 11/11/2021
Participants: Cecile Guasch, Giorgia Lodi, Hilde Kjølset, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
Note editor: Andreea Pasăre
Agenda:
-
Merge into master is ready (backlog corrections of definitions: classes, attributes & relations)
-
Go through the errors discovered by the constraints checker
-
Missing target roles
-
Missing multiplicity
-
-
Present approaches to roles
-
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 participatory 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”
-
-
(Future agenda)
-
Discuss the principles on specifying the cardinality constraints (in the model and in AP) == Discussion
Presenting a summary of the last session’s discussion on roles and the various features that we previously adopted for roles.
In the literature, there are three approaches to modelling roles:
-
Roles as named places - the most economical and the most straightforward
One limitation of this approach is that it is difficult to represent a group of lots.
-
Roles as specializations and/or generalizations
-
Roles as n-ary relations
Discussing the CPSV-AP model.
We can organise the roles and subroles as classes and whenever we need to instantiate it we can always instantiate that class, so we don’t point to the enumeration.
We shouldn’t create subclasses for all the subroles. But do we really need the classes for roles, as well?
Is it useful to reify each role?
Roles may have states that’s why we should be able to capture the additional properties they will inherit.
Subroles as adjunct instances example:
The EU Vocabulary Subroles includes group lead. How can we manage that?
We could bring the subroles into a controlled list and we will have a consistent approach to modelling Roles and Subroles.
Decisions:
-
Continue with the two parallel hierarchies.
-
Look at the current model and provide a solution of the main roles.
-
Test the solution with SPARQL queries.
-
Merge into master is ready (backlog corrections of definitions: classes, attributes & relations)
Working Group meeting 09/11/2021
Date: 09/11/2021
Participants: Cecile Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
Note editor: Andreea Pasăre
Agenda:
-
Discuss comments on attributes with missing definitions.
-
Go through the errors discovered by the constraints checker
-
Missing target roles
-
Missing multiplicity
-
-
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”
-
-
(Future agenda)
-
Discuss the principles on specifying the cardinality constraints (in the model and in AP) == Discussion
Discuss comments on attributes with missing definitions
Definitions adopted:
epo:RenewalIndicator - "Indicates whether the contract is subject to a renewal clause.
WG Approval 09/11/2021"
epo:AwardDateScheduled - "Planned date for the award decision.
WG Approval 09/11/2021"
epo:EstimatedTenderInvitationDate - "The planned date for the dispatch of the invitations to submit tenders.
WG Approval 09/11/2021"
epo:NonPublicationJustificationDescription - "A narrative explanation of why data is not published.
Additional Information:
This element is generally used when the non-publication-justification code chosen is ""other"".
WG Approval 09/11/2021”
epo:ReviewDeadline - "The time limit for review procedures.
WG Approval 09/11/2021"
epo:reviewDeadlineInformation - "Information about the time limit for review procedures.
WG Approval 09/11/2021"
epo:MinimumSubcontractorsProposedObligation - "The minimum percentage of the contract value that the contractor must subcontract.
Additional information:
This is used for the competitive procedure described in Title III of Directive 2009/81/EC. "
epo:SubcontractorsProposedAboveObligation -
"The maximum percentage of the contract value that the contractor must subcontract.
Additional information:
This is used for the competitive procedure described in Title III of Directive 2009/81/EC. "
epo:RankingInFirstStage - "The rank of the tender at the end of the selection phase of a multi-stage procedure.
WG Approval 09/11/2021"
epo:SubcontractShareSubjectMatter - "Description of the share of the contract that is to be subcontracted.
Additional information:
This can be an aggregate of several subcontracts.
WG Approval 09/11/2021"
epo:EPayment - "Electronic means must be used for paying.
WG Approval 09/11/2021"
