Closed ocorcho closed 2 years ago
I recognise the concern, but changing the range of involvedActor wouldn't solve this I think. Instead having separate subproperties of involvedActor for the various roles would unambiguously relate a consignment to the various actors playing the various roles. So, involvedConsignor would relate the specific LegalPerson involved as consignor to the consignment. The ActorRoles may then be inferred from being the object of an involvedConsignor relation.
Thanks, this is indeed a valid modelling possibility for this type of problem. Will these properties be created in the BusinessService ontology (what seems to make more sense as there may be a common set of roles across Federated) or should we create them in the ontologies that are importing these ones?
Thanks, we will add these to the BusinessService ontology.
Perfect, thanks. Leaving this open until they are included in the ontology formalisation, so as to keep track of this issue. We will already use them as if they existed.
When checking the definition of the class Consignment, I can see that the restriction on the property involvedActor has as value businessService:LegalPerson. Shouldn't it be businessService:ActorRoles? That is, if it focuses on actors such as legal persons, we will lose the possibility of describing properly the ActorRole that this actor has for this specific Consignment. This would be especially the case for those cases where the same legal person takes different roles in the same or different Business Transactions. If we connect with LegalPerson, we lose the possibility of expressing this properly.