Subject: [ESDS] Interaction models for Discovery Services

From: Mark Harrison <[email-masked]>
Date: Tue, 8 Jul 2008 11:09:57 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/esds

---

From: Kary Främling <[email-masked]>
Date: Thu, 10 Jul 2008 15:04:36 +0300

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

> ------------------------------------------------------------------------
>

---

From: "Kenneth R. Traub" <[email-masked]>
Date: Thu, 10 Jul 2008 08:21:00 -0400

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

Note that EPCs are URIs (of the form urn:epc:id:...).  So if DS keys are
defined to be any URI, then DS will accommodate not only EPC but any other
numbering system that has a corresponding URI syntax.  For those numbering
systems that don't already have a URI syntax, it is usually straightforward
to create one.  It is also easy for individual enterprises to create URIs
for private identifiers, by using an HTTP URI based on a domain name they
own.  (They may also register a PEN and use an OID, if they prefer an
all-numeric scheme.)

Ken

---
Ken Traub Consulting LLC
+1 (617) 285-4495
[email-masked]

---

From: Mark Harrison <[email-masked]>
Date: Thu, 10 Jul 2008 13:27:19 +0100

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:

> 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  
>> presentations, which I presented 3 weeks ago at a face-to-face  
>> meeting of the EPCglobal Data Discovery Joint Requirements Group.
>>
>> 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).
>>
>> 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.
>>

---

From: "Kenneth R. Traub" <[email-masked]>
Date: Thu, 10 Jul 2008 08:41:46 -0400

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.

A small point, but I believe you mean to say "...a URI or specifically an
EPC URI string."  There's no reason to restrict identifiers to just URNs
(which are a subset of URIs).

On the other hand, I'm not sure you'd want to allow non-URI strings, as
you'd have little hope of insuring their global uniqueness.

The correct formulation is probably "absolute URI".

Ken

---
Ken Traub Consulting LLC
+1 (617) 285-4495
[email-masked]

---

From: <[email-masked]>
Date: Thu, 10 Jul 2008 14:16:35 +0100

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mark Harrison
> Sent: 10 July 2008 13:27
> To: Kary Främling
> Cc: [email-masked]
> Subject: Re: [ESDS] Interaction models for Discovery Services
>.... 
> 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 think as Kary mentioned, the choice to run a localised DS could have a very significant impact on the early deployment of the technology. If a community can choose who can have access, and who hosts the service, then many of the problems of large-scale fine-grained access control policies can be mitigated.

The other point to consider is that we can imagine that DSs may serve very different concepts of community. As Mark mentions: industry segment, partnerships, geographical area etc. Thus it would be wrong to try to enforce a single meaningful structure on the system. Certainly structuring a single global DS system by identifier (like DNS) doesn't seem sensible as I loose any choice (and also any business or geographic relationship) with the parties hosting of my data and routing my queries.

If we allow DSs to represent different overlapping community concepts we can also see that an information owner (e.g. EPCIS owner) may want to register their information with many DSs. This can be a perfectly legitimate way of making the information available in all of the scopes it needs to be instead of assuming that we only register the data once to single fully-connected global network. Furthermore, the publisher can control exactly what it registers which each DS and understand the audience using that DS along with the motivation of the DS.

If we define a standard for the DS interfaces (register,query,potentially peering), then if someone (or collection of people) wants to set up a single global system they can. If this market never emerges and the standard is only used for a collection of smaller systems with ad-hoc peering, then that doesn't have to change the standard.

As you can probably gather aiming for a single global network worries me for two reasons:

- I'm not clear we need it (given that we can register data multiple places under clear control of the publisher)

