GS1 EPCIS Events #552
GS1 EPCIS Events #552
Conversation
| term: EPCISAssociationEvent | ||
| '@id': https://ref.gs1.org/epcis/AssociationEvent | ||
| title: EPCIS Association Event | ||
| description: The event type AssociationEvent describes the association or disassociation of one or several physical objects with a parent object or a specific physical location. Like the AggregationEvent, the AssociationEvent is also used to capture associations where there is a strong physical relationship between the containing and the contained objects such that they will all occupy the same location at the same time, until such time as they are disaggregated. However, the AggregationEvent does not allow for associations of objects with physical locations; if action is DELETE while omitting the childEPC and childQuantityList field, all contained children are disaggregated from the containing parent. Because there are situations in which associations are more permanent, i.e. beyond the physical flow of goods (e.g. packing/unpacking and loading/unloading), an AssociationEvent SHOULD be used (a) when objects need to be associated with a physical location or (b) when the parent object could also be subject to other, more temporary associations (i.e. captured using AggregationEvent). |
There was a problem hiding this comment.
| description: The event type AssociationEvent describes the association or disassociation of one or several physical objects with a parent object or a specific physical location. Like the AggregationEvent, the AssociationEvent is also used to capture associations where there is a strong physical relationship between the containing and the contained objects such that they will all occupy the same location at the same time, until such time as they are disaggregated. However, the AggregationEvent does not allow for associations of objects with physical locations; if action is DELETE while omitting the childEPC and childQuantityList field, all contained children are disaggregated from the containing parent. Because there are situations in which associations are more permanent, i.e. beyond the physical flow of goods (e.g. packing/unpacking and loading/unloading), an AssociationEvent SHOULD be used (a) when objects need to be associated with a physical location or (b) when the parent object could also be subject to other, more temporary associations (i.e. captured using AggregationEvent). | |
| description: The event type AssociationEvent describes the association or disassociation of one or several physical objects with a parent object or a specific physical location. Like the AggregationEvent, the AssociationEvent is used to capture associations where there is a strong physical relationship between the containing and the contained objects, such that they will all occupy the same location at the same time, until such time as they are disaggregated. However, the AggregationEvent does not allow for associations of objects with physical locations; if action is DELETE while omitting the childEPC and childQuantityList field, all contained children are disaggregated from the containing parent. Because there are situations in which associations are more permanent, i.e., beyond the physical flow of goods (e.g., packing/unpacking and loading/unloading), an AssociationEvent SHOULD be used (a) when objects need to be associated with a physical location or (b) when the parent object could also be subject to other, more temporary associations (i.e., captured using AggregationEvent). |
| - eCommerce | ||
| description: >- | ||
| The document recording a transaction between the seller and the buyer. Commercial invoices are normally prepared by sellers. | ||
| The commercial invoice on itself does not grant any ownership of the goods, unless it has an attached document proving the importer's payment for the total amount. The number of copies of the invoice (both original and copies) required for the delivery of the goods, must be agreed with the importer. Usually, invoices are issued with the original and two copies. Although normally the legislation in different countries does not limit the number of originals, it is not advisable to make more than those strictly necessary in order to accomplish with the customs needs required by the buyer. It is advisable that the importer confirms with the exporter all data that the invoice must provide before its issuing, as well as the particularities it must include in order to accomplish with the regulation of the destination country. |
There was a problem hiding this comment.
| The commercial invoice on itself does not grant any ownership of the goods, unless it has an attached document proving the importer's payment for the total amount. The number of copies of the invoice (both original and copies) required for the delivery of the goods, must be agreed with the importer. Usually, invoices are issued with the original and two copies. Although normally the legislation in different countries does not limit the number of originals, it is not advisable to make more than those strictly necessary in order to accomplish with the customs needs required by the buyer. It is advisable that the importer confirms with the exporter all data that the invoice must provide before its issuing, as well as the particularities it must include in order to accomplish with the regulation of the destination country. | |
| In itself, the commercial invoice does not grant any ownership of the goods, unless it has an attached document proving the importer's payment for the total amount. The number of copies of the invoice (both original and copies) required for the delivery of the goods, must be agreed with the importer. Usually, invoices are issued with the original and two copies. Although normally the legislation in different countries does not limit the number of originals, it is not advisable to make more than those strictly necessary in order to comply with the customs needs required by the buyer. It is advisable that the importer confirm with the exporter all data that the invoice must provide before its issuing, as well as the particularities it must include in order to comply with the regulation of the destination country. |
|
Thanks for preparing this. I clicked on the link and although I definitely don't want to discourage you, I have a few comments: The part that somewhat resembles an EPCIS event won't validate against our schema at https://ref.gs1.org/standards/epcis/epcis-json-schema.json or because
If it's easier to take an example of an AssociationEvent that should validate, please consider using something such as https://ref.gs1.org/docs/epcis/examples/association_event-a.jsonld - it's already fairly minimal |
|
Excellent feedback. Not discouraged at all! :) Your first 4 points I 100% expected. Like I said, I only aimed for a super basic starting point, so all those points were expected. So thanks for confirming! I'm not exactly sure how to deal with bullet 4. Will need some nerding around. Any input on how to make it work with the trace-vocab constraints is appreciated. Your last bullet we also discussed on the trace call yesterday. We have a |
|
Regarding bullet point 4, did you already try referencing (within your existing Regarding the last bullet point, https://ref.gs1.org/epcis/bizLocation already has a rdfs:range of gs1:Place (which is modelled on schema:Place but extends it in some ways). If instead of using a URN (URI that typically Resolves Nowhere) such as Typically within EPCIS event data, we avoid bloating the event data by minimising the amount of unnecessary 'master data' / static data and instead just use URIs, assuming that if anyone needs the master data, they can look it up via the URI. Obviously that's much more practical with a Web URI than a URN. So we wouldn't typically include schema:globalLocationNumber or gs1:globalLocationNumber within the event data, nor any other descriptive details that are the same each time that URI appears within an event. In case you're wondering what /414/ is within https://id.gs1.org/414/4012345000023 it's the GS1 Application Identifier for a GS1 Global Location Number of a physical location. (414 = physical location GLN, 417 = GLN of an organisation) |
|
Closing this Draft PR - I will move this discussion to an issue. |
This is a basic proof of concept, implementing the GS1 EPCIS event model with Verifiable Credentials based on the trace vocab infrastructure.
@mgh128, @CraigRe, @VladimirAlexiev I'd love your initial thoughts on this? Just general direction - no need to point out missing details. (I just focused on the most basic elements and also consciously skipped the epcisBody).
The resulting VC can be verified with DID Actor (link below). Note that it will fail until the PR is merged which updated the traceability context.
https://api.did.actor/v/eJylUluTmjAY_S_pq5dw0VWeuou4ahXvl7WzsxNCxCAQNgla3fG_N6hV61unDA8kOTnfufAFvmOWSPJLAusnWEuZCqtc3u12pZ1RYjwo61CrlTEnPkkkRZEobzVQuAEN6p9gkiNMkEcjKvc55L0A5D4lOemMcLqiyIuIfaVRFM7Abo8bDGex2rIJlwqEkST5VSpEhhJMGvnaAjrU9SKsFQ040aAF83cJzijCgfV1HdXnAUroAUnKkhOPr2771Lc2ZG8dqr2NbA2ZsRqN2Hpjmr7wnKeqndFJ-hLve_NPfTYLt7MqehkTx5iCYwHcjI8zLyRY3k_7y0E-jmzVR5eKPMsH2LMQDNOTMGd7gXv00GX4LPaOdhCpKK_qM55YJMWWMiGCKLFMqOmGWSlB9eglqGIIIuah6A-Tm8VeHgp4BB5PA8eSpOoQCUFiL6JJAI7v6iTljK1uIoDj65WKVh_TIEEy4yT_C8ApDtWI_1CJZhmmBc28ku2p67OSHpFr9j8FfPvnxi5GBhlPmSAXn_xOTAGEO6H2yb6z9l4x7dNOc-mMJsNxW7Tjtu7a7eoybgqsT9Xa3aPFkPYjQd_CN9iOtHqp1Fxko5Q4C-x-eOFHEMOVGw1r3Y6sNzY_nka9xmGaBk3HpMX5Wm-G2_7M5a1dyAeB1-sVG-h11Di4AZzONqxVS5KlUZkv7WdwPP4GZaMpqw
#385