Re: [ESDS] Interaction models for Discovery Services

Mark Harrison <mark.harrison@cantab.net> Thu, 10 July 2008 12:27 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF8F28C102; Thu, 10 Jul 2008 05:27:15 -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 D9EC628C0F6 for <esds@core3.amsl.com>; Thu, 10 Jul 2008 05:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 TCh-m7bk06vS for <esds@core3.amsl.com>; Thu, 10 Jul 2008 05:27:12 -0700 (PDT)
Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by core3.amsl.com (Postfix) with ESMTP id E185E3A6A36 for <esds@ietf.org>; Thu, 10 Jul 2008 05:27:11 -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]:59602) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpsa (PLAIN:mgh12) (TLSv1:AES128-SHA:128) id 1KGvF2-0003kv-5R (Exim 4.67) (return-path <mgh12@hermes.cam.ac.uk>); Thu, 10 Jul 2008 13:27:20 +0100
Message-Id: <F1E8CE72-929D-408D-BB79-080B636CDCEF@cantab.net>
From: Mark Harrison <mark.harrison@cantab.net>
To: Kary Främling <Kary.Framling@hut.fi>
In-Reply-To: <4875FAD4.9010808@hut.fi>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Thu, 10 Jul 2008 13:27:19 +0100
References: <8438190C-CAE5-4D1F-8FD6-758D7C909DAF@cantab.net> <4875FAD4.9010808@hut.fi>
X-Mailer: Apple Mail (2.926)
Cc: esds@ietf.org
Subject: Re: [ESDS] Interaction models for Discovery Services
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-Archive: <http://www.ietf.org/pipermail/esds>
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes"
Sender: esds-bounces@ietf.org
Errors-To: esds-bounces@ietf.org

Dear Kary, ESDS people,

Many thanks for these helpful comments.  The slides I posted were as  
they were presented to the EPCglobal Data Discovery Joint Requirements  
Group.
Of course, in the ESDS discussions, we are also thinking about  
Discovery Services in a wider, more general context.
I should make therefore make the following comments, which ESDS folks  
may wish to consider when reading these presentations:


Identifiers - not only EPC:
====================
ESDS is considering not only Electronic Product Codes (EPC) but more  
general kinds of identifiers - so any references to 'EPC' or 'EPC  
identifier' could also be interpreted as an individual ID of an  
object, whether expressed as a string, a URN or specifically an EPC  
URN string.
As I presented the slides, I often said 'EPC or individual ID' (to  
indicate this more general use in the ESDS context).


DS granularity and co-operation:
==========================
In one of the presentations, I did mention that the ESDS group had  
been thinking about having a federation of Discovery Services - and  
even the EPCglobal DD JRG seems to be coming around to the idea of a  
co-operative Network of Discovery Services - rather than attempting to  
fit everything into a single DS or small number of Discovery  
Services.  I think they could understand the potential benefit of  
partitioning implementations of DS according to industry sector or  
geographic region (while at the same time striving towards a technical  
protocol for the interfaces and data model that is truly global and  
sector-agnostic.)

I'm not entirely convinced about whether home users would want to  
install a DS within their home, since they might typically only have 0  
or 1 EPCIS in their home. However, I can see an argument for a home  
user installing a DS (or at least participating in a 3rd party hosted  
DS) for the purposes of sharing social bookmarks to various resources  
(e.g. web pages indexed by keyword) within a particular community of  
the home user's choice (e.g. with members of their family and friends).


Focus beyond Supply Chain Management:
==================================
I agree with Kary on this about the wider scope beyond SCM that ESDS  
seeks to address - and did verbally give the example of product  
lifecycle information management, tracking of aircraft parts  
throughout maybe 30 years of use after delivery from the integrator to  
the airline operator - and even including use of DS to help with end- 
of-life processes.

Also, as was discussed at the ESDS BOF in March, there could be much  
wider uses of Discovery Services for bottom-up indexing of citizen- 
generated content (e.g. reviews, ratings, commentary , video or photos  
on particular subjects/locations, etc.) - which has nothing to do with  
Supply Chain Management and where the intentional 'publishing'  
approach is in contrast with the top-down approach of spidering /  
crawling of links by today's web search engines.


Types of Information Resources - not only EPCIS:
======================================
The 'Terminology and Scope' presentation is maybe a bit too 'EPCIS'  
centric - since it was written for an EPCglobal audience - though I  
did try to mention the different kinds of resources.  Note also that  
some of the models (especially the Query Relay models) may be more  
difficult to use with general kinds of resources, since the DS simply  
forwards the clients' queries to the resources - and the DS may not  
know how to translate a query intended for one kind of resource (e.g.  
EPCIS) to make it suitable for querying another kind of resource (e.g.  
a web page).  This could be quite a limitation in those models.