- Security. On 'local' systems we can just about imagine how to write fine-grained access control policies (we're not going to want the same set of people to see all of our registrations). On a global system we'd have to propagate these policies in addition to the information registrations. All the systems would need to be using the same (federated) security attributes. We'd also need policies to express which DS providers the information could be propagated to as well as the permitted clients. Keep in mind that both the registrations and the security policies are confidential information. The query propagation model suffers similarly as we try to control who can subscribe to different publication scopes/identifiers.

Trevor.

Trevor Burbridge
Principal Researcher
Networks Research Centre | BT Research
Telephone: 01473 645115
Fax: 01473 640929 
Web: http://labs.bt.com/networks/
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British Telecommunications plc which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

---

From: Kary Främling <[email-masked]>
Date: Thu, 10 Jul 2008 17:01:10 +0300

Thank you for making this clear - it looks like the answer I was hoping 
for!

   Kary

---

From: Mark Harrison <[email-masked]>
Date: Thu, 10 Jul 2008 15:02:15 +0100

Dear Ken, ESDS folks,

Ken - thanks for the clarifications regarding identifiers.

Yes, I had intended to say 'a URI or specifically an EPC URI string'  
since URI includes both URNs and URLs.
In practice, all currently defined EPC identifier schemes have URI  
representations (in fact URNs) - although it is conceivable that a URL  
could be used as the identifier (although a URN, Digital Object  
Identifier (DOI) or Handle might be less 'fragile' or more likely to  
be maintained for long-term resolution).

URIs and structured identifiers have the benefit of making it easy to  
express patterns or ranges of related identifiers (e.g. for objects of  
the same product type or issued by the same organization), since  
related URIs often share a common prefix or stem.  The EPCglobal Tag  
Data Standard defines URI patterns for EPC identifiers in which  
wildcard characters  (*) or [lo-hi] ranges indicate which absolute  
URIs should match the specified pattern.

[ Not sure whether this is based on an established convention for URI  
patterns (Ken would know this) - but either the same approach could be  
adopted for non-EPC URI patterns - or regular expressions could be  
used (although it might be trickier to express a multi-digit numeric  
range using a regular expression - see for example http://www.regular-expressions.info/numericranges.html 
  )]

The XSD schema files for the Application Level Events (ALE) and EPC  
Information Services (EPCIS) standards developed by the EPCglobal  
community do not in fact constrain an EPC to be anything other than a  
URI - so it seems quite likely that a future EPCglobal standard for  
Discovery Services would take a similar approach of 'any URI' for EPCs  
or individual IDs.

Using structured identifiers and in particular URIs and URI patterns  
could have advantages in the operations of a Discovery Service, since  
URI patterns could be used as a convenient shorthand for registering  
or querying about multiple IDs that have a common URI prefix and a  
contiguous range of serial numbers.  They could also be helpful for  
any high-level indices that might be used for expressing the scope or  
identifier types / ranges handled by a particular DS.

Regarding ensuring global uniqueness, as Ken pointed out in his  
earlier e-mail, it is possible to prepend a non-URI string with a URI  
prefix in order to qualify its namespace and thereby construct a  
globally unique URI identifier from a combination of one or more  
locally unique identifier strings.

Best regards,

- Mark

On 10 Jul 2008, at 13:41, Kenneth R. Traub wrote:

> object,

---

From: "Kenneth R. Traub" <[email-masked]>
Date: Thu, 10 Jul 2008 11:17:59 -0400

> In practice, all currently defined EPC identifier schemes have URI
representations (in fact URNs) - although it is conceivable that a URL could
be used as the identifier (although a URN, Digital Object Identifier (DOI)
or Handle might be less 'fragile' or more likely to be maintained for
long-term resolution).

If an enterprise wishes to create a private identifier, the HTTP URI scheme
is the easiest to use.  All  the enterprise needs is an Internet domain
name, which of course can be obtained rather inexpensively and easily.
There need not be a web page corresponding to that HTTP URL -- it can just
be used as a unique identifier.

In contrast, it's rather difficult for an enterprise to get URNs for private
use.  Registering a new URN namespace with IANA is a tortuous process, and
may take several years to complete.  It's a little easier to apply for a
Private Enterprise Number (PEN) which may be used with OID URNs of the form
urn:oid:1.3.6.1.4.1....  But these are limited to a numeric (though
hierarchical) structure, and are also somewhat obscure.

So... I would indeed expect to find URLs as identifiers, specifically HTTP
URLs used when a single enterprise or small organization wants to use
private identifiers or otherwise embed an existing numbering system into URI
syntax.

> ... The EPCglobal Tag Data Standard defines URI patterns for EPC
identifiers in which wildcard characters  (*) or [lo-hi] ranges indicate
which absolute URIs should match the specified pattern ... Not sure whether
this is based on an established convention for URI patterns (Ken would know
this) - but either the same approach could be adopted for non-EPC URI
patterns - or regular expressions could be used ...

There is no established convention for URI patterns, to my knowledge.  Of
course, many operating systems have a wildcard syntax for filenames, so it's
easy to imagine URI patterns for the file: URI scheme (though I don't
believe the file: scheme actually defines a pattern syntax).

What we did for EPC was entirely ad hoc.

We purposely avoided a powerful syntax like regular expressions, however,
because that presents considerable implementation difficulty.  It's easy to
create a database schema in which EPC patterns can be searched efficiently
(you add columns for each of the individual EPC components, and then a given
pattern translates into a set of conjoined equality or inequality clauses on
each such column).  It would be quite difficult to do that for regexps,
unless the database had built-in support for regular expressions of equal or
greater expressive power.

> The XSD schema files for the Application Level Events (ALE) and EPC
Information Services (EPCIS) standards developed by the EPCglobal community
do not in fact constrain an EPC to be anything other than a URI - so it
seems quite likely that a future EPCglobal standard for Discovery Services
would take a similar approach of 'any URI' for EPCs or individual IDs.

That's entirely true for EPCIS, and indeed I'm familiar with many EPCIS
deployments that use non-EPC URIs (often HTTP URLs as described above).

The situation for ALE is a little different, because where EPCs appear in
ALE they are initimately tied to reading or writing to an RFID tag.  So the
only URIs that may be used there are ones for which a translation to binary
form is defined in the EPC Tag Data Standard; ie, EPC Tag URIs or EPC "raw"
URIs.

> Using structured identifiers and in particular URIs and URI patterns could
have advantages in the operations of a Discovery Service, since URI patterns
could be used as a convenient shorthand for registering or querying about
multiple IDs that have a common URI prefix and a contiguous range of serial
numbers.  They could also be helpful for any high-level indices that might
be used for expressing the scope or identifier types / ranges handled by a
particular DS.

Again, there is no general definition of "URI patterns".  So any notion of
URI pattern matching would have to be defined on a per-URI scheme basis, or
even on a smaller scope (e.g., urn:epc:id:... defines one pattern syntax,
but urn:foobar:... might define a different one).

> Regarding ensuring global uniqueness, as Ken pointed out in his earlier
e-mail, it is possible to prepend a non-URI string with a URI prefix in
order to qualify its namespace and thereby construct a globally unique URI
identifier from a combination of one or more locally unique identifier
strings.

Though to achieve global uniqueness, one can't just prepend any old URI
prefix.  One has to fit the non-URI string into an established URI scheme
that's properly registered with IANA and any other lower-level registration
authority mandated by that scheme.  As noted before, registering a new URI
scheme or URN namespace is probably only within the reach of an industry
consortium or standards body.  HTTP URIs are the easiest thing for
individual enterprises or small organizations, as the only registration
necessary is the purchase of a domain name.

Ken

---
Ken Traub Consulting LLC
+1 (617) 285-4495
[email-masked]

---

From: "David Potter" <[email-masked]>
Date: Tue, 15 Jul 2008 17:59:03 +0100

Dear ESDS Colleagues,

I have now had time to study and digest Mark's submissions from one week
ago, which I found most interesting, and I would like to make some
high-level observations as follows:

1.  The Trade-offs.xls spreadsheet is very illuminating. For me it speaks
volumes about the potential complexity if the proposed Discovery Services
component is actually responsible for much more than being a directory of
information sources. Is it realistic to expect a "Discovery Service", among
other functions, to handle "end-user" clients, handle standing
subscriptions, and to handle the collection of data from multiple providers
while according appropriate access rights and responding with that data.

2.  I think that there appears to be too much focus on the specifics of
supply chain management and EPCIS. What is the scope of the ESDS initiative?

a.  To create a generic information directory service? 

b.  Or to create a discovery service specifically for EPCIS and its data
scope?

3.  I am uncomfortable with the portrayal of the role of the Discovery
Service as an intermediary, between the Query Clients and the Information
Resources. I think that this intermediary role compromises the real role of
DS by expecting DS to perform many, potentially conflicting, roles as
already mentioned in 1. above. This significantly increases the complexity
of what the DS is supposed to be and also creates much more complex trust
and access relationships. 

4.  I would like to return for a moment to the concept of the "Consolidated
Information Broker", or CIB, that I raised a few weeks back (posting 21st
April 2008). If you replace the Query Client in Mark's models with a
"broker" type function, even one of the "Value-added track & trace
applications & supply-chain management applications" shown on slide 5 of
Mark's Terminology and Scope.ppt, then the relationship between the broker,
the DS and the Information Resources is much more logical. The tasks of
managing the real client requests, standing subscriptions, access and
permissions etc. can then be handled by the "broker"/value-added application
which uses the DS to locate data on behalf of the query clients.

