Re: [ESDS] Draft Problem Statement 00

[Mark Harrison <[e-mail]>]

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, [e-mail] wrote:

> 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: [phone]
> Fax: [phone]
> Mobile: [phone]
> E-mail: [e-mail]
>
>
>
>             Mark Harrison
>             <mark.harrison@ca
>              
> ntab.net>                                                  To
>                                       Ashkan Fadaiefard/Simard
>             29/01/2008 19:47          <[e-mail]>
>                                                                        cc
>                                       [e-mail]
>                                                                    
> 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/esds
>
>
> _______________________________________________
> ESDS mailing list
> [e-mail]
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/esds