Dear Mark, ESDS group,

Thank you for your comments and feedback on the proposed protocol  
changes to ESDS. Attached is the revised version of the protocol,  
which integrates the feedback received.

The revised proposal is aligned with the EPC terminology and data  
model while maintaining support for none-EPC identifier schemas.

Additionally a new 'RELABEL' value is defined for the data field  
'Action' to better express change of identifier for an object.

Best Regards,

Ali Rezafard

On 29-May-08, at 1:21PM, Mark Harrison wrote:

> Dear Ali, ESDS folks,
>
> I was interested to see Ali's recent ESDS posting about 'link  
> events' - as a way to handle aggregation, disaggregation,  
> association, dissociation and re-labeling.   The uni-directional  
> linking within the data model is certainly a different approach from  
> what we took in the BRIDGE project design work for Discovery Services.
>
> In the BRIDGE design work for Discovery Services, we have tried to  
> align closer to the EPCIS 1.0 data model - so we considered two  
> kinds of records - regular DS Records (similar to the ESDS Object  
> Events) and DS Aggregation Records (somewhat similar to the link  
> events).
>
> The EPCIS 1.0 data model defines four sub-types of EPCIS events -  
> ObjectEvents, AggregationEvents, TransactionEvents and QuantityEvents.
>
> EPCIS ObjectEvents are used for recording event information about an  
> individual EPC or list of EPCs.
>
> EPCIS AggregationEvents are specifically used for recording event  
> information about a parent-child hierarchy, consisting of a single  
> parent object and one or more children.
>
> In EPCIS, the data field 'Action' takes the values 'ADD', 'OBSERVE'  
> or 'DELETE' and these values have different interpretations  
> depending on the sub-type of event.
>
> In ObjectEvents, Action='ADD' is used to indicate that one or more  
> EPCs have been commissioned or created for the first time in their  
> entire lifecycle.  N.B.  Action='ADD' is NOT used to report the  
> first sighting of an EPC within an organization that merely handled  
> it.
> Action='DELETE' is used to terminate or decommission the EPC,  
> usually at the end of life of the individual object.  This  
> indication of decommissioning can be particularly useful for marking  
> 'closure' so that it is possible to ensure that discarded packaging  
> with RFID tags or unique ID barcodes cannot be reused to inject  
> counterfeit product into the supply chain.
> Most ObjectEvents are observations and correspond to Action='OBSERVE'
>
> In AggregationEvents, Action='ADD' indicates that one or more  
> children objects have been added to a parent ID.  Action='DELETE'  
> indicates either that specific listed children objects have been  
> disaggregated from the specified parent ID - OR if Action='DELETE'  
> and childEPCs is empty, it indicates that all children objects have  
> been disaggregated from the specified parent ID.
> Action='OBSERVE' can be used to indicate that a parent and one or  
> more child EPCs have been observed together in the same event - but  
> does not indicate that a change of aggregation has taken place.
>
> EPCIS 1.0 does not formally specify how to indicate re-labelling of  
> objects (because an EPC is intended to be for the whole life of an  
> object).  However, it is conceivable that some end-users might  
> (mis)use an AggregationEvent in order to indicate where relabelling  
> has taken place, perhaps treating the original ID as the child and  
> the new ID as the parent.
>
> The BRIDGE high-level design for Discovery Services (see D2.4  
> section A) tries to align with the EPCIS data model except that we  
> define some additional values of the 'Action' field for basic DS  
> records:
>
> LINK		- indicates a link to a resource (default / most common value  
> of Action field for basic DS records in the BRIDGE design)
> CREATE	- the object has been created for the first time
> CLOSE		- chain of custody for forward supply chain has reached its  
> formal endpoint (e.g. Point of Sale)
> DESTROY	- physical object has been destroyed.
>
> For aggregation records within a DS, we align with the ADD /  
> OBSERVE / DELETE values of the Action field used in EPCIS 1.0
> Note that we also allow an aggregation record to be published to a  
> DS in which either parent ID or childEPCs are not both specified -  
> just to indicate that a change of aggregation has happened.  In this  
> case, a client would need to query the corresponding EPCIS to  
> request details of the aggregation event.  Note that this is a  
> subtly different interpretation from EPCIS 1.0.
>
> The major difference between the EPCIS/BRIDGE approach to handling  
> linking/aggregation is that in the data model itself, there are no  
> uni-directional links that affect the visibility of an event; an  
> AggregationEvent specifies a parent ID and children EPCs - and via  
> the EPCIS query syntax, you can apply a constraint of either  
> MATCH_parentID, MATCH_childEPCs or MATCH_anyEPC - where MATCH_anyEPC  
> will match for IDs that are specified either as the parentID or as  
> one of the childrenEPCs.  This means that if we know one ID, we can  
> (subject to what the access control policies allow) see the other  
> IDs associated with that ID.  It also means that the underlying data  
> model remains more symmetric, rather than building in asymmetry that  
> should probably be handled by access control policies.
>
> There may be valid use cases for uni-directional or restricted  
> visibility regarding linking of identifiers.  However, my  
> understanding is that EPCIS 1.0 and BRIDGE WP4 expect this to be  
> achieved via an access control policy framework rather than by  
> creating such unidirectional linking in the underlying data model.
>
> To give a concrete example of this, consider a situation where fresh  
> food products are being transported in reusable containers leased  
> from a reusable container pooling company.  We may want to allow the  
> pooling company to track their containers at all times - but not  
> necessarily gain information about the shipments that are being  
> transported on them.  The pooling company may wish to offer its  
> customers (e.g. the food companies) with a value-added service that  
> allows them to track their food products by association with the ID  
> of the container in which it is transported - but only within one or  
> more limited time windows when they are legitimate users of that  
> container. The pooling company would need to take care to ensure  
> that the event data available to one customer is not available to  
> another (possibly competing) customer who happens to use the same  
> container at a later time.  BRIDGE WP4 is working on a sufficiently  
> expressive, flexible and machine-readable access control policy  
> framework that can be used to govern who is granted access to  
> specific events.  The results of such enforcement may be to suppress  
> (remove visibility) of some events from particular clients - or even  
> to modify the fields - e.g. to remove particular data fields within  
> events.  By taking this approach, rather than creating  
> unidirectional links within the data model, a single aggregation  
> event may be shown differently to different clients.  e.g. the  
> pooling operator might only see the data fields corresponding to its  
> container ID, while its customer should only see events relating to  
> shipments it handles - and not shipments from other companies who  
> use the same container at other times.
>
>
> Regarding linking to other Discovery Services, the BRIDGE design  
> allows a record to link not only to EPC Information Services (EPCIS)  
> but to other service types, including other Discovery Services.
>
> In the BRIDGE WP2 design, we don't deal with linking to different  
> supply chains (or supply chain fragments) - since WP4 (security) is  
> developing the access control policy framework.  I am not sure  
> whether it will even be possible to specify different supply chain  
> IDs within events at the time when events are created or published -  
> or whether this is again something that needs to be handled via the  
> access control policy framework.  Each party within a supply chain  
> may view its upstream suppliers as one supply chain fragment  and  
> its downstream partners as a different supply chain fragment - and  
> I'm not sure we can really define statically which supply chain an  
> event belongs to at the time it is created or published to a DS.  An  
> alternative approach may be to create or publish an event to a DS  
> and have this be subject to an access control policy that the  
> publisher specifies - and let the DS enforce that policy to  
> determine who has visibility of it.  It should even be possible to  
> modify the policies over time without needing to change the  
> underlying records.  This approach might also reduce the number of  
> link/aggregation events that need to be published in a DS.
>
>
> A general remark I would make about Ali's proposal for link events  
> is that ESDS needs to think carefully about whether or not to try to  
> maintain good alignment with the EPCIS 1.0 data model, given that  
> some members of ESDS hope that what is developed here may be useful  
> for adoption or future technical development by the EPCglobal  
> community.  If we can align with their terminology and data model at  
> an early stage and call an apple when it is an apple, rather than  
> calling it an orange, then we can make the 'transfer/adoption' and  
> 'translation' process far easier for the EPCglobal community, so  
> they can more easily understand and hopefully consider adopting some  
> or all of what ESDS develops.
>
> Best regards,
>
> - Mark

_______________________________________________
ESDS mailing list
ESDS@ietf.org
https://www.ietf.org/mailman/listinfo/esds