|
|
The possible type information of the role changes depending on the type of role.
- A classical FCOIM role has no type by default. But could be set similarly as the concepts on an OTFT.
-
A role from concept to concept could contain the direction (a->b, a<-b, a<->b)
- A role from container to concept/container could contain the (
a->b, a<-b, a<->b, contains, subtype, ... ?)
|
|
|
|
A better way may be to use flags.
- (empty) classic fco-im role
- BID functions as a bi-directional indicator for concept relations
- INP functions as a input indicator for rules/calculations
- OUT functions as a output indicator for rules/calculations
- DOC functions as a documentation for a targeted element
- TPL functions as a template for a targeted element
- ...
These flags could affect GLR instructions if also used on regular Fact/Object/Label types.
|
|
|
|
A role which is used as a start for a rolepath, should be able to override the properties, constraints and annotations of the final role pointed to. Therefor, a role function "PATH" should be added to allow role override functonality. |
|
|
|
For Rules which are using roles to relate them to OTFTs may need flags as well. The rules may need some OTFT as input, and Derived OTFTs as Output. The input/output flags is something to annotate as well. The input/output could be in code, or simply encoded by a direction flag.
|
|
