RE: [ebxml-dev] Discovery

["Nieman, Scott" <scott.nieman@synchrocon.com>]

<stn>Smile Mike.  Life is good.

Comments below.

</stn> 

-----Original Message-----
From: Mike Rawlins
To: Nieman, Scott
Cc: 'William J. Kammerer '; 'ebxml-dev '
Sent: 11/27/01 10:32 AM
Subject: Re: [ebxml-dev] Discovery

Can we not discuss this without resorting to more hype, and being a bit
more to
the point?

"Nieman, Scott" wrote <snipped> in response to William Kammerer's note:

> >>   This "discovery" crap sounds like e-marketplace hype which
> >>   only analysts and VC would swallow. If Ford wants to
> >>   "discover" a direct supplier, their own buyers and
> >>   engineers know where to look - they don't need ebXML.
>
> William, your examples are too typical of big business, which are
> unfortunately riddled with point to point integrations.  There are
examples
> that could be placed at a consumer or retail level.  For example, what
if
> William Kammerer wanted to buy a Peruvian sweater, and his Internet
search
> found sweater that he could buy directly from a woman in Peru.
Instead of
> that woman getting 10 cents/ day to make the sweater, she is getting a
> reasonable sum of money directly from you using PayPal.

I think you need a better example, Scott.  The primary focus of ebXML is
B2B, my
application to your application.  Your example is B2C, William sitting
at a
browser to the Peruvian woman's web site.  Try again.

<stn>Ummm, I think I refered to using the ebXML Registry peer community to
find her.  This assumes a client of some nature, so for William this was
P2P.</stn>
>
>
> This has been the vision of UN/CEFACT for ages, to help the emerging
> nations.  If it wasn't for the middleman and big business, we would
not have
> sweatshops.  These thoughts also freak out the e-marketplace vendors.

(CEFACT has been around for ages?  It may seem that way to some of us,
but I
think it has only been about 6 years or so in its current incarnation.)
Sure,
blame it all on middlemen and big businesses.  Just as the poor will
always be
with us, I expect that sweatshops will always be with us.
e-marketplace
vendors are already so freaked out about their low stock prices that I
don't
think any of this bothers them at all.  Can we stay on point?

<stn>What is your point?  My point is that you are limiting the conversation
to ONE audience which is not constructive.

And you're right that CEFACT has not been around for ages, it only seems
that way.  The Open-edi Reference Model also seems like ages too.  As does
BIM.  Each of these groups came to the same conclusion (modeling,
registration, and autoconfigution).  ebXML has as well.  

Having personally built B2B components to several e-marketplaces (btw, one
for the produce industry, and most recently, one for Healthcare Supply Chain
-- of which both were eventually sold), I think they have more worries than
their stock.  They can't get the trading partners connected because
integration is challenging and costly with today's tools.</stn>
>
>
> The vision of the ebXML Registry has been distributed, which means
many
> things:

Yes, the vision has been distributed.  When will the specification
support a
fully distributed registry?

<stn>From what I have read of the OASIS specification changes, I feel that
the specifications are sufficient to support any node on a peer community.
Transport should be viewed as service or adapter to it.</stn>


>
> 1) every web site could have an ebXML registry - ideally part of the
> everyday plumbing (I am happy that apache is taking this on),
> 2) every web site/RA can control its own destiny - creates its own
> classification schemes, link its assets to nodes in other
classification
> schemes, etc etc, to create a "web" of associations

OK, now instead of worrying about dealing with different EDI
implementation
conventions, we're going to have to deal with everyone's different
classification schemes in their registries.  I think we're just moving
the chaos
around a bit, and not fixing it.

<stn>Mike, think you are missing the point, or may not have understood the
specs.  The beauty of nodes in a scheme is that they extend the basic
metadata with associations to node "names", which are tied to an "end" of an
association, (specifically the classification which is a special type of
association).  These node names may appear in a different hierarchical
location in one person's scheme than another's scheme- but the name may be
the same or close.  Therefore most of the searching on a peer node would not
necessarily be on the schemes themselves but the basic metadata and the
lists of associations that reference these node names.  This part of the
ebXML Registry is very stable and uniform.

Another point is that everyone DOES have unique viewpoints.  This is why
TMWG promotes modeling techniques, since from a model we can establish these
views.  I don't care whether that is a relational database view or an OCL
constraint of a class diagram, the concept is the same. People like to slice
and dice information according to their viewpoints; e.g., accountants and
shipping /receiving departments have completely different views of the same
data.

To take that even further, the classification scheme support will likely
evolve to complete models or topic maps.  Anything that is purely
hierarchical (schemes, and many XML Schemas I have seen) has its pitfalls in
that it forces one person's viewpoint and is inflexible.  But again, the
scheme, model or topic map should not the focus of a search.</stn>


>
> 3) distributed technology like peer-to-peer (P2P) popularized by
Napster can
> relay searches to other ebXML Registries in the peer community (the
> distributed part still needs work, as P2P concepts need to be
standardized
> - ideally in XMLP), and each registry can respond directly to the
requestor,

So, ebXML Registry is not going to use the ebXML MHS anymore and will
use the
XMLP???  Yes, I think there's quite a bit of work left to do here.

<stn>Perhaps I am wrong, but I thought the XML Protocol work was looking at
adopting most, if not all of ebXML MHS, and that XMLP was the long term
solution.  I am suggesting here that the XMLP working group also look at the
concepts freely available in Gnutella, or other P2P efforts such as JXTA
(www.jxta.org).  Its good stuff.</stn>
>
> 4) it eliminates the middleman - no brokers, no exchanges (sorry
folks, that
> model will eventually be like the dinosaur)

Technology in and of itself will never eliminate the middleman - ask any
produce
wholesaler.  In fact, some exchanges and brokers have been created by
technology
because technology has made them practical.  Can we focus on some
reasonable
benefits and not wild, unsubstantiated claims?

<stn>Again I refer to my personal experience with a produce exchange.  P2P
would help them significantly as 1) suppliers often buy from each other as
they overcommit inventories all too often and need to buy more from the guy
across the street to fulfill orders (tracability problems or what?), and 2)
they need better means to find produce as it is perishable and needs to move
quickly.  Is this wild or what?</stn>

>
>
> As far as your example, your are correct that these point to point
> relationships exist, but they will exist for a long time.  But if I am
a new
> vendor, and if I can associate my part I manufacture as a
> substitute/alternative to a specific node in an AIAG classification
scheme
> (perhaps by a part number taxonomy), my part MAY come up in a search
if the
> previous manufacturer is continuously late on shipments, and/or has a
poor
> quality record.

Yes, and we have to acknowledge the fact that Ford, Chrysler, and GM use
different part numbering schemes.   It's a very nice vision, but as
always the
devil is in the details.

<stn>Fine.  It was an example.  The use case is valid, which I think you do
agree. </stn> 
>
>
> Discovery IS a good thing.

I fully agree, I just think there are practical limits (read ROI) to
what we can
do with the technology today.

<stn> I am a firm believer that if you can dream it, you can do it.  

I completely understand the issues with legacy integration.  Unfortunately,
most people who integrate are using point to point techniques, and don't
understand the costly, long term effects of doing so.</stn>

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com