|
Example: |
The AggregationEvent type includes fields that refer to a single “parent” (often a “containing” entity) and one or more “children” (often “contained” objects). A parent identifier is required when action is ADD or DELETE, but optional when action is OBSERVE.
A parent identifier is used when action is ADD so that there is a way of referring to the association in subsequent events when action is DELETE. The parent identifier is optional when action is OBSERVE because the parent is not always known during an intermediate observation. For example, a pallet receiving process may rely on RFID tags to determine the EPCs of cases on the pallet, but there might not be an RFID tag for the pallet (or if there is one, it may be unreadable).
The AggregationEvent is intended to indicate aggregations among physical objects, and so the children are identified by EPCs. The parent entity, however, is not necessarily a physical object that’s separate from the aggregation itself, and so the parent is identified by an arbitrary URI, which MAY be an EPC, but MAY be another identifier drawn from a suitable private vocabulary.
In many manufacturing operations, for example, it is common to create a load several steps before an EPC for the load is assigned. In such situations, an internal tracking number (often referred to as a “license plate number,” or LPN) is assigned at the time the load is created, and this is used up to the point of shipment. At the point of shipment, an SSCC code (which is an EPC) is assigned. In EPCIS, this would be modeled by (a) an AggregateEvent with action equal to ADD at the time the load is created, and (b) a second AggregationEvent with action equal to ADD at the time the SSCC is assigned (the first association may also be invalidated via a AggregationEvent with action equal to DELETE at this time). The first AggregationEvent would use the LPN as the parent identifier (expressed in a suitable URI representation; see Section 6.4), while the second AggregationEvent would use the SSCC (which is a type of EPC) as the parent identifier, thereby changing the parentID.
Explanation (non-normative): In the case where action is ADD and a non-empty bizTransactionList is specified, the semantic effect is equivalent to having an AggregationEvent with no bizTransactionList together with a TransactionEvent having the bizTransactionList and all same field values as the AggregationEvent. Note, however, that a AggregationEvent with a non-empty bizTransactionList does not cause a TransactionEvent to be returned from a query.
Note (non-normative): Many semantically invalid situations can be expressed with incorrect use of aggregation. For example, the same EPC may be given multiple parents during the same time period by distinct ADD operations without an intervening Delete. Similarly an object can be specified to be a child of its grand-parent or even of itself. A non-existent aggregation may be DELETED. These situations cannot be detected syntactically and in general an individual EPCIS repository may not have sufficient information to detect them. Thus this specification does not address these error conditions. |
|
|
