Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Organisation Roles and Subroles #240

Closed
eprocurementontology opened this issue Mar 27, 2020 · 6 comments
Closed

Organisation Roles and Subroles #240

eprocurementontology opened this issue Mar 27, 2020 · 6 comments
Assignees
Labels
module: ePO core ePO core type: feature request something requested to be implemented in a future release
Milestone

Comments

@eprocurementontology
Copy link
Collaborator

eprocurementontology commented Mar 27, 2020

The approach of the meetings on the 24th and 26th of March were focused on the analysis of the code lists Organisation Role (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/organisation-role) and Organisation subrole (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/organisation-subrole) from EU Vocabularies.

The purpose of this analysis was to check whether the codes contained in both lists are represented in ePO through either classes or attributes.

The WG started the analysis by the Organisation Roles code list, and the following concepts were discussed:
- Buyer
- Beneficial Owner (BO)
- Central purchasing body acquiring supplies and/or services intended for other buyers
- Central purchasing body awarding public contracts or concluding framework agreements for works, supplies or services intended for other buyers
- Winner
- Subcontractor

From the discussion of this codes the following modelling actions took place:

• BO should not be from role to role as we had. We deleted the link to Buyer and we decided that the BO is a property between Person class and Business
• The property "delegatesAncillaryActivitiesOn" between Buyer and ProcurementServiceProvider were removed

The conclusion of the analysis can be consulted in the sheet "Organisation-roles" of the mappings.

@eprocurementontology
Copy link
Collaborator Author

Issue related to #233

@eprocurementontology
Copy link
Collaborator Author

eprocurementontology commented Apr 3, 2020

The approach of the meeting on the 31st March and 02nd April was focused on the continuation of the Organization Roles analysis. This analysis aims to check whether the eProcurement Ontology covers all the codes listed in the Organization code list (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/organisation-role).

During the meeting on the 31st of March, the main points discussed were about the Subcontractor concept, and they are the following ones:

  • There was a general doubt about how to measure the different Sizes of a Subcontractor. In this discussion, some proposals were discussed, e.g. creation of a property between Person and Business, but the WG was not very confident with the solutions. From this discussion came up with an action point for everis to think in a solution.
  • Some relationships between AwardDecision, Subcontract, Subcontractor and Tender were analysed. In the Result diagram, the AwardDecision class is linked to the Subcontract 4 times. Some of those properties are redundant
  • Discussion about the impact of the addition of roles in the ontology. Now it is needed to discern the Organization and its types.

During the meeting on the 02nd of April, the main points discussed were the following ones:

• The WG worked in the ePO definition for the Subcontractor concept. The definition agreed with the WG was as follow:
• An individual or a business that has an agreement to perform part or all of the obligations of another contractor's contract.

Additional information

For some procedures, the subcontractor signs as well the contract between the buyer and the contractor.
• The WG discussed the relationships between Business, Registered Organisation, and Person. The WG said that Business inherits from Register Organisation and it is not a Person. The property isSelfEmployed Person and Business was removed as a conclusion of the discussion. It was decided there did not need to be a predicate SelfEmployed person as the self employed person can be reached through the property epo:hasBeneficialOwner
• Everis proposed the solution on how to measure the size of a Subcontractor. It was mainly based on the creation of an attribute “Agent Type”, which would be a code, in the class role that allows identifying if it is a natural person, business, etc. The WG said that this can be done with inferences and using reasoners. According to this discussion, the eForms mappings were modified according to the new relationships on how to know the size of the winner, tenderer, and subcontractor. The BT-165 was modified. See mappings.
IMPORTANT NOTE: If the economic operator or subcontractor are natural persons, these natural persons can be reached through the property epo:hasBeneficialOwner, which connects the epo:Business class to the epo:Person class.
• The WG discussed the mediation Body. The WG said that with the addition of the Role concept. The Organisation needs to be split into its different types. By the moment, ePO created new roles that were named “Mediator”, “Reviewer” which were linked to the Review Terms class.

@eprocurementontology
Copy link
Collaborator Author

The approach of the meeting on the 7th April was focused on the continuation of the Organisation Roles and Subroles discussion.

The WG discussed on the properties that links ProcedureTerms to Organizations: +epo:hasWorkingConditionsInformation, +epo:hasEnvironmentalProtectionInformation, +epo:hasEmploymentProtectionInformation, +epo:providesTaxRegulatoryInformation, +epo:hasAdditionalInformationProvidedBy. According to the WG these properties inform the Economic Operator about where he can find information about one of these specific topics.

The WG discussed these properties should point to the ContactPoint and not to the Organisation. The other possibility discussed was to have one property that group all these properties. Moreover, ContactPoint would have a property/attribute to categorise the ContactPoint.

As a decision of the discussion, the WG decided to create a class named “ReferenceFramework” which is linked to the Procedure and the Organisation class. Moreover, the WG said that the Contact Point and the Address class are also needed because we need to know the Postal address for example. Some of the attributes added to this new class ReferenceFramework were: Type (Code), Title (Text), Description (Text). Also, a new code list named “reference-information-type” was created.

The result of this discussion can be consulted in the Procurement Terms diagram.

@eprocurementontology
Copy link
Collaborator Author

eprocurementontology commented Apr 20, 2020

The approach of the meetings on the 14th, 15th, 16th and 17th of April was focused on the continuation of the Organisation Roles and Subroles discussion.

For this discussion, the WG continued working on the ePO mapping to the euvocabularies code list. The mapping can be consulted in the “Organization-roles” sheet of the mapping file. In that sheet, the corresponding mapping to each code can be consulted.