5.  This creates a simpler trust/authentication/access model because query
clients would no longer have direct access to the DS, only well-trusted and
certificated "broker"/value-added applications would be granted such access.
Similarly query clients would have no direct access to the Information
Resources, only the "broker"/value-added applications would have such
access. The risk of information harvesting by "honeypot" resources is more
or less eliminated in this way.

6.  This approach, in my opinion, leaves the DS with a much clearer role. It
has on the one hand only to deal with properly registered and authenticated
Information Resources who are authorised to publish the whereabouts of
information, probably with some strict scope controls to prevent false
information from being published by otherwise legitimate publishers. On the
other hand it responds to queries from properly registered and authenticated
"brokers"/value-added applications.

As Mark hoped, I also hope that these remarks will stimulate still further
lively discussion which will move us towards our eventual goal.

Best regards,

David.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Harrison
Sent: 08 July 2008 11:10
To: [email-masked]
Subject: [ESDS] Interaction models for Discovery Services

Dear ESDS colleagues,

 
http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design
%20Discovery%20Services.pdf

 

have made.

Best regards,

- Mark Harrison

---

From: Mark Harrison <[email-masked]>
Date: Tue, 15 Jul 2008 19:25:35 +0100

Dear David,
Dear ESDS colleagues,

Many thanks for these observations.  I'll include a few responses to  
them inline.

