Working Group meeting 17/01/2023

Date: 17/01/2023
Participants: Jana Ahmad, Natalie Muric, Pietro Palermo, Thomas Pettersson, Giampaolo Sellito, Emidio Stani, Ivan Willer
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi

Agenda

Discussion

Core Vocabularies observations

  • epo:hasOrganisationUnit should be an attribute on the OrganisationalUnit concept from org ontology.

  • If we follow org ontology we need to add a new class where to put only an attribute for the name.

vwghhMQmNKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCP8PVFhkCPTdwgcAAAAASUVORK5CYII=

  • The reason why we conflated these two is the case when only a particular unit is the Buyer.

  • Recommendation to not separate these two concepts (Organisation and Organisation Unit) and only rename the attribute to epo:hasOrganisationUnitName

    • Why? Because the Agent that takes a role (e.g. Buyer) can be a Unit or an organisation, but we decided to set the description at the “organisation level”.

  • epo:hasLegalFormType - from SEMIC perspective we asked the OP to create the Core Vocabulary for the classification of the legal forms from GLEIF:

    • This will be published in the future.

    • Switch to using a code list for legal type classifications.

cv:LegalEntity versus epo:Business

Definition for cv:LegalEntity:
A self-empoyed person, company, or organization that has legal rights and obligations.

QvHjpz8SADDJIpUPQKdeSLbb+PGoc8SP8xYAgOktUvnwPE++rqTnRQEpahvitFdLCRdfAGB6i1Q+AADADwDlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFZvUj7OnTsny0dw8j1ydwAAADBBt9sVbcGyLNklgtgsRmRi+UgkEq7r2rYtRnlEfPOAyQ8AADBZvGpcuHBBFAnf9x3HiT1kcvmQbUUSnaPZbMa+CAAAMJ7neUHYQkSXkJddRkwsH5cvX5YbrVYrOmiaZrQNAAAwQjSPXq8n+4ecyHBdd9qZj0Qikc1mo135LIIPAAAwQdQcjo6OLl68KPpDtH4jMrF8iLaSSqXOKX4EAAAwwfnz52VhuHTpUiKRqNVqQWwK47hjxHfiHMfpdDrxI9ElHAAAgLGiX5UVDMN4VSNiJpaP4GS1h23b8hdmgvCyzfceAQAAoBAVIuoM9Xr9+188tXwAAAC8dZQPAACgFeUDAABoRfkAAABaUT4AAIBW3wH6TmFMOlTauAAAAABJRU5ErkJggg==

Definition for epo:Business:
A private law company registered in a national registry.

VKarBkAAAAAElFTkSuQmCC

  • epo:Business should be a subclass of cv:LegalEntity in Core Business Vocabulary.

  • In order to align with Core Voc, it means we need to add cv:LegalEntity and org:FormalOrganization between org:Organization and epo:Business.

  • But a Business has to be a FormalOrganization.

  • In CPOV, a PublicOrganisation is not org:FormalOrganisation, but it is directly under org:Organisation.

dgAAAABJRU5ErkJggg==

  • Depending on the country, a cpov:PublicOrganisation may have a legal entity, so it may be a formal organisation.

  • Hierarchy

    • Org:Organisation

      • cv:PublicOrganisation

      • org:FormalOrganisation

        • legal:LegalEntity (self-employed person, company, or organisation with certain rights)

          • Action: Replace epo:Business by cv:LegalEntity

      • epo:OrganisationGroup

  • We need to have a discussion on whether the legal form type is at the legal entity level or at the organisation level.

    • What if we have the case when a tenderer is a public organisation?

  • This relationship is used at the Organisation level because foaf:Agent includes also a person or a system.

  • Decided to remove the relation from epo:OfferingParty to epo:Business as depicted in the diagram above.

CgAAAABJRU5ErkJggg==
Concession contract

  • In CPSV-AP the cv:ServiceConcessionContract was added as a subclass of epo:ConcessionContract:

WCeQt0dpNt2GHT8UIso+CrVjketBr100+lEAjiIYzCBmEUDr7vvwlNieF+bgseAAAAAElFTkSuQmCC

  • For CPSV-AP we need a relationship between epo:Contract to epo:ContractSpecificTerm (epo:hasContractTerm) in order to be able to get to the at-voc:contract-nature:

D8MFzktkMfMkQAAAABJRU5ErkJggg==

  • Contract includes specific terms

  • Contract cannot have epo:ContractSpecificterms

  • Contract “includes Lot”, is not right, needs more discussion on this.

Order

  • Look into the syntax binding, where we will see all the “elements” that we need to see in the order.

  • For example, Contract ID, is missing, or what is in the Buyer? It is hard to see all the elements from the ePOcore or eCatalogue, or eFulfillment.

  • Request: can we have a plain table with all properties for a class (including inherited attributes).

    • Technical Question:

      • Given a UML model, can we generate an “application profile” in a tabular representation (see SKOS-AP-EU ), for each class considering also inheritance.

      • Can we also automatically generate a “Path” to get that property?

  • It was found that a epo:ProcurementElement does not have an identifier, so the relation between epo:ProcurementObject and epo:Identifier was moved from epo:ProcurementElement to epo:Identifier as depicted in the diagram below:

6v8DttBVGvFk67oAAAAASUVORK5CYII=

  • Proposal to work on a table that contains all the properties for all the concepts in the Order phase on the 26th Jan.