Closed schivmeister closed 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
:
Issue
An
epo:Organization
currently has one association tocpov:ContactPoint
via theepo: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.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:
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:
epo:hasPrimaryContactPoint
shall be supplemented with a siblingepo:hasSecondaryContactPoint
, with cardinality restricted to 1 in the former relationship.epo:hasPrimaryContactPoint
shall be renamed toepo: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 byepo:hasContactName
).