Re: [ESDS] Draft Problem Statement 00

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: jan.boen@sita.aero

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

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:

>
> 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
> ESDS@ietf.org
> https://www1.ietf.org/mailman/listinfo/esds

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

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.

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