Subject: Re: [ESDS] ESDS Terminology

From: Kary Främling <[email-masked]>
Date: Thu, 08 May 2008 16:10:27 +0300

Dear all,

I agree with the need for a 'Consolidated Information Broker' (CIB - or 
whatever name it should have) that would aggregate and simplify access 
to different Discovery Services (ONS and others). The "method interface" 
of the CIB would just consist in methods for retrieving a list of 
information providers related to some product identifier (EPC or other) 
but how this is done, i.e. what different discovery services are used 
(ONS or others) would normally be irrelevant to the caller. The CIB 
would take care of the actual job of contacting all relevant DSs.

There could also be options for indicating preferred DSs to use or 
letting the CIB determine that based on what kind of information or 
information sources are requested, e.g. manufacturing information only, 
disposal information only etc.

The CIB could also have another method that would allow retrieving the 
actual information directly, rather than only retrieving links to 
information providers. However, that would obviously increase the size 
and complexity of the CIB implementation. A better solution would be 
that the links to information providers would be usable as a parameter 
for another service that would know how to retrieve information from 
different kinds of information services, such as EPCIS, PMI (PROMISE) or 
others.

Maybe we could also use this approach to illustrate the separation 
between "Discovery Services" and "Information Services"? Meaning:
1. CIB-DS: core interface has a method "String 
getInformationSources(String itemIdentifier)" that returns a list of 
links that correspond to the request, as some kind of XML-formatted 
String (presumably). This is what most DSs would have anyway, I guess.
2. CIB-IS: core interface has a method "String getInformation(String 
informationSources)" that returns an XML-formatted list of retrieved 
information. This is what most ISs have already, more or less. 
Obviously, if the returned information comes from many kinds of 
different information sources (EPCIS, PMI, others), then the requesting 
party may not be able to interpret or use all of it - but this is an IS 
issue, not a DS issue.

CIB-DS and the actual underlying DS systems definitely belong to the 
scope of Discovery Services, while CIB-IS does not (except for the 
"informationSources" parameter) - even though  no CIB-IS initiative 
probably exists for the moment, neither.

I hope this is understandable at least to a majority of the recipients. 
Finding a common terminology is definitely a challenge in this kind of a 
discussion!

Kind regards,

   Kary Främling

