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"
Present roles as adjunct instances
Role as n-ary relation:
Tender example role model:
Tender example instantiation:
How do we use a CV of roles?
We don’t need one. We should have them as classes or subclasses.
Award example role model:
Award example instantiation:
Information Provider Role and Subrole example:
Decisions:
-
Change data type from epo:Indicator to epo:Numeric for epo:SubcontractorsProposedAboveObligation
epo:MinimumSubcontractorsProposedObligation -
epo:TotalValueSubcontracted - should be changed to epo:EstimatedTotalSubcontracts
-
epo:MinimumShareSubjectMatter - change this to epo:SubcontractShareSubjectMatter and move it to statistical information.
-
epo:ParticipationPayment - should change type from epo:Numeric to epo:Text
Questions:
-
Should we move Reg2015 and BDTI AP into different eapx files?
-
For the moment we should keep them like they are until we decide to publish something.
-
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
Agenda:
-
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.
Decisions
-
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.
epo:hasBuyerType
The codelist to be used is at-voc:buyer-legal-type which is available at _https://op.europa.eu/web/eu-vocabularies/at-dataset/-/resource/dataset/buyer-legal-type[_https://op.europa.eu/web/eu-vocabularies/at-dataset/-/resource/dataset/buyer-legal-type]
http://publications.europa.eu/resource/authority/buyer-legal-type
-
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
Working Group meeting 28/10/2021
Date: 28/10/2021
Participants: Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
Note editor: Andreea Pasăre
Agenda:
-
Discuss whether we should add Review Requester to eProcurement Ontology
-
See Role table (rev-req). The concept is available in the vocabulary table and not in the ontology.
-
-
Inter-role dependency:
-
example relation: Tenderer and Winner (currently modelled as subclass)
-
Is it a true subclass relationship? or
-
Is the winner a more refined type of a tenderer? Like, for example, “square” is a more specific type of a “geometric shape”.
-
-
Is it a (precedence) dependency of some sort?
-
An organisation can take the winner role only if it is a tenderer first. Therefore we need an instance of the role of the or organisation as a tenderer (in one situation) in order to instantiate a winner role for that organisation.
-
-
Can they both be the case?-
Are we allowed to imagine that previously created instances can be updated / extended / modified? Or do we just refer to them mainly once they have been created? (this shall be recorded as a principle) -
Then how?
-
-
-
Decide what role properties we need in the model & announce work in progress on role modeling alternatives
-
Selection from 15 role features available.
-
Announce the work in progress on approaches to role modelling.
-
Discussion
Inter-role dependency:
Winner is not a more specific type of Tenderer. It’s a dependency on the outcome of a different phase.
Presenting “approaches to role modeling” document.
Example diagram:
Example instance level:
An Organisation should be at first a Tenderer in order to become a Winner.
Counter-example instance level:
But a Tenderer could be made up of several organisations.
Diagram example:
Example instance level:
Winner is a subclass of Tenderer which is a subclass of Role.
Example roles as subclass role to role - instance level:
We can not take the URi from the Tenderer and move it to Winner. We need to create another one.
The identity of the Role comes from the Organisation.
In UML we can not say that it is the same Organisation, but we can add a joint dependency “sameSource”, like in the diagram below:
Therefore we can not instantiate the following example:
Such inter-roles dependency needs to be expressed in the model without reusing the properties of the prior role.
For example:
The properties of an Organisation with several roles should be instantiated only once.
Counter-example:
Using specialisation relation is not a solution. (e.g. Winner is not a more specific type of a Tenderer)
Principles presented:
-
Instance immutability - once published, an instance shall not be conceptualised as changeable.
-
Non-redundancy - properties of an entity must be instantiated only once.
Role features
The following Features are relevant to ePO:
-
A role comes with its own properties and behaviour
-
Roles depende on relationships
-
An object may play different roles 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. (Evaluator role can be played by an organisation, a system or a person)
-
Roles can play roles (is this the case?!)We should fall back on role dependency whenever possible. The “group lead” is modeled as a named place and not a class in ePO. -
The state of an object can be role-specific.
-
Different roles may share structure and behaviour. (we have proper role hierarchies: for example CentralPurchasingBody is split into two classes: Awarding and Acquiring)
-
An object and its roles have different identities. (An organisation may be tenderer in different procedures/lots. So the # of tenderers may be greater than the number of organisations.)
Working Group meeting 26/10/2021
Date: 26/10/2021
Participants: Hilde Kjølset, Natalie Muric, Thor Steinar Møller, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
Note editor: Andreea Pasăre
Agenda:
-
Announce that a request will be sent to the WG about reviewing the proposed attribute definitions where currently missing.
-
Any comments to be discussed on the 9th of November
-
-
Announce that more review requests are coming as we document and propose corrections to the constraint violations.
-
Propose to record the ontology requirements, assumptions & (modelling) principles.
-
Approve with the group meeting that distilling/de-conflating the sub-role table into “derived role” and “derived function” (to which is also an “activity”/”action”) is (a) useful and (b) that what we need in ePO is the “derived function” column.
-
BDTI query returning multiple labels: how urgent is this?
-
What shall be presented to the DG GROW?
-
Proposal to revise:
-
Comments on the labels and definitions?
-
Distinction between roles and actions/functions extracted from their labels?
-
Discuss Roles and add comments for EU Vocabulary List (eg. mediator has a label Mediation Organisation)
-
-
Discussion
Subroles:
Subroles can be carried out by the organisations and roles list.
In Norway, in the current notices, the subroles are not used. They might be used in the future eForms.
At the moment, we are using the “derived functions”. Need to decide if the “derived roles” and their functions are conflated.
Presented the recipient example:
If we ask DG GROW to remove “Organisation” from the Label in EU Vocabularies it will be enough.
Adding comments for EU Vocabulary List:
-
bud-pay → Do you mean this is the 'Organisation that provides funding for the contract'? Then this would be a "funding contract".
-
group-lead → Possibly removing it from this list (where a group member is also listed). This is not a role of an agent participating in an action, it is a role of an agent in a social construct (that of associating as a group) And this list became more about action rather than role(s).
-
info-prov → providing additional information about the procurement procedure.
-
offl-acc → providing offline access to the procurement documents.
-
procesor → processing tenders. Note: is there a use case for this?
-
recipient → receiving tenders. Note: is there a use case for this?
-
req-proc → processing requests to participate. Note: is there a use case for this?
-
req-recep → receiving requests to participate.
-
rev-info → providing more information on the review procedures.
-
signatory → signing the contract. Note: signing on the side of the buyer is right?
Roles:
Revising Roles list in order to make sure we have covered each role and provided pertinent comments to DG GROW.
Add “The role of an agent that is responsible for…” to each definition of a Role.
ben-own → Beneficial Owner should be an attribute of the Buyer, if we take into account the discussion from group-lead.
Definitions proposed for adoption:
-
buyer
-
cpb-acq → changed definition to “The role of a central purchasing body acquiring supplies and/or services intended for other buyers.”
-
cpb-awa → changed definition to “The role of a central purchasing body awarding public contracts or concluding framework agreements for works, supplies or services intended for other buyers.”
-
mediator
-
reviewer
-
serv-prov
-
subcont
-
tenderer
rev-req → new definition: “Role of an agent who requests the review of a (procurement) procedure.”
Winner → changed definition to “A role of an agent to whom a lot is awarded.”
Questions DG GROW:
-
Do we find the distinction between roles and their function useful?
-
We should bring this to DG GROW’s attention.
-
-
What’s the difference between processing and receiving requests? (do we have a use case for this?)
-
Organisation-subrole:
-
This list appears to concern only the “buying side” of the procurement, except for group lead which could be also on the economic Operator side”.
-
It should be noted that group lead appears to be a role in a social construct rather than a role in an activity, which is the case for the rest of the codes.
-
We would therefore suggest that this is a direct attribute of the “buyer” and the “economic operator”.
-
Signatory may apply to the “economic operator” side therefore making it specific to the buyer (eg. buyer signatory) would exclude possible interpretations.
-
Decisions
-
Attribute definitions by 8th of November, to be requested by message in the MsTeams (not email).
-
Roles and Subroles worksheets are done and ready to be presented to DG GROW.
Working Group meeting 19/10/2021
Date: 19/10/2021
Participants: Hilde Kjølset, Giorgia Lodi, Natalie Muric, Thor Steinar Møller, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
Note editor: Andreea Pasăre
Agenda:
-
Glossary points to be discussed
-
Attribute definitions (see the file)
-
epo:AdditionalInformation
-
epo:ThresholdType
-
-
-
Continue modelling the subroles
List of subroles:
Organisation-subrole table definition: This table provides the list of the different sub-functions of the organisations in a procurement procedure.
bud-pay |
|
Permitted values for ‘hasRole’: Context: Contract |
exec-pay |
|
Permitted values for ‘hasRole’: buyer or the service provider |
group-lead |
|
Permitted values for ‘hasRole’: buyer, winner, tenderer or the service provider. Context for the buyer: Procedure |
info-prov |
|
Permitted values for ‘hasRole’: buyer or the service provider. Context: Procedure |
offl-acc |
|
Permitted values for ‘hasRole’: buyer or the service provider. Context: Lot, |
processor |
|
Permitted values for ‘hasRole’: buyer or the service provider. Context: Lot |
recepient |
|
Permitted values for ‘hasRole’: buyer or the service provider. Context: Lot |
req-proc |
|
Permitted values for ‘hasRole’: buyer or the service provider. Context: Lot |
req-recep |
|
|
rev-info |
|
|
signatory |
|
Discussion
-
Glossary points to be discussed
-
epo:AdditionalInformation - Keep definition from epo:Lot
-
epo:ThresholdType - No definition yet. Wait for Criterion discussion ().
-
-
Continue modelling the subroles
signatory subrole:
dateOfSignature is useful to emphasize that the date of signing can be different for the Buyer or the Winner.
The signatory is not possible in Competition Notices.
We can still use a common approach to model the situation, and the only difference will be whether this is anchored in time or in a different legal modality (obligation, permission).
The dateOfSignature from Contract represents the date of the last signature of the Contract.
req-recep subrole:
Permitted values for ‘hasRole’ are: Buyer (two CPBs included), ServiceProvider.
Decision:
-
Subroles can be modeled outside the WG, based on the general participation pattern. Context is always the Lot. Subroles are defining the Contract Notice.
Comments for EU Vocabulary List:
-
bud-pay - Should this not be the 'Organisation that provides funding for the contract'?
-
organisation-subrole - This table provides a list of subfunctions, therefore it is not necessary to put the word 'organisation' in the label. Re-labeling these concepts would harmonise the labels with those in the organisation role code list.
Working Group meeting 19/10/2021
Date: 19/10/2021
Participants: Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
Note editor: Andreea Pasăre
Agenda:
-
modelling structure of the Notices.
Discussion
There is a dependency between Organisation Role and Organisation Subrole in the eForms, but not in the eForms excel.
The first UML model draft for eForms excel has been created.
Organisation attributes should be linked to the Lot, the Procedure, etc. based on the description from the eForms excel. The same applies to other BGs.
According to the eForms, the place of performance can change per Lot, so we should be able to see this from the UML diagram as well.
Lot does not exist as a BG or BT in the eForms excel. It is only specified in the description.
Place of performance is filled backwards because it is easier to add a single place and mention that it applies to many lots.
Eg: Place of performance London applies to Lot 1, 2 and 3
We need to add a perspective to modeling the structure of the Notices in order to avoid having issues when applying this to RDF data.
Might be useful to see what are the parts of a Planning Form, Competition Form, DAP, etc.
Diagram Notice with 3rd dimension:
Represent as well as possible the logic of the Notices.
Diagram Previous Planning instance example:
Choice 1:
Choice 2:
Choice 3:
Choice 4:
Working Group meeting 14/10/2021
Date: 14/10/2021
Participants: Cecile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Andreea Pasăre
Note editor: Paloma Arillo
Agenda:
-
Continue modelling the subroles === List of subroles:
Organisation-subrole table definition: This table provides the list of the different sub-functions of the organisations in a procurement procedure.
bud-pay |
Organisation whose budget is used to pay for the contract |
exec-pay |
Organisation executing the payment |
group-lead |
Group leader |
info-prov |
Organisation providing additional information about the procurement procedure |
offl-acc |
Organisation providing offline access to the procurement documents |
hprocessor |
Organisation processing tenders |
recepient |
Organisation receiving tenders |
req-proc |
Organisation processing requests to participate |
req-recep |
Organisation receiving requests to participate |
rev-info |
Organisation providing more information on the review procedures |
signatory |
Organisation signing the contract |
-
Decision: all subroles--- Ask DG GROW to change the naming or add AltLabels for all subroles:
-
remove the word ’Organisation’ from all labels.
-
bud-pay → Organisation whose budget is used to pay for the contract, should be replaced with ‘Funding the contract’.
-
group-lead→ Group leader should be replaced with ‘Leading the group’.
-
-
Decision: “rev-info” subrole ==== Issue
-
The organisation executing the function of providing information about the review procedure can play the role of buyer, reviewer, mediator or service provider listed in ‘organisation-role’, how to reflect that they cannot play the function of providing review procedure information in the same procedure
-
The label itself is ambiguous. === Discussion
-
The situation is from whom we should get the information to request a review for a procedure.
The label is ambiguous: does it refer to the information about the procedure to follow for requesting a review itself? Does it refer to the information about the type of complaints that lead to requesting for a review? It seems to refer to where to get the information about how to request a review.
BG-612 checked to see if it can also be per Lot. We keep only ‘Procedure’ in the model.
How to show in the instance example that there are 4 possible roles that can play the function but not them all at the same time?
It is possible to infer from th eURI of the ‘rev-info’ which is his main role?
After checking the Excel file eForms business terms it seems obvious that role and subrole and flat lists so there is no need to link the role to the sub-role. An organisation plays a role and could play a subrole.
The reification does not necessarily imply a hierarchy role to subrole.
Chosen solution:
Diagram
Instance example
Choice 1: it seems in this example that the 4 roles can play the same function of ‘rev-info’ for the same procedure
Choice 2
Choice 3
No need for an instance example.
No reification needed which means no instance diagram needed.
In the ePO model in the ‘Procurement Term’ we add a class ‘Agent’ linked to ‘ReviewTerm’: hasAgentProvidingReviewProcedureInformation. Agent providing review info.
(We could alternatively use the reification and the instance diagram).
Rationale
The function is about who can provide information about the procedures concerning review requests.
Only 4 roles can play the subrole rev-info but there is no need to link the subrole to the role in the examples. So there is no need for creating an instance example (choice 3).
-
Decision: “req-recep” subrole === Discussion
Refers to the function of receiving the requests to participate in a tender. We checked BG 102 and this subrole seems to be also possible at Lot level although this seems a very extreme situation.
However, BT-770 clearly refers to the Procedure and not to the Lot.
Discussion to be continued on 19 October 2021
Working Group meeting 12/10/2021
Date: 12/10/2021
Participants: Cecille Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric,Thor Steinar Møller, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda:
-
Presentation of the note-taking
-
Apply the note-taking to a simple issue:
-
Identify the context/process where each “sub-role” is involved.
-
For each context/process, what other participants (actors or objects) are involved?
-
Is the term “sub-role” appropriate?
-
List of subroles:
Organisation-subrole table definition: This table provides the list of the different sub-functions of the organisations in a procurement procedure.
bud-pay |
Organisation whose budget is used to pay for the contract |
exec-pay |
Organisation executing the payment |
group-lead |
Group leader |
info-prov |
Organisation providing additional information about the procurement procedure |
offl-acc |
Organisation providing offline access to the procurement documents |
hprocessor |
Organisation processing tenders |
recepient |
Organisation receiving tenders |
req-proc |
Organisation processing requests to participate |
req-recep |
Organisation receiving requests to participate |
rev-info |
Organisation providing more information on the review procedures |
signatory |
Organisation signing the contract |
Decision: “signatory” subrole
Issue
Identify the situation where the signatory subrole is used and what is the proper way to model it.
It is labelled as “Organisation signing the contract”.
Alternative choices
Choice 1: so-called “subrole” as function specification in a contract signing situation with a role
Discussion
We need a natural person signing on the behalf of the Organisation.
The goal is to identify one or more of those organisations that have the role of the contractor.
If the Winner doesn’t sign, he doesn’t become a Contractor.
The triggering event to become a Contractor is the Signing of the contract by the Winner.
The other side of the Contractor Situation is the Contractee Situation.
Should we call Situation instead of Process?
According to the Oxford dictionary, a Situation is a set of circumstances of only one actor in a state of affairs.
Participation is preferred instead of Situation, like ProcurementParticipation.
ContractorSituation becomes ContractorParticipation. The same happens with ContracteeParticipation.
The Commission always signs last.
The Role embedded in the Situations: ContracteeParticipation and ContractorParticipation?
Maybe we should consider ContractSituation instead of ContractingSigningActivity.
In eForms, they want to convey the information in which Organisation performed an activity for which they have an organised Role.
This can be modelled according to the Award Reification diagram from version 2.0.2
The Winner doesn’t become the Contractor until the Contract is signed.
Subroles should be named functions.
There is always a Natural Person behind an Organisation that signs the contract.
Question: items in the subrole list
Note: The subroles controlled list enumerates actual (sub)roles in a granular action (i.e. action part of a broader process where the “primary” roles take part), but we think they should be functions, i.e. names of activities/actions.
-
Question for GD GROW: What is the difference between the organisation that executes the payment and the organisation that has the budget?
-
Can we remove the “organisation” term from the label of the concept and, instead, refer to the action only?
Working Group meeting 12/10/2021
Date: 12/10/2021
Participants: Cecille Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric,Thor Steinar Møller, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda:
-
Presentation of the note-taking
-
Apply the note-taking to a simple issue:
-
Identify the context/process where each “sub-role” is involved.
-
For each context/process, what other participants (actors or objects) are involved?
-
Is the term “sub-role” appropriate?
-
List of subroles:
Organisation-subrole table definition: This table provides the list of the different sub-functions of the organisations in a procurement procedure.
bud-pay |
Organisation whose budget is used to pay for the contract |
exec-pay |
Organisation executing the payment |
group-lead |
Group leader |
info-prov |
Organisation providing additional information about the procurement procedure |
offl-acc |
Organisation providing offline access to the procurement documents |
hprocessor |
Organisation processing tenders |
recepient |
Organisation receiving tenders |
req-proc |
Organisation processing requests to participate |
req-recep |
Organisation receiving requests to participate |
rev-info |
Organisation providing more information on the review procedures |
signatory |
Organisation signing the contract |
Decision: “signatory” subrole
Issue
Identify the situation where the signatory subrole is used and what is the proper way to model it.
It is labelled as “Organisation signing the contract”.
Alternative choices
Choice 1: so-called “subrole” as function specification in a contract signing situation with a role
Discussion
We need a natural person signing on the behalf of the Organisation.
The goal is to identify one or more of those organisations that have the role of the contractor.
If the Winner doesn’t sign, he doesn’t become a Contractor.
The triggering event to become a Contractor is the Signing of the contract by the Winner.
The other side of the Contractor Situation is the Contractee Situation.
Should we call Situation instead of Process?
According to the Oxford dictionary, a Situation is a set of circumstances of only one actor in a state of affairs.
Participation is preferred instead of Situation, like ProcurementParticipation.
ContractorSituation becomes ContractorParticipation. The same happens with ContracteeParticipation.
The Commission always signs last.
The Role embedded in the Situations: ContracteeParticipation and ContractorParticipation?
Maybe we should consider ContractSituation instead of ContractingSigningActivity.
In eForms, they want to convey the information in which Organisation performed an activity for which they have an organised Role.
This can be modelled according to the Award Reification diagram from version 2.0.2
The Winner doesn’t become the Contractor until the Contract is signed.
Subroles should be named functions.
There is always a Natural Person behind an Organisation that signs the contract.
Question: items in the subrole list
Note: The subroles controlled list enumerates actual (sub)roles in a granular action (i.e. action part of a broader process where the “primary” roles take part), but we think they should be functions, i.e. names of activities/actions.
-
Question for GD GROW: What is the difference between the organisation that executes the payment and the organisation that has the budget?
-
Can we remove the “organisation” term from the label of the concept and, instead, refer to the action only?
Working Group meeting 07/10/2021
Date: 07/10/2021
Participants: Cecille Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Thor Steinar Møller, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Issue
We have a situation with two roles where we try to decide what are the things participating in that specific situation.
Try to find a solution for anytime we have a situation with Roles.
Discussion
Assignation changed to Signing.
It was mentioned that it is signed by the Organisation in its Role of Buyer.
We replicate the same organisation according to the Role. Against the principle of deduplication. Organisation has one unique identity, only the situation where it has a specific Role changed.
Two situations at the same time: the signing of the AwardDecision and the attribution of the Lot.
AwardDecision mentions Lot and Winner.
Winner-selection-status should go to the Lot and not to the AwardDecision.
Example of a Tender Submission:
It has been decided to keep TenderLot and not change it to Tender.
For a TenderSubmission to make sense we need one Tenderer and at least one TenderLot or more.
It’s the Organisation that is in the Situation.
We discussed two options of roles and situations.
Choice 1:
Choice 2:
TenderLot is the offer for the specific Lot. It’s a role, like the role of being submitted by a tender.
We can have more Organisations that can participate/jointly submit in a Tender.
It’s the Tender that has the rank and not the Winner/Tenderer.
The Tender is not a participant, the Organisation is. The Organisation does something according to a Role.
Discussed CPSV-AP specification v2.2.1
The Buyer Role is only one, it doesn’t change. Only the situation changes. Checking Role in Time diagram.
Discussing the design pattern in SPAR ontology: Publishing Roles Ontology.
Working Group meeting 05/10/2021
Date: 05/10/2021
Participants: Cecille Guasch, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda:
-
presented social role by hoekstra
-
and a student example
-
if we adopt this model, check instance of a student model
-
presented loted2-original → roles
Discussion:
Social Role by Hoekstra was presented during this session. This model is similar to what we had in v2.0.1.
The difference is that Agent Role Reification has owl:Thing → Context.
It was discussed that it might be better to have roles as controlled vocabulary as well.
At the moment, we don’t have roles as a controlled vocabulary, we have them as classes.
A person does not stop to be a person when it becomes a student.
A person is rigid, but a role is not rigid.
In the data we have the same person repeated many times according to the role.
This is not the correct approach and should be fixed.
Proposing to try a student example as a buyer for “signing of the contract” situation.
We have to take the Buyer, the Agent, the relationship between them and the Lot.
Buyer example diagram:
If Buyer is not in a procedure, he is not a Buyer anymore, but an Organisation.
If we adopt a hierarchy of roles it becomes useful to constraint what subclasses from the hierarchy can adopt that role.
Buyer example 1 diagram:
There’s an association between organisation and procurement in the example Buyer.
Discussed the Turtle example from the last meeting. The role can be instantiated only once.
Should draw the diagram for this example offline and come back with an analysis/comparison for the next time.
Note: take care of the cardinalities between Agent - Roles - Procedure - Lot. (AgentRole Reification)
Workgroup meeting 30/09/2021
Date: 30/09/2021
Participants: Giorgia Lodi, Natalie Muric
Model editor: -
Note editor: Andreea Pasăre
Discussion
-
Discussed a possible approach on Role reification
-
The Political Roles Ontology (PRoles) paper was discussed.
-
The following RDF Turtle example was provided:
<http://data.europa.eu/a4g/resource/2019/s-001-001368#ContractAwardNotice99f7aaf2-13cb-46b4-830c-552e4467ef0c> a epo:ContractAwardNotice ;
epo:summarises <http://data.europa.eu/a4g/resource/2019/s-001-001368#Procedureae76cf46-d8e0-4caa-9ad8-6c9fa83ff0af> .
<http://data.europa.eu/a4g/resource/2019/s-001-001368#Procedureae76cf46-d8e0-4caa-9ad8-6c9fa83ff0af> a epo:Procedure ;
epo:hasProcurementSituation <http://data.europa.eu/a4g/resource/2019/proc-situation-1> , <http://data.europa.eu/a4g/resource/2019/proc-situation-2> .
<http://data.europa.eu/a4g/resource/2019/proc-situation-1> a epo:ProcurementSituation ;
epo:hasRole <http://data.europa.eu/a4g/resource/buyer> ;
epo:withFunctions <http://data.europa.eu/a4g/resource/execute-payment> , <http://data.europa.eu/a4g/resource/providesDocument> ;
epo:includesAgent <http://data.europa.eu/a4g/resource/2019/s-001-001368#Organisationbd6a5210-e7b0-4afb-b76f-c593bc50c92d> ;
epo:hasContext <http://data.europa.eu/a4g/resource/2019/s-001-001368#Procedureae76cf46-d8e0-4caa-9ad8-6c9fa83ff0af> .
<http://data.europa.eu/a4g/resource/2019/proc-situation-2> a epo:ProcurementSituation ;
epo:hasRole <http://data.europa.eu/a4g/resource/economic-operator> ;
epo:includesAgent <http://data.europa.eu/a4g/resource/OrganisationEO1> ;
epo:hasContext <http://data.europa.eu/a4g/resource/2019/s-001-001368#Procedureae76cf46-d8e0-4caa-9ad8-6c9fa83ff0af> .Working Group meeting 21/09/2021
Date: 21/09/2021
Participants: Cecille Guasch, Hilde Kjølset, Giorgia Lodi, Thor Steinar Møller, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
eSender role
Alternative choices
-
_Add the role _
-
Keep it out of the ontology ==== Discussion
Currently kept out of the ontology because it is not clear whether it is in the scope of the ontology. And if it is then it seems to be an organisation that sends notices through a system. But it seems to be a specialisation of the epo:ProcurementServiceProvider.
review requester role
participant role
Issue
_Currently missing in the ontology but present in the EU Vocabularies roles. _Alternative choices
-
_Add the role _
-
Keep it out of the ontology ==== Discussion
This role is ambiguous and should be first defined precisely, and likely re-labelled. In ePO v2.0.2 epo:CandidateShortlist epo:hasQualified …
Title: sub-role table in EU Vocabularies
Issue
-
What does this table cover? Currently, the sub-roles are modelled as relations between (e.g. Buyer, ProcurementServiceProvider) and Lot, and other ones.
-
DG-Grow(ESDP) proposes a sub-roles table and there is another table proposed by GD-Grow (eForms).
Discussion
Alignment attempt between EPO and ESPD and eForms.
Group Leader, Group Member are more roles than sub-roles.
The hypothesis of why roles and sub-roles were split:
-
There was a focus on the pre-award / notification phase and therefore the roles are those that are relevant in that phase, and sub-roles are possibly also roles but for other phases.
The situations are anchored either in an obligation modality or in a temporal modality
-
We record future commitments
-
Or actual facts
Possible situations where “sub-roles: occur:
-
Payment
-
Informing
-
Submission (two-stage procedure: 1. Request to participate, that has to be evaluated and then, 2. Submission of the actual tender)
-
Evaluation
What we do not know:
-
How to model the roles and sub-roles. We are missing the situation/context/phase.
-
Sub-roles can be delegated by “main roles”
-
The delegation shall be contextualised for a procedure
Working Group meeting 02/09/2021
Date: 02/09/2021
Participants: Paloma Arillo Aranda (OP), Eugeniu COSTETZKI (Meaningfy), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Andrea PASARE (xx) and Giampaolo Sellitto (ANAC)
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Norway’s Database for public procurement (DOFFIN by its Norwegian acronym)
Issues
-
(4)The JSON file: The description is split into several lines in the JSON file because it is easier to read the HTML file. Same as in the EPO RDF we have several elements <P>. In the construction of the Jason file it is assumed that there is one line per information and it is the result of transforming the file. Giorgia has to check a way to merge all the information in one file.
-
(1)Zip of all data that are distributes using folders that contain years and month and there is a subfolder per day and then inside each there are atomic files per notice. If we think on DICAT AP a data set that focuses in only ones notice would be weird to be considered as a data set so it was decided to add information. The way that Italy does is a good one so it was decided to do monthly distribution and per notice type. We can share the analysis done by BDTI??? Aligned to Italy, which is also easier to access for humans so that there is a homogeneous set of information. We used the TED mapping to analyse the presentation of the Norwegian data: they stored more information about the notices. In xml file in TED we could not find the information about the notice ID
-
(2)Main CPV per lot – it seems that in the Norwegian model the ‘additional cpv’ it is mapped to the lot and the the main cpv is mapped at procedure level. In the mapping current forms to eForms the additional is part of the current forms. In the new forms, we should use ‘main cpv’ for both, procedure and lot in the future. Maybe the Norwegian data does not correspond to the current mapping with the ’additional’ classification although this is not used when there is only one lot. In the Norwegian model if there are several lots both, main and additional are used.
Discussion
The JSON file: procedure has main cpv, the procedure has one lot and the additional code is the same as the main but with an additional zero at the end. It seems to be the same hierarchy.
The current form has main cpv as repeateable in the additional cpv section together with supplementary cpv. In the ePO the predicate is ‘main classiffication’. TED current forms: lot = additional cpv. Supplementary is about an additional information about that cpv code in the sense of main additional code.
The solution would be to speak about cpv without ‘main’ and ‘additional’.
In Norway the additional is not a mandatory field, so in some cases te cpv is not there, the same as in the TED data. In the Norwegian dataset the main cpv is mandatory.
In the ePO the main classification is mandatory and additional classification o to several. It is wrong because the situation changed with eFORMS. In the current forms the information is not good enough. In the eForms you can use main and additional in both procedure and lot but for lot is optional. We cannot change the model for the BDTI project so we stick to additional and this will be revised in the new version of model taking into consideration the eFORMS point of view and the current forms.
-
(6)NUTS codes – it seems that no always the NUTS code is provided in the Norwegian model. It is there but not in the same granularity. In the Jason file there is nothing similar to a nuts attribute. Hilde will investigate and call a short meeting about this issue.
-
(3)Notice uuid – the Nowegian case there isnno ID but ‘form section uuid’. Norway does not have an Official Journal so there are troubles mapping to the TED dataset. If we have the procedure, we can find it in the TED data and in the Norway notice. The question is whether there is a need to map the contract notice and the contract award notice. The ID is not unique in the Norwegian notices. The DOFFIN number is added because there is one sole place where notices are archived and it is an internal reference number. The hope is that the model and the new EFORMS will bring data quality and that the information will be done almost automatically.
Working Group meeting 31/08/2021
Date: 31/08/2021
Participants: Paloma Arillo Aranda (OP), Eugeniu COSTETZKI (Meaningfy), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Andrea PASARE (Meaningfy) and Giampaolo Sellitto (ANAC)
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Topics
Comments in EA
Could the additional info and the date added in the descriptions of the ePO be transformed and added as part of the element? (To be checked).
Queries
The ePO is the Ontology for Public Procurement. The BDTI is a pilot project set up with ISA2 in order to enable linking open data: to be able launch SPARQL queries from different databases. The goal is to transform the ePO into RDF as are other ontologies. The main issue is the transformation: respect data format, do the mapping, try to connect and link the data from the three countries participating in the BDTI project (Italy, Portugal and Norway).
Giorgia has tested launching a query in the BDTI. The WG has also tried to launch a query in GraphDB. These tests should be repeated when the data is updated.
The WG updated the query live and ran a test:
-
In the EPO “isResponsiblityOf’ should be corrected to ‘isResponsibilityOf’
-
Amount: in the ePO data, ’Amoun’t uses ‘ctts’ instead of ‘epo’; that should be considered in the query
-
In the TED data lot it should be ‘hasContractAwardedValue’ not ‘LotAwardedValue’.
-
It should be noted when the ePO uses data different to the that used in the queries.
-
currencyCode was added to the query
The date was also added
If we want the indicator, ‘hasAcceleratedProcedure’ should be used
The query launched will belong to the BDTI queries, as does this project, which will use it. In the ideal world, the query could be used by other datasets.
Working Group meeting 17/08/2021
Date: 17/08/2021
Participants: Paloma Arillo Aranda (OP), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Issues
GitHub Issues Update
The following issues have been discussed and updated:
Issue 187: Cardinalities properties and attributes – updated & closed
Issue 185: Agent – updated
Issue 184: Class create class "CV template" – updated & closed
Issue 177: ESPD documents and criteria – updated with label
Issue 174: ESPD Candidate short list – updated
Issue 173: Economic operator short list – updated
Issue 171: Subcontracting obligations and requirements – updated
Issue 170: Rename ‘Purchase Contract’ as ‘Specific Contract’ – updated
Issue 165: Codelist MULTIPLE Make authority codes human-readable – updated
Issue 164: Codelist; economic-operator-size; No single code for SME? – closed
Issue 161: Technique Validity Period and Contract hasDuration Period – updated
Issue 103: Glossary - Change – updated
Working Group meeting 27/07/2021
Date: 27/07/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Issues
GitHub Issues Update
The following issues were discussed and updated:
Issue 295: reuse more from the EC core ontologies – updated and closed
Issue 293: reg2015 owl-core mixes up label and namespace – to be discussed further with ECO and to be updated
Issue 303: latest version and tracker? – closed
Issue 299: add specific subclasses of Concept or restrictions on Conceptschema – updated
Issue 282: Economic Operator class: Erole type property – updated
Issue 281: Predicate harmonization – updated
Issue 279: Buyer definition does not cater for post award needs – updated
Working Group meeting 22/07/2021
Date: 22/07/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Giorgia Lodi (ISTC-CNR) and Giampaolo Sellitto (ANAC)
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Issues
GitHub Issues Update
The following issues were discussed and updated:
Issue 299: add specific subclasses of Concept or restrictions on Conceptschema – to check the ESPD source in that owl example.
Issue 298: revise prop naming convention – updated
Issue 297: avoid unspecific properties – updated
Issue 296: doubled restriction – updated
Issue 295: reuse more from the EC core ontologies – updated
Issue 294: dash or underscore in file name? – updated
Issue 293: reg2015 owl-core mixes up label and namespace – to be discussed and to be updated
Issue 292: glossary? No, “UML model” and “data dictionary” – add label ‘wiki mantenaince’
Issue 291: procedure ttl – updated
Issue 290: instead of busy term definitions use structured metadata fields – updated
Issue 289: issues related to model2owl – no comment
Issue 288: stick to the naming convention – updated and closed
Issue 287: don’t use too many namingspaces – updated add label ‘Namespace’
Issue 284: ecatalogue metadata – to be revised add label label Ecatalogue
Issue 283: has FullfillsRequirement property name – updated
Issue 308: add headings to minutes – label wiki maintenance
Issue 281: predicate harmonization – updated
Working Group meeting 20/07/2021
Date: 20/07/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP) and Giampaolo Sellitto (ANAC)
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Issues
GitHub Issues Update
The following issues were discussed and updated:
Issue 307: Subcontractor vs hasSubcontracted (relates to 306) – updated
Issue 306: Link of Role and Procedure – updated
Issue 305: Role-ContactPoint props, discrepancy between ontology and conceptual model – updated
Issue 304: rdf:PlainLiteral instead of rdf:Literal – updated
Issue 303: latest version and tracker? – updated
Issue 302: questions about Amount and Value – updated
Issue 301: every term must have a definition – work ongoing
Issue 300: add superclass epo:ProcurementWithSpecificRequirement – closed
Issue 299: add specific subclasses of Concept or restrictions on Conceptschema– updated
Working Group meeting 06/07/2021
Date: 06/07/2021
Participants: Paloma Arillo Aranda (OP), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Topic: The Italian Model
Work:
Within the context of works pertaining to environment related tenders such as extreme event interventions, for example, preventing fires, the Italian colleagues would like to use the ePO data to harmonize the terminology. For example, “procedure contract nature’ corresponds to the ePO ‘work’. The right mapping is ‘procurement project’. The ‘project’ class was discarded by the ePO WG in the past because a project has different procedures with different lots.
Supervisor authority:
In the procedures mentioned above there is a authority tthat controls the way these works are executed. This does not correspond to any role in our ontology because it is not a ‘reviewer’ but rather a controlling role that ensures that the work has been carried out properly. The ePO model does not need this role because the scope is the notice and not the frame of administrative matters.
Unique responsiblity for the procedure:
This belongs to the buyer, correspondings to the buyer contact point in the ePO. The buyer has a contact point meaning a person. It is not the buyer profile, because this is the web page. In the Italian procedures the buyer is an organisation while the role of contact point is played by a person. In ePO model version 2.0.1 there is a ‘buyer’ who has a ‘contact point’, but the contact is a channel but not the name of the person.
In Italy the buyer is a juridical person, the contact is a natural person. TED has a contact point in the contact data but not in the eForms.
Agent:
ePO agent class – the agent is connected to the role, a person inherits from agent. In Italy an agent can act on behalf of another agent and it can be mapped to the ePO.
CPV example:
there are many buyers but only one responsible for the procedure. The problem comes from the definition of ‘buyer’ in the directives. The one that publishes the procedure does not necessary buy.
In the current forms, ‘buyer’ is responsible for the procedure while in eForms their ‘buyer’ is not necessarily responsible for the procedure. Italy will try to explain whata buyer and other roles are, and will add a join procurement indicator, for example when the contracting authorities cannot buy by themselves but together.
It is possible that one specific beneficiary body proposes the procedure but then another authority implements the procedure. This does not exist in the ePO. Kind of ‘acts on behalf of’. We should have 2 arrows in the ePO model as we have in the OWL: ‘acts on behalf of’ is the inverse of ‘delegatesAncilliaryActivitiesOn’.
Service provider:
for example receives the tenders, it helps the buyer. The other agent delegates on the service provider.
Interventions:
are they in the data set? The Italian colleagues could try to extract the procedures of the example of contracting authority provided by Giorgia and check the data. Attention should be paid when importing data into Excel because the figures are not always well imported in csv. Concerning the Italian identifiers there is no always a mapping between the CUP and the CIG (both used in Italy) These CUP is only mandatory for contracts that produce value. Some countries have an identifier similar to the Italian CIG It is possible toassociate the CIG to the lot number given in TED. In TED there is one code to send something to publication, a kind of tender number, and one code that is use more like a CIG.
Working Group meeting 10/06/2021
Please find below the minutes from 10 June 2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Katia Infante (ANAC), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Thor Steiner Møller (dfø), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
The meeting on 8 June 2021 was cancelled.
Topic of discussion: Value
Natalie presented a way of analysing the business terms and the WG agreed to adopt it. In the same document here you can find the discussion held and decisions made during the meeting concerning "Value".
The WG raised a question for eForms : Does BT-157 really want a Group of Lots or Lots within a FrameworkAgreement? ‘Group of Lots’ is not mentioned in the Directives 2014/24 and 2014/25.
Working Group meeting 03/06/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Thor Steiner Møller (dfø), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
Topic of discussion: Check Summary from 01 June 2021 and update decisions
-
Contract has no relation with Value in v2.0.2 but does in 2.0.1.
Proposal: rename ‘Value’ to ‘MonetaryValue’ in the new version of the Ontology (this new version will incorporate updates to definitions and predicates with regard to 2.0.1, and will add certain features from 2.0.2). We have to consider the implication of this change for all mappings, such as ANAC Data, Consip Data and TED Data.
-
Maximum and Minimum were proposed to be used as predicates in 2.0.1 and 2.0.2.
-
The predicate ‘hasAwardEstimatedValue’ cardinality should be changed to ‘0 .. *’
-
We have to identify all ‘MonetaryValue’ instances in the model to link them to other classes.
-
The following point was brought up: If there is an AwardedValue for the FrameworkAgreement and an AwardedValue for the Contract, is that not a contradiction because the FrameworkAgreement is a Contract?
FrameworkAgreement: either has no value and the value is of the contracts derived from it, or it is considered to be the total value of the FrameworkAgreement. Otherwise one ends up with a double value.
A comparison of these concepts in the model and the Business Terms in eForms and current forms need to be drawn up to check and ensure that the WG creates a model that reflects the use cases of both, current forms and eForms.
Topic of discussion: Amount
-
It might be possible to eliminate the class Amount by inserting an amount:numeric and currency:skos in the MonetaryValue. It must be checked if the same can be done for Amount and Quantity.
-
In the TED mappings the data is mapped to ‘ccts’ and not ‘epo’ as per the OWL file.
-
When checking notice 2020/S 243-602968 it was noted that the minimum and maximum offer is used, which is different to the maximum and minimum value of the contract and should probably be associated to the tender as shown in the model created in the last meeting.
Topic of discussion: Plans for the near future
-
Apply the Reification on the whole model.
-
Finalize eOrdering and eCatalogue
-
Add the ESPD to the Ontology once an ESPD UML data model is available.
-
Ensure there is placeholder in the Ontology conceptual model for indicating data during the contract’s life cycle.
Working Group meeting 10/06/2021
Please find below the minutes from 10 June 2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Katia Infante (ANAC), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Thor Steiner Møller (dfø), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
The meeting on 8 June 2021 was cancelled.
Topic of discussion: Value
Natalie presented a way of analysing the business terms and the WG agreed to adopt it. In the same document here you can find the discussion held and decisions made during the meeting concerning "Value".
The WG raised a question for eForms : Does BT-157 really want a Group of Lots or Lots within a FrameworkAgreement? ‘Group of Lots’ is not mentioned in the Directives 2014/24 and 2014/25.
Working Group meeting 27/05/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
Topic of discussion: Definitions – predicates
The following relations were discussed and compared with the html conventions to see if this work will correct the inconsistencies:
-
Subject: ContractModificationNotice
Predicate: ‘modifies’ is replaced with ‘announcesModification’
Object: Contract
-
Subject: Procedure
Predicate: uses
Object: AccessTerm
Inverse: isSubjectTo
-
Subject: PlannedProcurementPart
Predicate: uses
Object: Channel
This relation is deleted as it is not required in the mapping.
-
Subject: FrameworkAgreementTechnique
Predicate: uses
Object: EAuctionTechnique
This relation is deleted as it is not required in the mapping. It is not clear if FrameworkAgreement or the FrameworkAgreementTechnique uses the eAuctionTechnique.
-
Subject: Procedure
Predicate: uses
Object: ExclusionGround
The CCCEV has to be revisit as this relation needs to be changed. Lot should specify the procurement criterion which should in turn be related to the CCCEV.
-
Subject: LotGroup
Predicate: uses
Object: ‘FrameworkAgreementTechnique’ replaced with ‘Technique’ as FrameworkAgreementTechnique is a Technique
Definition: Relation indicating that a lot or a grouplot uses a technique
Inverse: is UsedBy
This needs to be checked in more detail.
-
Subject: Lot
Predicate: uses
Object: Technique
Some definitions have been added to the relations discussed on 18 and 25 May. The minutes have been updated.
Working Group meeting 25/05/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
Due to unavailability of a part of the WG members the meeting on 20 May 2021 was cancelled.
Topic of discussion: SPARQL Queries analysis
-
Possible error detected: superfluous 'P' HTML element in the queries. This is not a real error as it was requested to be added to the text in order to separate the sentences with paragraphs.
-
Link: if we have the Procedure ID it should not be a problem to launch a query to map TED data with the National ID for that procedure. Queries will have to be adapted and finetuned to meet Procedure without corresponding ID.
-
epo:identifierValue should be epo:hasIdentifierValue
-
epo:isResponsiblityOf should be isResponsibilityOf
-
How could we detect the possible spelling mistakes in the mapping in order to correct them to run the SPARQL queries. Maybe with SHACL Shapes?
Action Points
-
Look into ways of treating paragraphs in pdf
-
epo:insert verbs infront of attributes instead of using has by default
Topic of discussion: Definitions – predicates
The following relations were discussed and compared with the html conventions to see if this work will correct the inconsistencies:
-
Subject: AwardDecision
Predicate: refersTo
Object: Lot, LotGroup
AwardDecision is a Document. The WG checks the reification. It is decided to keep it as it is as it will be used for version 2.0.1
-
Subject: Contract
Predicate: refersTo
Object: Lot
Contract is a Document. The WG decides that is probably should follow the reification. To be discussed
-
Subject: Contract
Predicate: refersTo
Object: Tender
Definition: Realtion indicating a document mentions another document.
Contract is a Document. Tender is a Document.
-
Subject: ContractModificationNotice
Predicate: ‘refersTo’ replaced with ‘Modifies’
Object: ContractAwardNotice
Definition: Realtion indicatin a ContractModificationNotice announces a modification of a contract.
ContractModificationNotice is a Document. ContractAwardNotice is a Document.
-
Subject: PlannedProcurementPart
Predicate: refersTo
Object: Document
To be checked if this relation can be deleted when doing a new mapping.
-
Subject: ‘TenderLot’ replaced with ‘Tender’
Predicate: ‘refersTo’ replaced with ‘specifiesItem’ and this replaced with 'itemises'
Object: Item
Definition: Relation indicating a tender or a lot details an item
Inverse: itemItemisedBy
Definition: Relation indicating an item is detailes in a tender or lot
-
Subject: Lot
Predicate: ‘refersTo’ replaced with ‘specifiesItem’ and this replaced with 'itemises'
Object: Item
Definition: Relation indicating a tender or lot details an item
Inverse: itemItemisedBy
Definition: Relation indicating an item is detailes in a tender or lot
-
Subject: Lot
Predicate: ‘refersTo’ replaced with ‘isDerivedFrom’
Object: PlannedProcurementPart
Definition: relation indicating from where the lot stems
Inverse: becomes
Definition: Relation indicating a PlannedProcurementPlan becomes a lot or a procedure
-
Subject: Document
Predicate: relatesTo
Object: Procedure
Definition: Relation indicating a document used in the context of a procedure
-
Subject: TenderLot
Predicate: 'relatesTo' replaced with 'isSubmittedFor'
Object: Lot
Definition: Relation indicating a TenderLot is submitted for a lot
-
Subject: Lot
Predicate: specifies
Object: 'SelectionCriterion' replaced with 'ProcedureCriterion'
-
Subject: Procedure
Predicate: isComposedOf
Object: Lot
Working Group meeting 18/05/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Natalie Muric (OP) and Giampaolo Sellitto (ANAC).
Topic of discussion: Relation subject-object - check definitions
Before discussing the relations subject-object and the predicates, the WG redefines the following:
-
FrameworkAgreementTechnique
Definition: Technique that establishes the terms governing contracts to be awarded during a given period, in particular with regards to price and, where appropriate, the quantity envisaged.
The technique is prepared during the procedure and it becomes active when the contract is signed.
-
FrameworkAgreement
Definition: An agreement between one or more contracting authorities and one or more economic operators.
Topic of discussion: Definitions - predicates
The following relations were discussed and compared with the html conventions to see if this work will correct the inconsistencies:
-
Subject: AwardDecision
Predicate: isReferredByA
Object: Contract
To potentially be removed if not used in mappings 5it causes no problem in the rangedomain scope).
-
Subject: Lot
Predicate: isReferredByA
Object: Contract
-
Subject: Subcontract
Predicate: isReferredToIn
Object: AwardDecision
This relation is removed. However the WG decides to look later how to redo the mapping maybe as statistical information or ‘subcontracting’
-
Subject: AwardDecision
Predicate: isReferredToIn
Object: Subcontract
This relation is removed.
-
Subject: Lot
Predicate: isReferredToIn
Object: ProcurementDocument
Definition: Relation indicating that the Lot is referenced in the ProcurementDocument.
-
Subject: Lot
Predicate: isSpecifiedIn
Object: Procedure
Definition: Relation indicating that the Lot is referenced in the Procedure.
-
Subject: StrategicProcurement
Predicate: isSpecifiedIn
Object: ResourceElement
This relation is removed.
-
Subject: Document
Predicate: isSubmittedBy
Object: Agent
This relation is removed.
-
Subject: Tender
Predicate: isSubmittedBy
Object: Tenderer
Definition: Relation indicating the economic operator that submitted a tender.
Inverse: submits
Definition: Relation indicating the submission of a tender by an economic operator
-
Subject: FrameworkAgreementTerm
Predicate: isSubmittedBy
Object: LotGroup
This relation is removed.
-
Subject: AwardDecision
Predicate: refersTo
Object: Lot, LotGroup
To be discussed with the rest of the WG members.
-
Subject: Contract
Predicate: refersTo
Object: Lot, Tender
To be discussed with the rest of the WG members.
-
Subject: ContractModificationNotice
Predicate: refersTo
Object: ContractAwardNotice
To be discussed with the rest of the WG members.
-
Subject: PlannedProcurementPart
Predicate: refersTo
Object: Document
To be discussed with the rest of the WG members.
-
Subject: TenderLot
Predicate: refersTo
Object: Item
To be discussed with the rest of the WG members. On 11 May 2021 it was decided to replaced 'TenderLot' with 'Tender'. For th etime being the change will not be applied.
-
Subject: Lot
Predicate: refersTo
Object: Item, PlannedProcurementPart
To be discussed with the rest of the WG members.
-
Subject: Document
Predicate: relatesTo
Object: Procedure
-
Subject: TenderLot
Predicate: ‘relatesTo’ is replaced with ‘isSubmittedFor’
Object: Lot
Definition: Relation indicating the TenderLot is submitted for a Lot.
-
Subject: Lot
Predicate: specifies
Object: SelectionCriterion
-
Subject: Procedure
Predicate: isComposedOf
Object: Lot
Working Group meeting 11/05/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM), Svante Schubert (TTC 440) and Giampaolo Sellitto (ANAC).
Topic of discussion: Definitions - GroupLot
Presents an example how an economic operator can present 2 tenders for 2 lots separately or one tender for both lots together as a group of lots.
-
Subject: LotGroup
Predicate: isAwardedTo
Object: TenderLot
Note: ‘Lot’ as per Directive 2014/24/EU
‘TendeLot’ seems to be the minimum common denominator. The decision is to:
-
mantein TenderLot,
-
put the electronicSubmissionIndicator and all the propertiesof Tender in TenderLot
-
remove Tender
-
rename TenderLot to Tender.
The properties appear in the model but we can replace it with just ‘Tender’ for each lot or group of lots so as not to mix the transport of data with the semantics. See also Group of Lots slides from Norway 11/05/2021 where attributes of TenderLot are combined into Tender. The WG has to check the mappings.
Topic of discussion: Definitions - predicates
The following relations were discussed and compared with the html conventions to see if this work will correct the inconsistencies:
-
Subject: Procedure
Predicate: ‘isConludedBy’ replaced with ‘hasBuyerWebsite’
Object: Contract
Definition: Relation indicating the website of the buyer
The meeting on Thursday 13 May is cancelled.
Working Group meeting 06/05/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM), Svante Schubert (TTC 440) and Giampaolo Sellitto (ANAC).
Topic of discussion: Definitions - predicates
The following relations were discussed and compared with the html conventions to see if this work will correct the inconsistencies:
-
Subject: Buyer
Predicate: ‘has’ replaced with ‘hasBuyerWebsite’
Object: BuyerProfile
Definition: Relation indicating the website of the buyer
-
Subject: ContactPoint
Predicate: ‘has’ replaced with ‘hasChannel’
Object: Channel
Definition: Relation indicating a concept has a communication channel
Note: Not needed here. To be checked if this relation is needed in planning and any mapping
-
Subject: Role
Predicate: ‘has’ could be replaced with ‘hasContactPoint’
Object: ContactPoint
Note: new name of predicate to be reviewed with reification
-
Subject: Procedure
Predicate: ‘has’
Object: DirectAwardTerm
Note: to be reviewed based on discussion on 4 May 2021 if ‘has’ should be replaced with ‘isSubjectTo’. Follow patterns and possibly abstract class decision
-
Subject: PlannedProcurementPart
Predicate: ‘has’
Object: ContractTerm
Note: to be reviewed based on discussion on 4 May 2021 if ‘has’ should be replaced with ‘isSubjectTo’
-
Subject: EvaluationBoard
Predicate: ‘has’ replaced with ‘evaluates’
Object: ExclusionGround
Definition: Relation indicating who evaluates a criterion
Inverse: isEvaluatedBy
Definition: Relation indicating by whom a criterion is evaluated
-
Subject: Lot
Predicate: ‘has’ replaced with ‘hasPurpose’
Object: Purpose
Definition: Relation indicating a contract, procedure, lot or planned procurement part has a purpose
Note: need to change relationships for procedure (overall purpose).
-
Subject: Lot
Predicate: has
Object: OpeningTerm
Note: to be reviewed based on discussion on 4 May 2021 if ‘has’ should be replaced with ‘isSubjectTo’
-
Subject: Procedure
Predicate: has
Object: ProcedureTerm
Note: to be reviewed based on discussion on 4 May 2021 if ‘has’ should be replaced with ‘isSubjectTo’
-
Subject: Lot, GroupLot
Predicate: hasAwardedValue
Object: Value
Note: to be reviewed with ‘Values’
-
Subject: Lot, GroupLot, Procedure, Subcontract
Predicate: hasEstimatedValue
Object: Value
Note: to be reviewed with ‘Values’
-
Subject: ContactPoint
Predicate: hasLocation
Object: Location
-
Subject: Document
Predicate: hasNonPublishedElement
Object: PublicationProvision
Definition: Relation indicating that part of a document is not published
-
Subject: PublicationProvision
Predicate: ‘hasNonPublishedElement’ replaced with ‘isForResourceElement’
Object: ResourceElement
Definition: Relation indicating that the publication provision applies to a given field of a document
-
Subject: Tender, TenderDocument
Predicate: hasSubmissionTerm
Object: SubmissionTerm
Note: to be reviewed based on discussion on 4 May 2021 if ‘hasSubmissionTerm’ should be replaced with ‘isSubjectTo’
-
Subject: ContractTerm
Predicate: ’includes’ replaced with ‘hasSubTerm’
Object: SubcontractTerm
Definition: Relation indicating a term has a subterm
Inverse: isSubTermOf
Definition: Relation indication a term is a subterm of another term
-
Subject: Document
Predicate: includes
Object: RegulatoryFrameworkInformation
Note: Element and its relations not needed in Notification
-
Subject: Tender
Predicate: includes
Object: TenderLot
Definition: Relation indicating a Tender has a TenderLot
Inverse: isIncludedIn
Definition: Relation indicating a TenderLot is included in a Tender
-
Subject: Lot
Predicate: isAwardedTo
Object: TenderLot
Note: Question as to whether Lot awarded to ‘tender’ or ‘tenderer’. WG decision: must be ‘tender’ as one tenderer may submit several tenders
-
Subject: LotGroup
Predicate: isAwardedTo
Object: TenderLot
Note: If ‘Lot’ is to LotGroup then ‘TenderLot’ is to TenderLotGroup and therefore a LotGroup isAwarded to TenderLot (,). To be discussed in the next meeting.
Actions:
-
to find use case
-
to find old notes and ppts on this point
Next meeting to be held on Tuesday 11 May 2021
Working Group meeting 04/05/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM), Svante Schubert (TTC 440) and Giampaolo Sellitto (ANAC).
Topic of discussion: Definitions - predicates
The following relations were discussed and compared with the html conventions to see if this work will correct the inconsistencies:
-
Predicate: fulfilsRequirement
Note: the OWL generates ‘hasFulfilsRequirement’ as it is an attribute of the class. All attributes need to be manually checked and ‘has’ or another verb used. Using fulfilsRequirement from three different sources is not a problem as the range is an SKOS concept.
-
Subject: PlannedProcurementPart
Predicate: has
Object: AccessTerm
Note: predicate and relations to be discuss with the UML to OWL project team following the 3 different situations described below and discussed during the meeting
-
Current situation Procedure isSubjectTo ContractTerm and AccessTerm, while PlannedProcurementPart isSubjectTo AccessTerm.
However the way this is currently designed means that there is no possible restriction: in the OWL transformation everything in the domain (Procedure or PlannedProcurementPart) would be subject to anything in the range as we cannot differenciate what is subject of what.
-
Proposal 1 The introduction of an abstract class ‘ProcurementTerm’ allows ContractTerm and AccessTerm to inherit from that class ‘ProcurementTerm’.
-
Proposal 2 A change in the domain, ‘OWLThing’, and the introduction of the abstract class will allow that any class is subject to the abstract class ‘ProcurementTerm’.
-
-
Subject: Address
Predicate: has
Object: LocationCoordinate
Note: predicate to be discussed when redefining Location ‘hasGeometry’ or ‘hasLocationCoordinate’
-
Subject: AwardDecision
Predicate: ‘has’ replaced with ‘specifiesWinner’
Object: Winner
Definition: Relation indicating that the AwardDecision defines a winner
Inverse: isWinnerDefinedIn
Definition: Relation indicating that a winner is defined in an award decision
-
Subject: AwardDecision
Predicate: has
Object: Subcontract
Note: this relation is discarded as BT-55 can go through TenderLot and BT-554 should probably be a calculation of the total value of all subcontracts related to a tender lot (could be provisionally put in a CAN – to be discussed)
The next meeting will be held on Thursday 06 May.
Working Group meeting 29/04/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM) and Giampaolo Sellitto (ANAC).
Topic of discussion: Conventions report
Short summary concerning the conventions report version 2.0.1 and the project conversion of notices from xml format to rdf.
Topic of discussion: Definitions - predicates
The following relations were discussed and compared with the html conventions to see if this work will correct the inconsistencies:
-
Subject: SecurityClearanceTerm
Object: Winner
Predicate: applies
It was decided to remove this relationship as it is not required. If any such relationship is required in the future it should be studied within its use case.
-
Subject: TenderLot
Object: LotGroup
Predicate: appliesTo - renamed to ‘isSubmittedFor’
Definition: Relation showing that a TenderLot is submitted for a group of lots
Inverse: hasTenderLot
Definition: Relation indicating a GroupLot has a TenderLot associated to it
-
Subject: SelectionCriterion
Object: LotGroup, Lot
Predicate: ‘appliesTo’ renamed to ‘isSpecifiedIn’
Definition: Relation indicating a selection criterion in a given Lot or LotGroup
Inverse: specifies
Definition: Relation that indicates the conditions for selecting economic operators for tendering
-
Subject: Contract
OBJect: Document
Predicate: attaches
Definition: Relation indicating that a Thing includes a document
Inverse: isAttachedIn
Definition: Relation indicating a document is included in a Thing
-
Subject: Tender
Object: TenderDocument (inherited from Document) change in Model
Predicate: attaches
Definition: Relation indicating that a Thing includes a document
Inverse: isAttachedIn
Definition: Relation indicating a document is included in a Thinbj * Subject: Buyer and its relations are correct. No need to review.
Working Group meeting 27/04/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM) and Giampaolo Sellitto (ANAC).
Topic of discussion: Summary review previous week
The the minutes of the previous week were approved.
Topic of discussion: Definitions - predicates
The following relations were discussed and a check is to be done in the html conventions to see if this work will correct the inconsistencies:
-
Subject: Lot
Object: ContractTerm, FrameworkAgreementTerm, MultipleStagesProcedureTerm, SubmissionTerm, DesignContestRegimeTerm, FrameworkAgreementTerm.
Predicate: applies – renamed to ‘isSubjectTo’.
Definition: Relation that specifies rules that are applicable to the lot.
Inverse: isAppliedby – renamed to ‘setsContextFor’.
Definition: Relation that specifies the lot to which these rules apply.
-
Subject: Procedure
Object: Lot
Predicate: specifies – renamed to ‘isComposedOf’
Definition: Relation showing a component part of a procedure.
Inverse: specifiedIn – renamed to ‘IsComponentOf’
Definition: Relation showing the lot is part of the procedure.
-
Subject: Lot
Object: SelectionCriterion
Predicate: specifies –
Definition: Relation that indicates the conditions for selecting economic operators for tendering.
Invese: isSpecifiedIn
Definition: Relation indicating a selection criterion in a given lot.
-
Subject: StrategicProcurement
Object: ResourceElement
Predicate: isSpecifiedIn - To check in EA if it should be removed. The WG does not see the reasoning for this property it does not seem to map to anything
-
Subject: DesignContestRegimeTerm, FrameworkAgreement
Object: Lot
Predicate: appliesTo – removed
Note: check mapping
-
Subject: SecurityClearanceTerm
Object: Document, Location
Predicate: appliesTo: renamed to ‘describesAccessRestrictionsTo’
Definition: Relation that specifies access rules
Inverse: applies – renamed to ‘hasSecurityClearanceTerm’
Definition: Relation indicating that security clearance is required for access
Note: org:site to be replaced by epo:location
Working Group meeting 22/04/2021
Participants: Paloma Arillo Aranda (OP), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM) and Giampaolo Sellitto (ANAC).
Topic of discussion: Definitions
The following concepts were defined in the meeting:
-
epo:TenderDocument – Document that is part of the tender.
-
epo:Value – postponed until discussion on lots values and amounts.
-
org:Site – Note: There is a problem here. See diagram Procurement, which uses org:site for the SecurityClearanceTerm. It is generally used in the context of a defence procurement (the tenderer needs to get clearance to access documents for example). There is no need to map to the eForms, as eForms need only a date and the description. org:Site can be removed as we have no use case for it and is is not needed in the eNotification. The WG has now finished the definition of all classes and attributes.
Topic of discussion: GitHub
A cleanup of the ePO GitHub is planned for a near future where the versions might be merged or a new version 2.0.3 will be published.
Topic of discussion: Inconsistencies to be addressed
Based on the document https://github.com/OP-TED/model2owl/blob/master/test/reasoning-investigation/findings.md the WG starts checking the inconsistencies that need to be address in the ePO. These inconsistencies arise from the fact that generic predicates are used such as “RefersTo”:
-
ContractModificationNotice RefersTo ContractAwardNotice
-
Contract RefersTo Tender
By using the same predicate as described above from the OWL core it can be implied that the ContractModificationNotice RefersTo Tender however this is not true. There are several solutions to correcting this problem:
-
keep ‘refersTo’ as it is in the model now and ask the transformation script to add a reference to the class it is pointing to make it more specific ie Transform ContractModificationNotice RefersTo ContractAwardNotice toContractModificationNotice RefersToContractAwardNotice ContractAwardNotice
This is not considered a good idea as it is not evident to business people reading the diagram
-
Manually transform ContractModificationNotice RefersTo ContractAwardNotice toContractModificationNotice RefersToContractAwardNotice ContractAwardNotice
Check all predicates to ensure they make business sense then either
-
alter them as described above,
-
change them to make better sense
-
keep them
In each of these scenarios it has to be ensure that no cross referencing can provide false assumptions Note: Contract and Notice are both are subclasses of Document. The document ‘Findings of reasoning with eProcurement ontology’ states ‘Contract disjoint with Notice’ (Date 3 March 2021). However:
a) In the restrictions Version of 3 March 2021 the ‘disjointness’ does not seem to be indicated in the model. Questions:
-
Has a rule been implemented in the transformation that subclasses of the same class are disjoint?
-
Why dcterms in restrictions? See issue: https://github.com/OP-TED/model2owl/issues/75
b) In the restrictions Version of 17 March 2021 the ‘disjointness’ does not seem to be indicated, unless the core is imported into the restrictions. The restrictions file does not show that Contract or ContractModificationNotice are subclasses of Document and the ‘disjointness’ is not indicated.
A solution to how disjointness is to be defined needs to be found. See https://github.com/OP-TED/model2owl/issues/76
The next meetings will address harmonizing the predicates. They will be addressed alphabetically. The working group checked the first predicates and decided in the next meeting to address:
-
appliesTo
-
applies
-
attaches
-
combinesLotsInto
-
isConcludedBy
-
fulfillsRequirement
-
isFundedBy
-
has
Working Group meeting 20/04/2021
Participants: Cécile Guasch (ISA2 - DIGIT), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM) and Giampaolo Sellitto (ANAC).
Topic of discussion: DigitAll Conference
The meeting was reduced in time due to the DigitALL Public Conference. (https://digitallpublic.eu/)
It was noted that there was some overlap in the presentation “Road towards a European semantic toolchain for public administrations – state of play and future developments” (Thursday, April 22, 2021 9:30 AM to 11:00 AM) and “Turning UML models into OWL ontologies and SHACL data shapes in the eProcurement ontology project” (Tuesday, April 20, 2021 4:30 PM to 5:30 PM) which is a result of the eProcurement ontology.
The presentation “How to make the most of procurement data” is of particular interest to this working group. (Thursday, April 22, 2021 9:30 AM to 11:00 AM)
Topic of discussion: Definitions
-
epo:RequestForClarification – A demand for elucidation of received information Additional information: Requests for clarification are usually used by buyers during the process of award or evaluation to understand specific aspects of the tender without altering the tender.
-
epo:RequestForParticipation – Application of an economic operator to be included in a procurement procedure.
-
epo:Reviewer - Role of an agent who investigates the overall correctness of a procurement procedure, producing a related report. Additional information: Any organisation or person may request a review of a procurement procedure.
-
epo:TechnicalSpecification - A set of documented requirements applicable to the object of the procurement. Additional information: A specification often includes technical standards.
-
epo:Mediator - A role of an agent that attempts to resolve a dispute between different agents and come to an agreement.
Working Group meeting 15/04/2021
Participants: Ana Aido, Paloma Arillo Aranda (OP), Eugeniu Costezki, Cécile Guasch (ISA2 - DIGIT), Veit Jahns (TC440), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM), Giampaolo Sellitto (ANAC), Jalini Srisgantharajah (dfø). Topic of discussion: Reification and eNotification
Considering the extensive work carried out on the reification and eNotification models, the Working Group (WG) proposes that the work integrating the reification in the eNotification model can be produced outside the working group and that the WG can validate the result or request certain changes.
The WG in the mean time will concentrate on:
-
providing definitions for concepts where they are missing;
-
improving the work on amounts and values;
-
the removal of complex data types;
-
addresses and locations: where reuse of the Core Location Vocabulary and INSPIRE should be looked into.
-
evolving the models for eOrdering and eCatalogue.
The new Core Location Vocabulary will be discussed in the Core Vocabularies Webinar on 23 April at 10-12 see here. It would be good to discuss at this webinar whether it is really necessary to have a Location to access the address of an Agent.
Topic of discussion: ePO WG meetings week 16 (20 and 22 April 2021)
Members of the ePO WG will be participating in the Webinar https://digitallpublic.eu/.
The ePO meetings will take place on Tuesday 20 and on Thursday 22 even if we have to stop earlier than usual.
Topic of discussion: Definitions
The following concepts were discussed in the meeting:
-
epo:LocationCoordinate – this definition will be addressed at a later stage as the class ‘Location’ is still under discussion.
-
epo:MultipleStageProcedureTerm
Definition: Conditions and stipulations defining particularities of procedures carried out in several steps.
Additional Information: Generally this refers to procedures where selection is carried out to qualify tenderers who are then requested to submit the rest of their tender for evaluation ie Restricted procedure
-
epo:OpeningTerm
Definition: Conditions and stipulations defining particularities of the opening of the tenders.
Additional information: The opening of the tenders is the event when tenders are made accessible for evaluation, it is generally the same date and time for all tenders
-
epo:OrganisationGroup
Definition: Agreed collaboration of several organisations.
Additional information: This concept has been created to fulfill the need to represent a grouping of organisations that is not necessarily registered ie consortia.
-
epo:Prize
Definition: A reward given in a contest.
-
epo:RegulatoryFrameworkInformation.
Definition: Legal information that governs specific aspects of the procedure.
Additional information: The legal information can concern tax regimes in a given country for example
Topic of discussion: Event about SCORVoc standard
The Supply Chain Operation Reference (SCOR) is a cross-industry approach to lay the groundwork for more efficient and effective information exchange in supply networks. Within this framework an ontology SCORVoc has been created: https://github.com/vocol/scor uses https://schema.org/ that is good for defining products, as is the Good Relations Ontology.
The interconnection between the two ontologies were discussed and whether they could be mapped to one another. It was felt that although the scopes were different that commonalities could be found and it would be interesting to explore synergies that could be creating.
SCOR is about processes of Supply Chain management and supported by SCORVoc ontology, the eProcurement ontology is about (public) procurement data, however for common terms representing the same concept it could be worth ensuring a common definition to enable reuse, linking and interoperability.
SCOR will be presented at a workshop of the CEN TC 440 (European Committee for Standardization - Technical Committee on Electronic Public Procurement) on April 26, 2021 to better understand SCOR.
We carry on with definitions on Tuesday.
Working Group meeting 13/04/2021
Participants: Paloma Arillo Aranda (OP), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM) and Giampaolo Sellitto (ANAC).
Topic of discussion: Definitions
The following concepts were defined in the meeting:
-
epo:Amount
Definition: A number of monetary units specified using a given unit of currency
-
epo:UnitCodeListAgencyID - attribute renamed to epo:CurrencyCodeListAgencyID
Definition: Identifier of the agency that maintains the currency code list used
-
epo:UnitCodeListAgencyName - attribute renamed to CurrencyCodeListAgencyName
Definition: Name of the agency that maintains the currency code list used
-
epo:UnitCodeListID - attribute renamed to epo:CurrencyCodeListID and its data type changed to URI
Definition: Concept scheme URI used for the currency code list
-
epo:BuyerProfileNotice
Definition: Notice of the existence of a buyer profile
-
epo:Contractor
Definition: An economic operator that has signed a contract with a purchaser
-
epo:EvaluationBoard
Definition: Committee set up to evaluate the tenders submitted
Additional information: The committee may be a regular board or a jury.
-
epo:ExpressionOfInterest
Definition: Document presenting an economic operator’s request to be considered for procedures covering a specific domain
The definitions will be added to the ePO Glossary and the EAP file.
Working Group meeting 25/03/2021
Participants: Anna Frantzen, Cécile Guasch (ISA2 - DIGIT), Hilde Kjølset (dfø), Giorgia Lodi (ISTC-CNR), Thor Møller (dfø), Natalie Muric (OP)Juan Carlos Segura Fernández-Carnicero (everis), Giampaolo Sellitto (ANAC), Enric Staromiejski (everis), Sander Van-Dooren (ISA2 - DIGIT).
Topic of discussion: Presentation of the BDTI pilot
-
The BDTI team presented the wordk done on the BDTI pilot and how it uses the DCAT specification.
Topic of discussion: Definitions
The following concepts were defined in the meeting (see definitions in the EAP file and in the ePO glossary):
-
epo:Room
-
epo:StreetName
-
epo:TimezoneOffset
-
epo:Alias
-
epo:CurrencyID
-
epo:AmountValue
The definitions can be consulted in the Glossary. See https://github.com/OP-TED/ePO/blob/2042074d3a7e21b69f2892b645511ad083c13a05/v2.0.1/01-Glossary/ePO-Glossary.xlsx.
Working Group meeting 23/03/2021
Participants: Paloma Arillo(OP), Cécile Guasch (ISA2 - DIGIT), Veit Jahns (TC440), Giorgia Lodi (ISTC-CNR), Natalie Muric(OP), Héctor Rico (everis), Helder Santos(INCM), Giovani Paolo Sellito (ANAC), and Enric Staromiesjski Torregrosa(everis).
-
NM pointed out that there won’t be a meeting next 1st. The next meeting will be on the 13th.
-
NM indicated that thursday 25th presentation BDTI usage of DCAT.
-
NM informed the WG that v2.0.1 has been released. Showed the git and the release.
Topics of discussion: eCatalogue diagram
The WG proposed and agreed on separating eCatalogueReification and create a specific eCatalogue diagram to ease the maintenance.
Action Point: epo:Adress should have fullAddress as a string
The work done during the meeting was carried out taking as reference the diagrams from TC440:
-
epo-ecat:eCatalogue definition has been modified. Additional Information removed and used for the definition of epo-ecat:eCatalogueLine
-
The epo-ecat:eCatalogueLine was added. The class was defined based on TC 440 and the additional information from epo-ecat:Catalogue.
-
A new predicate was added from epo-ecat:eCatalogue epo:isComposedOf epo-ecat:eCatalogueLine. Cardinality 1..*
-
A new predicate was added from epo-ecat:eCatalogueLine epo:specifiesItem epo:Item. Cardinality 1
-
The class epo:Period was added in the diagram and linked to: epo:Contract and to epo-ecat:eCatalogue
-
The class epo:Price was added
-
The class epo:Location was added
-
Action point for the future: cardinalities should be harmonised – aligned with the 2.0.1 (all attributes from all classes)
-
The WG created an issue regarding Predicate harmonisation that concerns isComposedOf amongst other predicates in the Ontology. Issue 281 (https://github.com/eprocurementontology/eprocurementontology/issues/281).
Topic of discussion: eOrder diagram:
-
Change applied based on previous eCatalogue discussion: predicate from epo:Order epo:isComposedOf epo:OrderLine
-
Action Point: Separate the eOrdering and eOrdering Reification under its prefix as it is done in the case of eCatalogue (e.g. epo-eorder:)
Working Group meeting 16/03/2021
Participants:Ana Aido, Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjølset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Juan Carlos Segura Fernández-Carnicero (everis), and Enric Staromiejski (everis).
Topic of discussions: Review of the minutes from the 9th and 11th of March
No comments from the WG.
Topic of discussion: Definitions
The following concepts were defined in the meeting (see definitions in the EAP file and in the ePO glossary):
-
epo:Address
-
epo:Floor
-
epo:ID
-
epo:InhouseMail
-
epo:MarkAttention
-
epo:MarkCare
-
epo:PlotIdentification
-
epo:PostalZone
-
epo:Postbox
-
epo:Region
The definitions can be consulted in the Glossary. See https://github.com/OP-TED/ePO/blob/2042074d3a7e21b69f2892b645511ad083c13a05/v2.0.1/01-Glossary/ePO-Glossary.xlsx.
Topic of discussion: BDTI diagram
-
ReservedProcurement cardinality was changed to 0..*. The code-list from at-voc was also added.
-
Other code cardinalities needed in BDT where modified:
-
NUTS
-
Country code and cardinality 1
-
The CPV code was added and cardinality 1 for the main classification and for the the additional 0..*
-
The contract-nature code was added and cardinality 1 set for the contract nature
-
The permission code-list was also added associated to Lot with cardinality 0..1
-
The Lot ID cardinality was changed from 0..1 to 1
-
The cardinalities of the epo:Procedure attributes in the BDTI diagram were changed based on the ePO v2.0.1 ones
Working Group meeting 11/03/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjølset (dfø), Giorgia Lodi (ISTC-CNR), Helder Santos (INCM), Juan Carlos Segura Fernández-Carnicero (everis), Giampaolo Sellitto (ANAC), and Enric Staromiejski (everis).
Topic of discussion: Datatypes cardinalities
The WG discussed the cardinalities and attributes of some datatypes, e.g. epo:Quantity and UnitCode. The question of whether to remove or keep the UnitCode in epo:Quantity was posed, since the role of UnitCode could be replaced by epo:Item.
From this discussion the following modeling actions took place:
-
The UnitCode attribute from the class epo:Quantity has been removed. But the WG will reconsider whether to retrieve it back or not when analysing the modelling of Item in the context of eCatalogue and other aspects of the postaward;
-
The attributes epo:UnitCodeListAgencyId, epo:UnidCodeListAgencyName, epo:UnitCodeListID have been added in the classes epo:Measure and epo:Amount.
-
The EU Vocabularies codelist at-voc:measurement-unit has been added to the datatypes diagram associated to the class epo:Measure.
-
The EU Vocabularies codelist at-voc:currency has been added into the datatypes diagram associated to the Amount class.
The final version of the datatypes diagram is the following one:
Working Group meeting 09/03/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Natalie Muric (OP), Helder Santos (INCM), Juan Carlos Segura Fernández- Carnicero (everis), Giampaolo Sellitto (ANAC), Jalini Srisgantharajah (dfø), and Enric Staromiejski (everis).
Topic of discussion: Review of the minutes from the 2nd and 4th of March
-
Some corrections were done according to the WG comments.
Topic of discussion: Definitions
The following concepts were defined in the meeting (see definitions in the EAP file and in the ePO glossary):
-
epo:AccessTerm
-
epo:SomeProcurementDocumentRestrictedJustification
-
epo:ProcurementDocumentLandingPage
-
-
From the epo:Address class the following concepts were defined, mostly inspired by the definitions provided by UBL-2.3 :
-
epo:AdditionalStreetName
-
epo:BlockName
-
epo:BuildingName
-
epo:BuildingNumber
-
epo:CityName
-
epo:CitySubdivisionName
-
epo:CountrySubentity
-
epo:CountrySubentityCode
-
epo:District
-
The definitions cna be consulted in the Glossary. See https://github.com/OP-TED/ePO/blob/2042074d3a7e21b69f2892b645511ad083c13a05/v2.0.1/01-Glossary/ePO-Glossary.xlsx.
Working Group meeting 04/03/2021
Participants: Ana Aido, Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Veit Jahns (TC440), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM), Juan Carlos Segura Fernández-Carnicero (everis), and Enric Staromiejski (everis).
Topic of discussion: Competency Questions
-
The WG analysed and modified some of the competency questions created by everis for the validation of the converted notices produced in the context of TED RDF project.
Topic of discussion: eCatalogue
-
The WG discussed the CatalogueSituation and the fact if this refers to the Pre-award or Post-award catalogue situation. The TC440 convenor indicates that the current model is closer to the Post-award than to the Pre-award situation. This led to rename the reificantion class to indicate that it addressed the Postaward situation (the class is now 'PostawardCatalogueSituation').
-
The WG asked if for the different types of catalogue situations there will be different roles involved. The model is more or less the same, at least at the structual level. The difference would be in the roles and the objects (things involved) , since in the preaward the catalogue involves the Tenderer (and the lot) whilst in the post-awared it involves the seller and the contract.
-
After examining definitions of eCatalogue, namely the ones proposed by the TC440 convenor, Open PEPPOL and UBL, the WG came up with its own definition of 'eCatalogue':
"A document describing a set of items offered for purchase that can be processed in an electronic way.
Additional Information
The description may include a rich set of details, like prices, packaging, discounts, special promotions, etc."
-
The WG also defined the class 'Item' as:
"A singular product or service.
Additional Information
An item can be an atomic thing or a composition of things that together are seen as a unit, e.g. a tetrabrik of milk or an indivisible package of six tetrabriks."
The latest diagram on the eCatalogue is the following one:
This diagram will evolve with the results from further discussion on how to go on in the structuring of the eCatalogue (to be addressed in forthcoming sessions).
Working Group meeting 02/03/2021
Participants: Paloma Arillo Aranda (OP), Hilde Kjølset (dfø), Natalie Muric (OP), Fatima Sadiq (OP), Helder Santos (INCM), Juan Carlos Segura Fernández-Carnicero (everis), Giampaolo Sellitto (ANAC), Jalini Srisgantharajah (dfø), and Enric Staromiejski (everis).
Topic of discussion: Reification class
During the meeting the WG discussed the usage of the reification class. The following points were discussed:
-
The WG reviewed the ProcurementTermsNotificationSituation. This class was created specially to reflect which roles related to terms are involved at notification time.
-
Since terms are notably present in the diagrams Competition and Results, the WG asked whether this reification should not also appear in those diagrams and how.
-
Note that this reification could not be used in any other situations, but that this could be the subject of further analysis
-
In a first round of analysis on this, the WG thought of changing the name of the ProcurementTermsNotificationSituation by InformationProvisionSituation to reflect those roles that provide documents/information, (as this reification is used mainly to explain who is providing information during the the procurement). However, on second thought, the WG considered that the InformationProvisionSitutation is not needed at all, since for these 'kind of roles' like the tax information provider, employment information provider, etc. only the name and the contact point are actually required. This need is already covered by the generic reification "ProcurementSituation". Hence, the WG decided to remove the specialisation (InformationProvisionSituation) completely.
-
During the meeting, some questions were though to know which kind of info would be retrieve from the RDF triple store.
-
The WG worked started to consider how to include the Procurement Situation reification class in the Competition diagram, and test its effects and relations with the classes currently existing in this Diagram.
Working Group meeting 25/02/2021
Participants: Paloma Arillo Aranda (OP), Eugeniu Costezki, Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM), Juan Carlos Segura Fernández-Carnicero (everis), and Giampaolo Sellitto (ANAC).
Topic of discussion: OWL restrictions of the ontology
The WG discussed about some problems found after running the transformation script (developed under the OP model2owl project (model2owl) from uml to owl restrictions. Some of the points of discussion were:
-
Problems related to the entity owl nothing and how and when it should be fixed. The WG said that it is not a priority for the time being;
-
Some inconsistencies have been foun after running a reasoner, but it is needed from where they come in order to fix them. The WG said that the BDTI project may be use for the analysis of this inconsistencies since it is scoped for some few classes of ePO. With this exercise, the WG indicated it will allow to discover wether the modifications need to be done in the uml or in the script.
Topic of discussion: Cardinalities
The WG worked on the cardinalities of the attributes of the eProcurement Ontology v2.0.1.
The corresponding modification in the model can be consulted in this Cardinalities.
Working Group meeting 23/02/2021
Participants: Ana Aido, Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Fatima Sadiq (OP), Helder Santos (INCM), Juan Carlos Segura Fernández-Carnicero (everis), and Giampaolo Sellitto (ANAC).
Topic of discussion: Cardinalities
The WG worked on the cardinalities of the attributes of the eProcurement Ontology v2.0.1.
The corresponding modification in the model can be consulted in this Cardinalities.
Working Group meeting 18/02/2021
Participants: Ana Aido, Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Veit Jahns (TC440), Hilde Kjølset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Fatima Sadiq (OP), Helder Santos (INCM), Juan Carlos Segura (everis), Giampaolo Sellitto (ANAC), Jalini Srisgantharajah (dfø), and Enric Staromiejski (everis).
Topic of discussion: eCatalogue discussion TC440
The WG worked on the definitions of the following classes used in eCatalogue:
-
Buyer:
A role of an agent that awards a contract and/or purchases items.
Additional information:
In pre-award, the buyer generally awards the contract, however future purchasers may be foreseen. In post-award the buyer generally refers to the purchaser of items.
-
CatalogueReceiver:
A role of an agent processing a catalogue.
Additional Information:
The catalogue receiver may not only receive it but also validate it, process it, etc. The catalogue receiver role is usually played by the agent that acts as a buyer, or by another agent that acts on behalf of the buyer.
-
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.
-
Seller:
A role of an agent legally responsible for providing goods and services bought by a Buyer.
Other points of discussion:
-
The WG discussed whether the CatalogueReceiver and CatalogueProvider should be a code or individual classes. The final conclusion was to have both as classes.
-
The WG decided to remove the properties hasCatalogueProvider and Receiver since we have the CatalogueSituation which inherits from ProcurementSituation and it is related to Role. The CatalogueReceiver and the CatalogueProviders are roles.
-
The WG discussed whether the seller is a subclass of Winner/Tenderer/EO.
Working Group meeting 16/02/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Fatima Sadiq (OP), Helder Santos (INCM), Juan Carlos Segura (everis), and Giampaolo Sellitto (ANAC).
Topic of discussion: Cardinalities
The WG worked on the cardinalities of the attributes of the eProcurement Ontology v2.0.1.
The corresponding modification in the model can be consulted in this Cardinalities.
Working Group meeting 11/02/2021
Participants 11th February: Ana Aido, Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjølset (dfø), Giorgia Lodi (ISTC-CNR), Thor Møller (dfø), Natalie Muric (OP), Helder Santos (INCM), Juan Carlos Segura Fernández-Carnicero (everis), Giampaolo Sellitto (ANAC), and Jalini Srisgantharajah (dfø).
Topic of discussion: Cardinalities
The WG worked on the cardinalities of the attributes of the eProcurement Ontology v2.0.1.
The corresponding modification in the model can be consulted in this Cardinalities.
Working Group meeting 09/02/2021
Participants 9th February: Ana Aido, Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjølset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Hector Rico (everis), Helder Santos (INCM), Giampaolo Sellitto (ANAC), and Jalini Srisgantharajah (dfø).
Topic of discussion: Cardinalities
The WG worked on the cardinalities of the attributes of the eProcurement Ontology v2.0.1.
The corresponding modification in the model can be consulted in this Cardinalities.
Working Group meeting 04/02/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjølset (dfø), Thor Møller (dfø), Natalie Muric (OP), Hector Rico (everis), Helder Santos (INCM), Juan Carlos Segura (everis), and Giampaolo Sellitto (ANAC).
Topic of discussion: Cardinalities
The WG worked on the cardinalities of the attributes of the eProcurement Ontology v2.0.1.
The corresponding modification in the model can be consulted in this Cardinalities.
Working Group meeting 04/02/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Helder Santos (INCM), Juan Carlos Segura (everis), Giampaolo Sellitto (ANAC), and Enric Staromiejski (everis).
Topic of discussion: Revision of the minutes from the 26th and 28th January
-
Some small corrections were done during the meeting
Topic of discussion: Cardinalities
The WG worked on the cardinalities of the attributes of the eProcurement Ontology v2.0.1.
The corresponding modification in the model can be consulted in this Cardinalities.
Working Group meeting 28/01/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Veit Jahns (TC440), Giorgia Lodi (ISTC-CNR), Thor Møller (dfø), Natalie Muric (OP), Hector Rico (everis), Helder Santos (INCM), Giampaolo Sellitto (ANAC), and Enric Staromiejski (everis).
Topic of discussion: eCatalogue discussion TC440
The meeting was focused on the definition of classes within eCatalogueReification Diagram (CatalogueReceiver and CatalogueProvider). The discussion went through the possibility of exploring if CatalogueReceiver and CatalogueProvider are better handled as roles (defining them as classes) or as activities defined within the organisation-subrole code list. Both possibilities were depicted:
OPTION 1
Inclusion of the Catalogue Provider and Catalogue Receiver as subclasses of Role (in which case, the code-list 'organisation-subrole' does not contain codes related to these two roles):
Both roles were defined as follows:
-
epo-ecat:CatalogueReceiver: A role of an agent processing a catalogue. Additional information: The catalogue receiver role is usually played by the agent that acts as a buyer, or by another agent that acts on behalf of the buyer.
-
epo-ecat: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.
OPTION 2
Removal of Catalogue Provider and Catalogue Receiver classes and inclusion of two new codes in the codelist 'organisation-subrole': 'cat-prov' and 'cat-receiv':
The WG considers that this latter case is more elegant and more flexible, since it allows any Agent to perform activities of catalogue provision and reception (e.g., Buyers and Service Providers). It also allows for further addition of other activities that can be performed by other Agents related to catalogues such as catalogue validation, catalogue dissemination, etc.
-
Action point: move the definitions of Catalogue Provider and Catalogue Receiver from inside the classes into the codelist 'organisation-subroles'.
WRAP-UP
Instead of having the roles CatalogueProvider and the CatalogueReceiver, the WG decided:
-
To create a new class named ServiceProvider and where the ProcurementServiceProvider inherits from. So now the model indicates that ServiceProvider is a Role, and the ProcurementServiceProvider is a Service Provider.
-
The WG also added to new codes - CatalogueReceiver and CatalogueProvider - into the codelist 'organisation-subroles'.
These two decisions allow solving that a CatalogueReceiver could be a ServiceProvider, but also a Buyer.
Note that the CatalogueProvider and the CatalogueReceiver have been hidden in the eCatalogue diagram, but not in the UML model. This is still under discussion, but if the discussed proposal is accepted, the definitions will be moved into the codelist and the classes will be removed from the model.
Working Group meeting 26/01/2021
Participants: Paloma Arillo Aranda (OP), Cécile Guasch (ISA2 - DIGIT), Hilde Kjølset (dfø), Giorgia Lodi (ISTC-CNR), Thor Møller (dfø), Natalie Muric (OP), Helder Santos (INCM), Juan Carlos Segura (everis), Giampaolo Sellitto (Anticorruzione), and Enric Staromiejski (everis).
Topic of discussion: Revision of the minutes from the 19th and 21st of January
-
New participants were added to the 19th January minutes;
-
The rationale of why we talk about abstract classes was added to the 19th’s minutes
-
Related to the previous point, the stereotype of all abstract classes in the UML were removed, since the WG considered that in purity the concept of 'abstract' cannot be applied to ontologies, and in certain situations it could be necessary to instantiate one of these base class that until now were considered kind of 'abstract', e.g. 'Notice', amongst other.
-
Typo in the name of a participant corrected;
-
Some other typos in the minutes of the 21st January also corrected;
-
Issue https://github.com/eprocurementontology/eprocurementontology/issues/267 was updated;
-
Decision of adding the organisation to which each member of the WG belongs to next to her/his name, in the list of attendants.
Topic of discussion: Roles and Subroles reifications
-
Proposed that each specific situation (i.e. reification) should have its own codelist. Identified two new situations where this could make sense: eNotification and ESPD-related situations. For the first one, proposed the inclusion of a new diagram representing the situation reified as 'ProcurementTermsNotificationSituation'.
-
The WG analysed in detail this proposal and challenges the idea that the activities that everis considers exclusively of the Notification could not be applied to other phases and different roles.
Finally, the WG concludes that a better solution would consist in having a single code list with all these activities associated to the generic reification, the Procurement Situation, instead of to particular reifications (apply these changes to the UML mode. This action point was applied on the 28th of January).
.png){kind=link}
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:
.png){kind=link}
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
Working Group meeting 19/01/2021
Participants: Paloma Arillo Aranda, Giorgia Lodi, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Enric Staromiejski.
Topic of discussion: Address class
-
The WG discussed the meaning of the attribute "epo:Department" in the epo:Address class;
Topic of discussion: Review of the minutes from the 12th and 17th of January
-
To add the diagram of eCatalogue in the minutes from the 12th of January;
-
Some modifications were done during the meeting;
-
To add Giampaolo into the participants from the 12th January.
Topic of discussion: Roles and Subroles reifications
-
Created a presentation Agent Role Conclusions explaining the conclusion on where other reification classes are needed for the rest of roles and subroles activities;
-
Created a new diagram named Procurement Terms Notification where they defined a new ProcurementTermsNotificationSituation and the roles involved in this situation;
-
The WG discussed this new diagram created to understand the different classes dropped on it:
-
The WG also discussed about the BuyerProfile and if it should be linked to the Agent class. The answer is yes, but in v2.0.1 and v.2.02 it is modelled differently due to no reifications are used in previous versions.
Topic of discussion: Abstract classes
-
Discussion about the meaning of abstract classes. In UML an abstract class is never implemented.
For instance, it is not possible to implement an individual of the class notice since it is a document itself, same happens with technique, but you can implement the types of notices "Contract Notice" "Contract Award Notices", etc.
Working Group meeting 14/01/2021
Participant: Paul Donohoe, Anna Frantzen, Cécile Guasch, Gunnar J.Johnsen, Hilde Kjølsetm, Girogia Lodi, Jan Maerøe, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski.
Topic of discussion: DCAT-ePO Ontology
-
The Norwegian conveners attended the meeting to present the W3C DCAT ontology and its possible relationship and use in ePO;
-
The presentation introduced the explanation of the DCAT;
-
The Norwegian conveners introduced their Data Catalogue, the project were they are involved. The project has re-focused (broaden the scope) from records management to "information management";
-
The Norwegian conveners indicated their intentions to implement the ePO Ontology in their project for the information management;
-
The Norwegian conveners presented an overview and some details of the Norwegian data catalogue. It is composed of 5 parts: dataset, API, concept, information model and public service (BETA);
-
The following specifications were introduced and explained during the meeting: DCAT, BRegDCAT-AP, and DCAT-AP-NO v2.0 which is compliant to BRegDCAT;
-
An explanation of the concepts of catalogue, dataset, dataset description and data model was done using the IKEA catalogue as an example. According to this explanation, Data Catalogue and Dataset could be represented using DCAT-AP-NO while dataset and datamodel could be represented using the ePO Ontology.
-
The discussion entered into more technical details where the WG discussed on how to connect the ePO and DCAT, for example reusing the dcat:Resource class.
-
IFLA FRBR/LRM (https://www.ifla.org/publications/node/11412) was also discussed by the WG since W3C DCAT (https://www.w3.org/TR/vocab-dcat-2/) took some inspiration from it.
-
The WG also discussed, together with the Norwegian conveners, about keywords and recommendation and how they could be used. For example, a recommendation from the WG was to take the classes from the ePO and to enrich/introduce the ePO terms in the EUROVOC thesaurus (example of recommendation: say "Tender" to refer to the offer submitted by the Economic Operator, never use "Tender" to mean "Procurement" or "Procedure", and other similar ones).
-
The presentation used during the meeting and provided by the Norwegian conveners can be consulted in Presentation-ePO-WG
Working Group meeting 12/01/2021
Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Veit Jahns, Hilde Kjølset, Thor Moller, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski.
Topic of discussion: eCatalogue discussion
-
TC440 eCatalogue convenor attends the meeting to contribute to the discussion of eCatalogue.
-
TC440 eCatalogue convenor explained briefly the eCatalogue process.
-
TC 440 eCatalogue convenor showed the terms and definitions of the different roles participating in the eCatalogue process. For their definitions, they reused/based the definitions defined by the ePO Ontology. They also based their definitions from Peppol (e.g. customer), UBL (e.g. seller).
-
TC 440 eCatalogue convenor also explained the analysis that they performed for the correspondence of the classes used in the ePO ontology. For example the class Agent they saw the correspondence to the UBL class "Party".
-
TC 440 eCatalogue convenor explained that they created different UML diagrams where they reused classes from the ePO Ontology, but also created other classes to model the Catalogue Provider, Catalogue Receiver and Seller.
-
TC 440 eCatalogue convenor and the WG discussed the differentiation that Peppol did between Business Role and Business Partner (however TC 440 is considering the deprecation of this "Business Partner" term).
-
The WG worked in a testing eCatalogue diagram. For that purpose, a new module (ePO Conceptual Model) in the set of ePO diagrams was created named "eCatalogue" (see the eAP file), also here the picture:
-
The WG started working on the role of CatalogueProvider to understand how to model it in the ePO Ontology.
-
A reification CatalogueSituation was created to link the Agent to the roles.
Working Group meeting 07/01/2021
Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Héctor Rico, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajah.
Topic of discussion: Review of the minutes from the 15th and 17th of December
-
Some small modifications were added to the minutes.
Topic of discussion: Issues in GitHub
The WG discussed the following issues:
-
Issue [274](https://github.com/eprocurementontology/eprocurementontology/issues/274)
-
Issue [271](https://github.com/eprocurementontology/eprocurementontology/issues/271):
-
The WG agreed on the following: 1. procedure isSummarisedBy 1 and only 1 CAN only is wrong: The WG decided to change the cardinality 0..*; 2. hasOptionsPermission cardinality 1 seems irrelevant: The WG decided to change the cardinalities to 0..1.
-
Also, the WG agreed that it should be applied in the document that would be provided by the OP, which includes attribute cardinalities.
-
The WG agreed that it is for the Application Profiles to decide which cardinalities should be. The ontology has to be as less restrictive as possible.
-
-
Issue [271](https://github.com/eprocurementontology/eprocurementontology/issues/271)
-
Issue [70](https://github.com/meaningfy-ws/model2owl/issues/70#issuecomment-748187185) from the model2owl repository
Topic of discussion: OWL restriction files
The WG indicated that the errors detected were fixed and no errors occurred with the new release.
Topic of discussion: to check the eOrder diagram
The WG checked the status of the eOrder diagram. The discussion point were the followings:
-
The WG commented that object properties from epo:Lot to epo:Value are misleading.
-
The WG suggested to check how the attributes relate to the predicates. In theory, all the predicates would fit with only one attribute.
-
An issue will be opened in GitHub to discuss further in-depth.
Topic of discussion: Usage of modules in the ePO ontology
-
Currently, all the diagrams are translated to a general owl file. In the case of BDTI, they produced a little piece with the data for its specific context.
-
The WG discussed to have small ontologies for each of the procurement phases. For example, to have a module for the eOrder with its classes and properties. The common classes could be in another package.
-
The WG indicated that using modules would allow reducing the complexity of the Ontology.
-
Everis raised the issue of how Enterprise Architect manages the reuse of classes from other packages. It creates a copy of the class, and any change created for classes reused is only applied to the specific UML diagram where it is used.
Any comments on the documentation?