Source: Object Management Group ( Mike Bennett)
Misclassification of Role and PartyInRole in Owbnership and Control ontologies. Also happens in FIBO-BE (separate issue to cover that).
Existing pattern uses a cascading sequence of restrictions and logical unions, the end result of which is to cause types of PartyInRole (in OwnershipAndControl) to be classified as types of Role
See FND Control ontology, restrictions 01 and 02. See restrictions 04 and 06 in Ownership ontology.
Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:11 GMT
Disposition: Resolved — EDMC-FIBO/FND 1.0
Change range of hasRole to ThingInRole; other changes to OrganizationMember
The issue as described indicates a misclassification of roles versus parties in roles when a reasoner is run on the model as it was at Beta1.
Subsequent changes in Beta2 render the original issue moot since it is unlikely that the changed model would yield the same results.
As part of the remodeling of Ownership and Control, changes were made in FTF1 which also render the property ‘hasRole’, with domain of Thing and range of Role would also either be moot, or would require a new domain and / or range.
This proposed resolution is to have hasRole with a domain of ThingInRole and a range of Role, making effectively a terminological equivalence to the semantics of the role as defined for the ThingInRole class (e.g. Issuer).
Changes described for OrganizationMember (in the Parties ontology) remain as they were in the previous proposed resolution to this issue.
There is a restriction on this property in the ontology Roles:
ThingInRole is sub class of fibo-fnd-pty-rl-02 onProperty hasRole min 1 onClass Role
This is retained.
Previous usages of hasRole:
In Control – property restriction 02 (this is now onProperty ‘isPlayedBy’instead of ‘hasRole’)
In Ownership: Property restriction 06 (this is now onProperty ‘isPlayedBy’ instead of ‘hasRole’)
There is one other usage of this property, in Parties:
In Parties: Property restriction 04 – this is a parent of OrganizationMember and forms part of a complex restriction cascade whereby OrganizationMember is necessarily a member of the class of things with property hasRole, with someValuesFrom the restriction on property isMemberOf allvalueFrom Organization.
Change: as with the previous 2 restrictions, this should now be in property isPlayedBy. This means that an organization member, as a party in a role, is played by (a kind of hasIdentity relationship), that which is a member of some organization.
Updated: Tue, 21 Apr 2015 01:18 GMT
- JIRA 8 Issue Resolution-2.docx 183 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- JIRA8v2-1_Role Definitions.svg 558 kB (image/svg+xml)
- JIRA8v2-2_RolesRow.docx 14 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- JIRA8v2-3 Organization Member.svg 467 kB (image/svg+xml)
- JIRA8v2-4 Parties Row.docx 14 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- Parties.rdf 17 kB (application/rdf+xml)
- Roles.rdf 12 kB (application/rdf+xml)