Subject: [ESDS] Linking events

From: Ali Rezafard <[email-masked]>
Date: Sun, 18 May 2008 01:57:42 -0400

Dear ESDS group,

Attached is a proposed addition to the ESDS protocol schema to enable  
tracing of objects in event of relabeling, aggregation, and  
disaggregation. Often an object's identifier and membership changes as  
it move through and between supply-chains, these changes and  
identifier relationships are referred to as linking events.

Linking events need be maintained in the Discovery Service (DS) to  
enable end-to-end traceability for an object. While DS maintains the  
records for these linking events it is upto the Consolidated  
Information Broker (CIB) to interpret and validate the information.  
Each CIB based on their access privileges will be able to compile the  
chain of events and follow an object through it journey.

Please review and comment.

Thanks,

Ali Rezafard

_______________________________________________
ESDS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/esds

---

From: Mark Harrison <[email-masked]>
Date: Thu, 29 May 2008 18:21:13 +0100

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