OP-TED / ePO

The eProcurement Ontology provides the formal, semantic foundation for the creation and reuse of linked open data in the domain of public procurement in the EU.
European Union Public License 1.2
58 stars 18 forks source link

Problem with semantics of `epo:hasPrimaryContactPoint` #531

Closed schivmeister closed 7 months ago

schivmeister commented 8 months ago

Issue

An epo:Organization currently has one association to cpov:ContactPoint via the epo:hasPrimaryContactPoint relationship (object property), with unrestricted cardinality. This means there can be multiple such associations. This, however, is incompatible both with its name and practical usage requirements.

image

By definition, there can only ever be one "primary" instance of a thing. In this context, an organization can have multiple contact points, but only one of them can be the default, main or primary. A data example can be seen in the eForms specification, where the following structure is typical:

<Organization>
    <Company>
        <Contact>
    <TouchPoint1>
        <Contact>
    <TouchPoint2>
       <Contact>
    ...

In this example, the company that represents the organization has a single, default contact point, but the organization has multiple contact points that can be reached.

Recommendation

Based on the semantics of a relationship between an organization and its contact points, one of the following solutions can be considered for the ePO model:

  1. The relationship epo:hasPrimaryContactPoint shall be supplemented with a sibling epo:hasSecondaryContactPoint, with cardinality restricted to 1 in the former relationship.
  2. The relationship epo:hasPrimaryContactPoint shall be renamed to epo:hasContactPoint with cardinality intact (unrestricted).

The second solution leaves the issue of identifying a primary contact point open, but is the least invasive approach.

Additionally, the cpov:ContactPoint class should facilitate providing both an internal identifier and a name, as contact points are expected to also be cross-referenced, and they should be user-identifiable by name (that is different from the contact person's name represented by epo:hasContactName).

andreea-pasare commented 7 months ago

Thank you for your comment. We agree that the cardinality for epo:hasPrimaryContactPoint should be 0..1. The change should be implemented in ePO v4.1.0.

The epo:hasPrimaryContactPoint predicate represents the contact point of the Legal Entity. The other contact points used in eForms should be represented via the epo:AgentInRole epo:hasContactPointInRole epo:ContactPoint:

image