Subject: Re: [ESDS] Draft Problem Statement 00

From: "Ashkan Fadaiefard/Simard" <[email-masked]>
Date: Tue, 29 Jan 2008 11:07:52 -0500

Dear ESDS group,

I have read the proposed Problem Statement, and I had some comments.
As a large logistic company the problem of Discovery Service is of
interest to us. I feel that an important scenario is missing from the
document, and that is aggregation and disaggregation. The use case
below explains the scenarios in detail.

Products produced from manufacturers can be packaged differently. 
Single product in one box, or multiply products in one box.
For example a shoe company produces shoes from different manufacturer. 
Some manufactures packages one pair of shoe in one box and some others 
will put multiply boxes of shoes, different sizes and colour mixed in 
one larger box. Once the products arrive in the distribution centre, 
the products needs to be sorted based on their model, colour and size
however all the boxes have the same tag thus the distribution
centre needs to identify each box and apply new tags.

Another example is when a box contains 1000 products. The box is 
tagged as 1 box set to contain 1000 products. In a pick and pack operation 
the box
will be opened and based on orders from retailers the products will be 
removed 
from the box thus the inventory of the box is reduced however the tag 
still reads 1000 products. Also the products shipped to the retailers need 
to be 
re-tagged before shipping to consignee.

So in the future, when we want to have visibility from beginning to end of 
a supply chain, 
we need to have proper handling (protocol) for this kind of scenario.

Best Regards,
Ashkan Fadaiefard

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

---

From: Mark Harrison <[email-masked]>
Date: Tue, 29 Jan 2008 18:47:24 +0000

Dear Ashkan,

Many thanks for posting these use cases to the ESDS mailing list.  It  
is always very helpful to receive such input from potential end-users  
of Discovery Services.

I agree with you that it may be important to be able to record changes  
of aggregation (including disaggregation) within a Discovery Service,  
even if such aggregation events are also available within an  
information service (e.g. an EPC Information Service) provided by an  
organization that is doing the aggregation / disaggregation.

One of the problems with relying on 'following the chain' from the  
manufacturer to the current downstream custodian of the object is that  
there could be a broken link in the chain if one of the organizations  
does not provide an onward link - or if their information service is  
temporarily (or permanently) unavailable.  A Discovery Service can  
provide some resilience to ensure that (subject to having the correct  
credentials and access privileges), it is always possible to 'navigate  
beyond a broken link' to find who currently has the object.

However, if the identifier of the object to be tracked changes at some  
intermediate point within the supply chain, then this is potentially  
equivalent to a broken link.  Aggregation and disaggregation (as well  
as re-labelling) all represent a change of identifier (including  
convergence or divergence between one identifier and the identifiers  
of many 'child' objects contained within a 'parent' container) - so in  
order to solve the 'broken link' problem, we may well need to allow  
for changes of aggregation to also be stored within Discovery  
Services, even if such information is also available elsewhere most of  
the time (e.g. in EPC Information Services of individual companies).

Although the current ESDS internet drafts do not explicitly support  
aggregation event at this time, the EU BRIDGE project has considered  
this in their design for Discovery Services.  We have contributed a  
number of our public documents to the ESDS mailing list and also begun  
a comparison of the ESDS internet drafts with the BRIDGE designs.  The  
initial version of this comparison exercise will be posted to the ESDS  
mailing list very soon and is intended to stimulate discussion on  
topics, such as the one you raise, regarding aggregation changes.

Many thanks for your comments today.  We look forward to further  
discussions with you.

Best regards,

- Mark Harrison

On 29 Jan 2008, at 16:07, Ashkan Fadaiefard/Simard wrote:

> tagged as 1 box set to contain 1000 products. In a pick and pack  
> operation the box
> will be opened and based on orders from retailers the products will  
> be removed
> still reads 1000 products. Also the products shipped to the  
> retailers need to be
> So in the future, when we want to have visibility from beginning to  
> end of a supply chain,
> Ashkan Fadaiefard_______________________________________________
> ESDS mailing list
> [email-masked]

---

From: [email-masked]
Date: Tue, 29 Jan 2008 20:20:11 +0100

Mark, all,

Just one general comment:
What we should keep in mind is that the DS is a "THIN" service.
As long as the service is thin, slim etc I see no problem in adding some
functionality.
It should not however evolve in to a full fledged application service.
That's not what it is intended to be.

Best regards,

Jan

Jan Boen
Director Auto ID SET
CSBU - SITA

Tel: +32 2 745 0598
Fax: +32 2 745 0570
Mobile: +32 473 933 190
E-mail: [email-masked]

             Mark Harrison                                                 
             <mark.harrison@ca                                             
             ntab.net>                                                  To 
                                       Ashkan Fadaiefard/Simard            
             29/01/2008 19:47          <[email-masked]>             
                                                                        cc 
                                       [email-masked]                       
                                                                   Subject 
                                       Re: [ESDS] Draft Problem Statement  
                                       00                                  

                                                                           

Dear Ashkan,

Best regards,

- Mark Harrison

This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.

---

From: Mark Harrison <[email-masked]>
Date: Tue, 29 Jan 2008 19:34:20 +0000

Dear Jan et al.,

Thanks - this is a good point, which we must always keep in mind.

While the BRIDGE design anticipates that there may be a case for  
allowing storage of aggregation changes within a Discovery Service, it  
attempts to keep the DS a "THIN" service by not requiring the DS to  
'automatically' track up and down across various aggregation changes.   
i.e. it only provides links for events that reference the original  
unique ID specified in the query.

In a sense, we're taking a minimal approach, similar to that in EPCIS  
- that the service is only expected to return (a subset of) the data  
that is pushed into it - but is not required to do any interpretation  
about the 'event data' - other than performing simple filtering  
against query criteria (and enforcement of access control policies).

In the EU BRIDGE project, we have made this distinction quite clear by  
having a separate technical work group (WP3) working on a design (and  
prototype) for an enhanced track-and-trace application for serial- 
level data, while work package WP2 focused on the design and  
prototyping of a THIN Discovery Service.

Of course, the fully-fledged 'track and trace' may query Discovery  
Services and other information services - but in many cases, it may be  
implemented as an application within a single organization - and the  
results from such an application might not be made available to other  
organizations within the supply chain or product lifecycle - but might  
instead just be used internally within a single organization for  
monitoring their supply chain upstream and downstream.

Best regards,

- Mark

On 29 Jan 2008, at 19:20, [email-masked] wrote:

> This document is strictly confidential and intended only for use by  
> the addressee unless otherwise stated.  If you are not the intended  
> recipient, please notify the sender immediately and delete it from  
> your system.
>
>