Moreover, and as a summary of the meetings, the following discussions and modelling actions took place:

  1. The WG discussed how to map in ePO the codes “info-tax”, “info-envir”, “info-emp”. These three codes are information provided by an Organization. As a decision of the discussion, the WG decided to add them to the code list “reference-information-type”. Finally, this code was replaced by the “function-taxonomy”, see bullet “4”.

  2. There was another discussion on how to map the TED eSender. According to the WG, it is a role and it is who submit the notice. To fulfill the mapping, the WG decided to create a property from Role to Document. The following explanation was added in the property “isSubmittedBy”:

image
Property “epo:isSubmittedBy”:
The transmitter of documents.

Additional Information:
An example of transmitters are TeD eSenders, which are usually either the Buyer or a Service Provider acting on behalf of the Buyer, qualified by the Publication Office of the European Union.

  1. As an Action Point raised on the meeting of the 14th of April and assigned to everis “mapping of buyer and tenderer roles in eForms” they explained how is the mapping. To see the mappings see BT-08 (mappings URL). Moreover, Everis asked the WG and after its mapping, why there are not tenderers in the “Contract Modification” phase. It was thought that because the Contract is not referred to the Tenderer, it is referred to the Winner. Moreover, this phase is just related to the Contract and not to the Winning tender.

  2. Once the Organisation roles were mapped, the WG started with the mappings of the Organisation Subroles. The WG analysed the different subroles listed in the euvocabularies code list “Organisation Subroles” (Source: https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/organisation-subrole). The WG proposed that instead to have different classes for each Subrole, the model should have a class “Role” that points to a code list where the different subroles are listed, in other words, Subroles are another role of a role. The WG analysed whether all the subroles from euvocabularies applies to the different roles (e.g. Economic Operator, Buyer, etc.). For this discussion, a reflection was done to analyse when the different subroles are applied in the different roles. After analysing these subroles the WG said that these are not subroles, they are functions of an Organisation. As a conclusion of this discussion, the following actions were agreed by the WG:

  • The WG proposed to create a new class named Function which is linked to the Procedure and Agent, and which has a “function-taxonomy” code list. This was proposed since the functions are related to the procedure, and the Agent is who carries out the functions. This code list replaces the “reference-information-type” mentioned in bullet 1 and the codes inside were moved to the “function-taxonomy”. Also, the class “ReferenceFramework” is not needed anymore and was removed. This class was created to add the “reference-information-type” code. As an action point, everis will add the codes inside the “function-taxonomy” code. To decide which subroles are part of this “function-taxonomy” the following reflection was created. In this document, the WG makes the reflection of how to classify the different subroles, if by functions in the context of one specific procedure and or functions transcending a specific procedure.

  • The EO role type code list was added inside the "funtion-taxonomy". Moreover, the WG mentioned that rules for controlling which functions can be executed by an agent playing a specific role need to be created (SHACL shapes).

  • During the discussion of the Organisation subroles and how to map them in ePO, the WG modified the definition of the Buyer class since the WG thoughts that all the subroles are only part of the buyer: “ePO: Organisation that awards the contract. Additional information: Examples of a buyer can be Contracting authority, contracting entity, a defence contractor, an international organisation, or an organisation awarding a contract subsidized by a contracting authority.”.

@eprocurementontology
Copy link
Collaborator Author

eprocurementontology commented Apr 24, 2020

During the meeting on the 21st of April, the WG continue working on the Organisation Roles and Subroles in order to finalise the mapping.

Everis, as an action point assigned to them, explained that two new properties were created. One to say that Agent creates (Creator) a Document and another one to say that Role submits a Document (eSender). The WG, after discussing both properties, said that the property for the sender should link the Agent and Document and not the role and document. It was decided that the creator was not needed as this is information is transactional and held by the internal systems.

The WG also worked on the definition that everis created for the distinction between the Role and Function concepts. The WG reviewed a worked in a more clear definition for the distinction of both concepts. The final result of the work was as follows:

  • Role: A part played by an agent in a particular business process.

Additional information
In ePO, the 'business processes' related to procurement can be 'purchasing', 'tendering', 'evaluating', 'awarding', 'ordering', 'invoicing', etc.

The concept of 'role' is different from the concept of 'function'. However, functions can be carried out by procurement-related roles and other domain-related agents. Please refer to the class 'Function' to see the difference.

  • Function: The specific task of an agent in a particular business process.

Additional Information
In the context of public procurement, ‘functions’ are tasks related to procurement in general or more specifically to the management or execution of concrete procurement procedures.
Examples of functions in procurement can be organisations responsible for providing information on taxes in a specific region, organisation providing information concerning the general regulatory framework for employment protection and working conditions in a specific region, organisations providing information concerning the general regulatory framework for environmental protection, etc.

@andreea-pasare andreea-pasare added type: feature request something requested to be implemented in a future release module: ePO core ePO core labels Oct 11, 2022
@andreea-pasare andreea-pasare added this to the 2022 Q4 milestone Oct 11, 2022
@andreea-pasare andreea-pasare self-assigned this Dec 11, 2022
@andreea-pasare
Copy link
Collaborator

In the latest of ePO release, 3.0.1, all roles/subroles contained within the code lists Organisation Role and [Organisation subrole] (https://op.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/organisation-subrole) from EU Vocabularies are represented as concepts/properties in the ontology.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module: ePO core ePO core type: feature request something requested to be implemented in a future release
Projects
None yet
Development

No branches or pull requests

2 participants