Subject: [ESDS] ESDS Terminology

From: "David Potter" <[email-masked]>
Date: Mon, 21 Apr 2008 08:13:16 +0100

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 product lifecycle 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

 

_______________________________________________
ESDS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/esds

---

From: Mark Harrison <[email-masked]>
Date: Mon, 28 Apr 2008 19:53:18 +0100

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.
> 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  
> 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.
> 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>