>Dear ESDS folks,
>
>Thank you to David for suggesting that we should also consider the  
>role of a 'Consolidated Information Broker' that provides an end-user  
>with a convenient way of retrieving complete lifecycle information  
>from multiple Discovery Services and the underlying information  
>services that are referred to by the Discovery Service links.
>
>This is a very plausible scenario - and the 'Consolidated Information  
>Broker' could well be implemented within a single organization as a  
>track and trace application that needs to interface to Discovery  
>Services and information services to collect event information as  
>initial input to more sophisticated analysis algorithms and decision- 
>making capabilities.  In other situations, the 'Consolidated  
>Information Broker' may be a value-added service offered to multiple  
>users in different organizations.
>
>In fact, the EU BRIDGE project has anticipated something similar to  
>this in its work.  Work package 2 focused on the design and  
>prototyping of lightweight Discovery Services, while work package 3 is  
>concerned with serial-level supply chain control.  Currently, the work  
>package 3 partners are developing a software prototype of a framework  
>for enhanced track and trace capabilities.  This consists of a module  
>called the 'Event Gathering Layer' that interfaces to Discovery  
>Services and EPCIS and iteratively performs the necessary queries or  
>registers query subscriptions in order to track a particular object  
>end-to-end - this can also include automatic tracking of parent  
>containers or child objects (e.g. when a bulk product is broken down  
>into smaller units).  Non-probabilistic and probabilistic track and  
>trace algorithms are then invoked to analyze the event data and learn  
>the flow patterns from accumulated historical data for similar  
>objects.  Finally, an Application Programming Interface and Graphical  
>User Interface are also being developed as part of the prototype, to  
>allow for intuitive configuration of supply chain networks and  
>hierarchies, as well as display of problems and generation of alert  
>messages.  An overview of this related work will be given in a public  
>webinar of the BRIDGE project on Wednesday 21st May.
>
>A key point about considering this additional component in the  
>interactions is that it is not necessary to overload Discovery  
>Services with too many additional functional requirements - we always  
>have to consider what is core functionality for a Discovery Service -  
>versus what is functionality for a Track & Trace application or  
>'Consolidated Information Broker'.  In the latter case, in ESDS we  
>only have to provide just sufficient functionality or 'hooks' in a  
>Discovery Service to allow an application to do the rest - whether  
>that is generating alerts, checking plausibility of flow patterns,  
>following up/down multiple levels of aggregation or across changes of  
>identifier to track (e.g. upon relabelling).
>
>Best regards,
>
>- Mark
>
>
>
>On 21 Apr 2008, at 08:13, David Potter wrote:
>  
>
>>Dear ESDS Colleagues,
>>I have been following the postings on this forum with great interest  
>>since a few weeks before IETF 71, where I attended the ESDS BOF, and  
>>ever since.
>>I noticed at the ESDS BOF that a lot of the discussion, and comments  
>>afterwards, seemed to arise from a lack of clarity in the following  
>>two main points:
>>1.       The need for a crystal clear distinction between “discovery  
>>services” and “information services” (information is a difficult  
>>word to avoid).
>>2.       Use of terminology like “application” or “supply chain”  
>>which mean different things depending on sector, experience and  
>>other factors, and may unnecessarily limit or broaden the scope  
>>according to interpretation.
>>In my opinion, in order to get an endorsement at the IETF Dublin  
>>meeting for an “ESDS” Working Group, which I happen to believe is  
>>crucially important, the new Problem Statement that will be  
>>submitted must at least properly address the two points above.
>>For those of you who do not recognise me, I have been the Chairman  
>>of the Project Steering Board of, and also a strong participant in  
>>the EU PROMISE Project, which formally ends on May 14th. Because a  
>>number of partners in the project are strongly motivated to further  
>>the work and results of PROMISE, three of us have already  
>>established a company, Promise Innovation International Oy, in  
>>Finland, to continue to carry the PROMISE flag and rally the troops  
>>behind it. We have a fundamental interest and dependency on the  
>>eventual results of the “ESDS” community.
>>As we emerge from the PROMISE Project itself, our future vision is  
>>for “Closed Loop Lifecycle Management”. Not just productlifecycle  
>>management, or supply chain. We now foresee common discovery and  
>>information services which support the closing of the information  
>>loop for almost any kind of entity, an item, an assembly, a complex  
>>product, a pallet of goods, a piece of baggage,  human food and  
>>beverage, animal feeds, pharma, healthcare patients, animals etc.  
>>etc. This is what drives me to believe that the ESDS Problem  
>>Statement needs to be constructed using terminology that is as  
>>neutral as possible. I believe we can do that together!
>>I have been prompted to make this posting by Mark Harrison’s posting  
>>“Diagrams to help towards a consistent terminology for generic  
>>Discovery Services”. I attach a PPT and PDF file of my own diagram,  
>>based on Mark’s, which I believe goes part of the way to express  
>>what, from a PROMISE point of view, seems to me to be how the  
>>relationship between DS and “information services” might eventually  
>>pan out. I am cautious even to use the phrase “information services”  
>>in case of misunderstanding, but I hope the notes imbedded in  the  
>>attached PPT and PDF files will make the picture clearer.
>>I claim no “authority” in the way I have used terms in these files,  
>>I am very flexible to find better or more appropriate terminology in  
>>everything. Also the diagram is quite simple and ignores a lot of  
>>potential detail, but the most important thing I want to demonstrate  
>>is how the RELATIONSHIP between Discovery Services, “information  
>>services” and their users might be portrayed.
>>I look forward to what I imagine might be an interesting discussion!
>>Best regards,
>>David.
>>
>>
>>The contents of this e-mail and any attachments are the property of  
>>PROMISE-INNOVATION and are intended solely for the named  
>>recipient(s). The contents may be confidential and should not be  
>>communicated to anyone else without our express consent. If you have  
>>received this in error please notify the sender and delete it from  
>>your system
>>
>>
>>
>>
>><DS_Terminology_2.ppt><DS_Terminology_2.pdf>
>>_______________________________________________
>>ESDS mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/esds
>>    
>>
>
>_______________________________________________
>ESDS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/esds
>
>  
>
_______________________________________________
ESDS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/esds