Re: [ESDS] ESDS Terminology

Mark Harrison <mark.harrison@cantab.net> Mon, 28 April 2008 18:53 UTC

Return-Path: <esds-bounces@ietf.org>
X-Original-To: esds-archive@optimus.ietf.org
Delivered-To: ietfarch-esds-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CCE3A69F6; Mon, 28 Apr 2008 11:53:23 -0700 (PDT)
X-Original-To: esds@core3.amsl.com
Delivered-To: esds@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15D83A69F6 for <esds@core3.amsl.com>; Mon, 28 Apr 2008 11:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.998
X-Spam-Level:
X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYqU-K73pCLm for <esds@core3.amsl.com>; Mon, 28 Apr 2008 11:53:21 -0700 (PDT)
Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by core3.amsl.com (Postfix) with ESMTP id 3C07A3A692E for <esds@ietf.org>; Mon, 28 Apr 2008 11:53:20 -0700 (PDT)
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]:56787) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:mgh12) (TLSv1:AES128-SHA:128) id 1JqYTZ-0004J2-Nb (Exim 4.67) (return-path <mgh12@hermes.cam.ac.uk>); Mon, 28 Apr 2008 19:53:21 +0100
Message-Id: <7385CE79-5468-424D-896C-C94E4CA9FC19@cantab.net>
From: Mark Harrison <mark.harrison@cantab.net>
To: David.Potter@PROMISE-Innovation.com, esds@ietf.org
In-Reply-To: <002d01c8a37f$2ef60bb0$8ce22310$@Potter@PROMISE-Innovation.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Mon, 28 Apr 2008 19:53:18 +0100
References: <002d01c8a37f$2ef60bb0$8ce22310$@Potter@PROMISE-Innovation.com>
X-Mailer: Apple Mail (2.919.2)
Subject: Re: [ESDS] ESDS Terminology
X-BeenThere: esds@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion of the ESDS \(Extensible Supplychain Discovery Service\)" <esds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/esds>, <mailto:esds-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:esds@ietf.org>
List-Help: <mailto:esds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/esds>, <mailto:esds-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: esds-bounces@ietf.org
Errors-To: esds-bounces@ietf.org

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

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