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.)