On 15 Jul 2008, at 17:59, David Potter wrote:

> Dear ESDS Colleagues,
> I have now had time to study and digest Mark's submissions from one  
> week ago, which I found most interesting, and I would like to make  
> some high-level observations as follows:

> 1.  The Trade-offs.xls spreadsheet is very illuminating. For me it  
> speaks volumes about the potential complexity if the proposed  
> Discovery Services component is actually responsible for much more  
> than being a directory of information sources. Is it realistic to  
> expect a “Discovery Service”, among other functions, to handle “end- 
> user” clients, handle standing subscriptions, and to handle the  
> collection of data from multiple providers while according  
> appropriate access rights and responding with that data.

The presentation of interaction models considered different kinds of  
intermediaries.
The BRIDGE work considered that the Meta-Resource model would probably  
not be favoured in a supply-chain because companies do not want to  
give up control over their data.  In this sense, I would therefore say  
that it is not the role of a Discovery Service to handle the  
collection of data from multiple providers.  That role of gathering  
information is more for a value-added track-and-trace application or  
'consolidated information broker' than for a DS.

Regarding handling of standing subscriptions, the motivation for this  
is to allow a client to be notified about the existence of other  
organizations or who register at some point in the future that they  
hold information about a particular object (or topic).
In a supply chain context, this could help a manufacturer to identify  
which other companies handle their products after they have left the  
factory gates.
In a citizen-to-citizen context, a citizen might register with a DS  
that they have a photo or a video clip about a particular subject -  
and that they would like to be notified about others who at some point  
in the future also register about the same topic.  In this context, a  
DS is facilitating as a bottom-up mechanism to help with the building  
of a community that shares an interest in a common topic - whether it  
is an individual physical object or some topic of interest.  It's  
somewhat like subscribing to a mailing list on a particular topic.

Without supporting standing queries, a DS can only tell a client about  
those who have registered information about that object or topic in  
the past.  With standing query support, they can also keep the client  
informed about future queries.

Note that this is a different kind of standing query from the kind  
that an individual resource (such as an EPCIS) might support.  In that  
case, the ID and address of the resource is already known to the  
client - and the resource can notify the client directly about new  
additional information that the resource has recently added for that  
ID or topic.

What we are talking about for standing queries in a DS context is  
about helping the client to be notified about new / previously unknown  
resources who register with a DS for the same ID or topic at a future  
time.

On the question of whether a DS handles "end-user" clients, we  
probably need to make a distinction between:
1) an organizational end-user (e.g. an application within a company  
that attempts to query a Discovery Service directly)
2) an individual citizen end-user who attempts to query a Discovery  
Service.

 From the perspective of the EPC Network, the vision is that companies  
