John F. Sowa wrote:
> Now, let's consider a successful example of interoperability among
> thousands of businesses that use a shared vocabulary with enough
> shared structure to support applications: the Amazon.com database.
>
> Amazon sells a huge number of products, and they could never define
> all of them precisely. So they don't even try. They do have some
> loosely defined product categories (books, electronics, etc.) but they
> let each supplier choose the category labels for their own products.
>
> The suppliers can define their products in any way they please. But
> the only product description that Amazon requires is a character string
> that the Amazon DB stores for each product. But the Amazon system just
> moves that string it around, formats it, and indexes the words in it.
>
> The reason why this method works is that Amazon forces any supplier
> that wants to sell their products to conform to the Amazon conventions
> and database schema. The sellers have to map their data to the Amazon
> categories and abide by Amazon conventions. But the suppliers have
> total control over how they design or describe their own products.
> (01)
Now let us look at an example of exactly the same process that largely
fails. Brokers for contract manufacturing have a weak reference
ontology, aka database schema, in which their manufacturing service
suppliers create their entries. Beyond that the service suppliers are
free to describe their capabilities in any way they choose. When a
customer creates a query requesting services, the query is interpreted
against the database schema, and all of the entries that satisfy it are
returned. In addition, extra keywords that the customer provides are
matched if possible in the text supplied by the suppliers, and the
ordering of the possible suppliers for a customer query is dependent in
part on those matches. (02)
The problem is that customers looking for contract manufacturing
services need very specific capabilities. A thousand firms can turn
parts, but what is needed is the ability to turn parts of a certain
metal alloy and of a specific set of lengths and widths, and often
within a certain tolerance. Trying to find that needle in haystack of
'can turn metal parts' and 'have XYZ machines with a 2-meter bed' (which
the supplier might have mentioned) is not easy. On average, the
customer gets 50+ 'highly ranked' supplier entries, with the first 27
being useless, mostly after determination by phone call. (03)
That is why making a strong ontology for the domain is important. (04)
Two similar efforts in trying to standardize electronics parts catalogs
in the late 20th century failed for two reasons: (1) new parts were
being rapidly introduced, which made maintaining the catalog terms
difficult, and (2) suppliers did not want a standard schema even for
common electronic parts, because the standard presentation would deliver
all of the characteristics with equal font sizes and apparent weight.
Each supplier's website described parts using big fonts for the features
they did well, and appealed to their target markets, and little fonts or
no data for the features they did not value and did not necessarily do
well in. (05)
All of these business-oriented models have the problems of dealing with
the level and kinds of detail that influence decisions in the business,
and the business motivation and emphasis in presenting those details.
And businesses find value in creating noisy contextual vocabularies,
whose explicit purpose is to conceal their commonalities with competing
products and services. You need only to read Porter and the
"value-chain" stuff to see the wide variety of things businesses take to
be their "value". (06)
That is why making a strong ontology for the domain will please no one,
and probably solve few problems. Business want to advertise their
advantages to customers, and they make their market by trading off one
domain of emphasis for another. People only agree to a common ontology
for commodity products, because everyone's advantages there are in terms
of volume, cost and time, and both suppliers and customers want that
market to be open. (07)
-Ed (08)
P.S. My job is to rain on various parades... (09)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (010)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (011)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (012)
|