Uniform representation of instance and occurrence data
This issue was discussed completely and the following items were discussed and to a large extent agreed:
・Parts library does not restrict the APs on how they define their properties;
・It may not be possible to represent all occurrence data in the IEC format;
・End-user may need to be able to distinguish between instance and occurrence data;
・Uniform representation of instance and occurrence data in a single dictionary would be an essential requirement for AP226 in order to keep its current SCM (Ship Common Model) approach;
・There is a need to leave the context of a property (whether instance or occurrence/measured or predicted and so on) out of the definition of a property and represent it in the AP226 data model.
Based on discussion, it was agreed that AP226 would represent the occurrence properties in the same format as instance properties and CTC will implement this decision.
Representation of groups of properties in AP226
Z Bazari (LR) presented the high level conceptual model on how AP226 model will use its Plib-compliant dictionary. He described the current AP226 model in which the properties are grouped in various classes of entities and then referenced by a class of object. The schema presented supports the definition of these types of entities by reference to properties in the dictionary. The meeting agreed that the approach seems reasonable.
The discussion then focused on how detailed these entities need to be specified in AP226. The following points were raised:
・AP is free to group properties according to its business needs;
・For longer term usage of the AP, it would be better to keep the detailed specification of these entities outside of the AP226. In this case, details of such objects can be specified in an implementation agreement. Guy felt that grouping should not be enforced, because we cannot anticipate all the business processes within which the AP will be used. Gerry said that experience with other APs shows that we should avoid hard-coding what we consider rules of "good engineering practice" into data structure constraints;
・Z Bazari stated that the above proposal is practical but leaves the AP226 too generic and open to interpretation by end-users. He agreed that detailed specification of all the grouped properties also will not be a good option as it would make the AP too rigid and difficult to adapt to new business cases or scenarios.