should be able to exchange serial-level information directly in a peer- 
to-peer or point-to-point manner without going through a broker or  
intermediate.  This is enabled by having a standardized protocol for  
sharing serial-level information and making queries about it - and  
something which the EPC Information Services (EPCIS) standard attempts  
to provide.  However, before that peer-to-peer communication between  
companies can happen, they need to know how to contact each other.  In  
small-scale pilots or where they have an existing business  
relationship, their addresses will be known to each other.  For global  
deployment and where two companies don't have an existing business  
relationship, Discovery Services can help two companies find each other.
So, my understanding is that in the EPC Network, it would be perfectly  
acceptable for an organizational end-user to query a DS directly, to  
find the address of other organizations holding relevant information  
(subject to their access control policies and whether they are willing  
to identify themselves to the client) and then to directly query the  
information resource for the detailed information.

Regarding individual citizens, it is not clear that they will have  
direct access to supply-chain Discovery Services or product-lifecycle  
Discovery Services, since there may be difficulties in authenticating  
them or making decisions about whether or not to grant them access  
(other than deciding 'no access').

More likely, an individual citizen may be able to make a request for  
traceability information on an individual they are considering buying  
- or on one that they have just bought.  In the pre-purchase scenario,  
a retail store might provide an information kiosk that allows a tagged  
object to be scanned (via serialized barcode or RFID).  The citizen is  
then provided with pre-cached traceability information for that  
individual object.  The cached information was obtained before the  
object was placed on the shelves, using the retailer's credentials to  
authenticate with a Discovery Service and with individual information  
resources, such as EPCIS instances across the supply chain.  In the  
post-purchase scenario, an individual citizen may be able to access  
pre-cached traceability information from the retailer's website or  
from the manufacturer's website.  Again, this cached info was obtained  
using the credentials of either the retailer or manufacturer and the  
access privileges granted to them by the other members of the supply  
chain for that product (which may or may not permit them to reveal  
each organization on the chain to the general public or final end- 
purchasers of the product.)

> 2.  I think that there appears to be too much focus on the specifics  
> of supply chain management and EPCIS. What is the scope of the ESDS  
> initiative?

Kary raised a similar concern.  I did mention that these presentations  
were prepared FOR the EPCglobal Data Discovery Joint Requirements  
Group - so I apologise if they seem rather too EPCIS-centric or too  
focused on supply chains.

When reading through these, the ESDS group should keep in mind the  
broader interpretation and uses of Discovery Services.

Of course you and Kary are both correct, that ESDS can take a broader  
perspective, beyond supply chains to consider entire product  
lifecycles or even completely esoteric or unrelated applications of  
Discovery Services.  Above, I gave the example of Discovery Services  
enabling citizen-to-citizen information discovery in a bottom-up  
approach that is not reliant on the top-down approach of today's  
search engines.  That *could* be a motivation for IETF to consider  
Discovery Services as being an important topic, even if the IETF is  
not so interested in supply chains.

> a.  To create a generic information directory service?

In ESDS, we can keep it quite general purpose.

> b.  Or to create a discovery service specifically for EPCIS and its  
> data scope?

Not specifically for EPCIS.  Of course, the EPCglobal community could  
be a major beneficiary of some of the work that ESDS does - but in  
ESDS we should try to keep it generic, while also considering how to  
make it easily transferable to an EPC Network context.

There are probably some terms in the existing ESDS drafts that are  
still too supply-chain-centric, that don't make sense in a citizen-to- 
citizen use of Discovery Services.  For example business step or  
lifecycle step - but so long as those are optional fields, we can  
probably live with them.

> 3.  I am uncomfortable with the portrayal of the role of the  
> Discovery Service as an intermediary, between the Query Clients and  
> the Information Resources. I think that this intermediary role  
> compromises the real role of DS by expecting DS to perform many,  
> potentially conflicting, roles as already mentioned in 1. above.  
> This significantly increases the complexity of what the DS is  
> supposed to be and also creates much more complex trust and access  
> relationships.

In the presentations, I have tried to indicate for each of the models,  
what data would need to be stored (either temporarily or permanently)  
in a Discovery Service.  If we want to support both a historical  
directory as well as future-looking standing queries, we will normally  
need to use a combination of two models.

