Re: [ESDS] Draft Problem Statement 00

Mark Harrison <mark.harrison@cantab.net> Tue, 29 January 2008 18:47 UTC

Return-path: <esds-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJvUX-0000Ar-Oh; Tue, 29 Jan 2008 13:47:29 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJvUV-0000Ac-Sp for esds@ietf.org; Tue, 29 Jan 2008 13:47:27 -0500
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJvUV-0003oU-59 for esds@ietf.org; Tue, 29 Jan 2008 13:47:27 -0500
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from mlpc-mgh-p.eng.cam.ac.uk ([129.169.78.104]:51238) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpsa (PLAIN:mgh12) (TLSv1:AES128-SHA:128) id 1JJvUT-0005pY-Tl (Exim 4.67) (return-path <mgh12@hermes.cam.ac.uk>); Tue, 29 Jan 2008 18:47:25 +0000
Message-Id: <EFAECF97-62CB-46D1-8EE6-0C3EDDDF79EF@cantab.net>
From: Mark Harrison <mark.harrison@cantab.net>
To: Ashkan Fadaiefard/Simard <AFadaiefard@simard.ca>
In-Reply-To: <OFDDF6AFF1.DB3E0EF4-ON852573DF.00531D94-852573DF.00589C2D@simard.ca>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [ESDS] Draft Problem Statement 00
Date: Tue, 29 Jan 2008 18:47:24 +0000
References: <OFDDF6AFF1.DB3E0EF4-ON852573DF.00531D94-852573DF.00589C2D@simard.ca>
X-Mailer: Apple Mail (2.915)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: esds@ietf.org
X-BeenThere: esds@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of the ESDS \(Extensible Supplychain Discovery Service\)" <esds.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/esds>, <mailto:esds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/esds>
List-Post: <mailto:esds@ietf.org>
List-Help: <mailto:esds-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/esds>, <mailto:esds-request@ietf.org?subject=subscribe>
Errors-To: esds-bounces@ietf.org

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