Kary - thanks again for posting these comments to the list.  Let's  
hope the presentations of the different models and also your comments  
and these responses stimulate some interesting discussions on the ESDS  
mailing list.


Best regards,

- Mark




On 10 Jul 2008, at 13:04, Kary Främling wrote:

> Dear Mark, ESDS people,
>
> I had a look through the slides. In general, I think they give a  
> well-organised and complete picture of the different possibilities  
> and challenges - even though I did not think through all of them in  
> detail.
>
> I would mainly have the following comments (not intended as  
> criticism!) for the moment:
> - I do not think it is good to restrict DS keys to EPC. Personally,  
> I do not think EPC will wipe out all other numberings and you never  
> know what will be invented in the future. This could become an  
> obstacle to the adoption of the future DS infrastructure.
> - DS granularity: the presentation is quite neutral about this; we  
> would need to support a rather flexible way of creating new DS's,  
> e.g. I might (for some reason) even want to install a DS at my home  
> (in addition to the EPCIS or other information source) and be able  
> to declare my existence to some other, existing DSs. Security and  
> trust are of course always an issue with this but the more  
> "geographically local" the setting up of inter-DS links is, the  
> better is the trust usually. PS! "my home" may not be a realistic  
> scenario but it might be the extreme case - or maybe DS on products  
> would be the extreme case? Anyway, if the DS mechanisms can handle  
> this, then they should be able to handle all levels of "granularity".
> - Focus on SCM: after 3,5 years of work on PLM (or CL2M), I always  
> feel uncomfortable when constrained to speak only in SCM terms. This  
> is because to me, SCM is just a special case of a much broader  
> thing. I do understand that a majority of the ESDS community may  
> think mainly in SCM terms and could get confused by new terminology  
> - but I think the step must be taken at some stage.
> - The emphasis on EPCIS as the main information source is  
> understandable - but other information sources can be used also. The  
> presentations do show this possibility quite clearly but in the  
> beginning there is an impression that EPC/EPCIS are the only truly  
> supported technologies/interfaces/etc.
>
> It seems to me that the answers to most of these comments are  
> already somewhere in the slides, so it may mainly be a question of  
> terminology and presentation. Anyway: I think you are doing a good  
> job, Mark - thanks for your efforts!
>
> Best regards,
>
>   Kary
>
>> Dear ESDS colleagues,
>>
>> Following on from the previous discussions on this mailing list  
>> about the interaction between Discovery Services and 'Consolidated  
>> Information Brokers', I have attached a couple of Powerpoint  
>> presentations, which I presented 3 weeks ago at a face-to-face  
>> meeting of the EPCglobal Data Discovery Joint Requirements Group.
>>
>> The presentation on the interaction models considers the possible  
>> sequences of message flows between a query client, an information  
>> resource and a Discovery Service, considering suitability of each  
>> model for one-off queries as well as standing queries, together  
>> with an analysis of their relative merits in terms of protecting  
>> the confidentiality of information resources, confidentiality of  
>> clients' queries, as well as considering the kinds of data to be  
>> stored in a DS, performance and latency issues and impact on the  
>> network traffic and possible security threats.
>>
>> The slides are intended to provide an easy-to-read animated summary  
>> of the analysis contained in section B of  the document D2.4 from  
>> the BRIDGE project (High-level design document).
>>
>>    http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design%20Discovery%20Services.pdf
>>
>> I would also like to acknowledge that the original BRIDGE document  
>> D2.4 section B was jointly authored by Trevor Burbridge (BT),  
>> Oliver Kasten (SAP), Cosmin Condea (SAP) and Mark Harrison  
>> (University of Cambridge, Auto-ID Lab), with additional inputs from  
>> Nicholas Pauvre  (GS1 France) and members of AT4 wireless (who led  
>> BRIDGE WP2).
>>
>>
>> I have also attached an Excel spreadsheet which indicates some of  
>> the advantages and disadvantages from the perspectives of the  
>> client, resource, DS and network traffic, together with some  
>> possible countermeasures.  Feel free to modify the spreadsheet -  
>> though I suggest that you highlight any changed cells (e.g. set  
>> background colour of cell to yellow) so it is clear to everyone  
>> which changes you have made.
>>
>> I really hope that these presentations and the spreadsheet will  
>> stimulate some lively discussion on this mailing list and I look  
>> forward to reading your comments about the different interaction  
>> models for Discovery Services.
>>
>> Best regards,
>>
>> - Mark Harrison
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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