Most of the models (with the exception of the Meta Resource model) are  
trying to keep the DS as a lightweight intermediary.  Another point to  
note is that the interaction models described are only about the  
initial step of helping a client to find a resource.  As soon as the  
client knows the address of the resource, it can contact the resource  
directly in a point-to-point manner, without having to interact  
further via a Discovery Service.  Sorry if that was not clear enough  
in the slides.

You are of course correct that the models differ from each other in  
the amount of complex trust and access relationships that they need to  
handle.
However, this is only one aspect of the trade-offs.  The spreadsheet  
was an initial attempt to show a balanced view of (ideally) all the  
trade-offs across the models.

> 4.  I would like to return for a moment to the concept of the  
> “Consolidated Information Broker”, or CIB, that I raised a few weeks  
> back (posting 21st  April 2008). If you replace the Query Client in  
> Mark’s models with a “broker” type function, even one of the “Value- 
> added track & trace applications & supply-chain management  
> applications” shown on slide 5 of Mark’s Terminology and Scope.ppt,  
> then the relationship between the broker, the DS and the Information  
> Resources is much more logical. The tasks of managing the real  
> client requests, standing subscriptions, access and permissions etc.  
> can then be handled by the “broker”/value-added application which  
> uses the DS to locate data on behalf of the query clients.

I suppose a question there is who operates the 'Consolidated  
Information Broker' role.  I can imagine that a company might have  
such an application within their organization, that can interact with  
underlying Discovery Services and Information Resources and insulate  
employees of that company from needing to make queries directly to a  
DS or information resource.

However, a 'Consolidated Information Broker' provided by a third party  
may be trickier to achieve, since an individual company may have  
different access privileges through their own credentials and business  
relationships to what the third party CIB provider has.  There might  
be ways for a company to securely pass-through their credentials to  
the third party, in a way that prevents the third party CIB provider  
from gaining the ability to impersonate the company that provided the  
credentials - but it is probably not straightforward.

> 5.  This creates a simpler trust/authentication/access model because  
> query clients would no longer have direct access to the DS, only  
> well-trusted and certificated “broker”/value-added applications  
> would be granted such access. Similarly query clients would have no  
> direct access to the Information Resources, only the “broker”/value- 
> added applications would have such access. The risk of information  
> harvesting by “honeypot” resources is more or less eliminated in  
> this way.

I think this vision (however valid) is in conflict with the vision for  
the EPC Network, where a client is technically allowed to access a DS  
or information resource directly, without having to go via a broker.   
For the ESDS work to be useful to the EPCglobal community, I think we  
still need to allow for any organization or individual to be  
technically able to query or register information with an ESDS or  
information resource without going via a broker.  Of course, they  
might be denied access or given very restrictive access - but in  
principle, subject to authorization, they can communicate directly.

> 6.  This approach, in my opinion, leaves the DS with a much clearer  
> role. It has on the one hand only to deal with properly registered  
> and authenticated Information Resources who are authorised to  
> publish the whereabouts of information, probably with some strict  
> scope controls to prevent false information from being published by  
> otherwise legitimate publishers. On the other hand it responds to  
> queries from properly registered and authenticated “brokers”/value- 
> added applications.

Although our views may differ somewhat on (5) and (6), I do agree with  
you on the need to support the idea of properly registered clients and  
publishers interacting with a DS.  This may require a client or  
publisher to present a digital security certificate that not only  
asserts who they are - but also that they are a genuine member of a  
particular industry sector or have a licence to operate (in highly  
regulated industry sectors).  This is certainly functionality that  
would be very useful for the design of a Discovery Service to include,  
even though it might only be implemented in Business-to-Business  
Discovery Services and might not always be implemented in Citizen-to- 
Citizen Discovery Services.

In this example, there is perhaps a role for an industry body or  
consortium to play in the certification process, to ensure that only  
bona fide members of the community can connect to a particular  
Discovery Service.

In a Business-to-Citizen context, an example might be a security token  
that is printed on the purchase receipt, which provides the retailer  
or manufacturer with assurance that the client is the purchaser of the  
individual product, rather than a random member of the public.

> As Mark hoped, I also hope that these remarks will stimulate still  
> further lively discussion which will move us towards our eventual  
> goal.
> Best regards,
> David.

Many thanks for this posting.  I hope that the responses above help to  
address some of your concerns and that your comments and my responses  
also help to stimulate further discussion.

Best regards,

- Mark

> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Mark Harrison
> Sent: 08 July 2008 11:10
> To: [email-masked]