RE: [ebxml-dev] RE: OASIS Members to Develop Universal Business Language

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Title: RE: [ebxml-dev] RE: OASIS Members to Develop Universal Business L anguage

Paul:

You make a point about industry-specific vocabularies that is exactly one of the issues that the core component mechanism was designed to address. This is the idea of "context" as used in these specifications.

I will give a simple explanation that can be reviewed in all it's gory detail in the specification to be made available as a draft for comment on the ebTWG.org website soon.

Basically, Core Components are the harmonized low-level data components (some simple, some aggregate) that are used across industries, processes, products, etc. Some message types will be used in many industries, and can usefully be assembled in a fairly generic form from the core components (which is what UBL is attempting to do, for example).

The context mechanism provides a way for each industry or other interest group to specify deviation from core components and standard message types, and to tie that specific deviation to their industry, business process, product, geographical setting, legislative influences, etc.

As a result, you *will* be able to do product- and industry-specific things with core components and the vocabularies based on them. The real difference is that the semantics will remain the same where they can be the same, and where they need to be different, the reasons for their differences will be tightly tied to the exact deviation.

The context mechanism makes this information available to computers, in the registry, so that applications can begin to do things like lower the cost of integration across industry or internatinal boundaries, by detecting the extent and reason for variation in data between industry vocabularies.

One simple example is this:

        A business person goes to look in the repository for what document structure to use. By filling in information about    what business process, what industry, what geographical region, and what products, he will discover exactly what        changes to the generic components and documents other people using the repository saw as necessary to do business in    the same situation. Because it is easier and cheaper to re-use others work than to do a redesign, the busines person    will take what he finds, and use it. Only if something is missing will the businessperson have to go back and create    something new, and only where the gap specifically is. This new work would then become available for that specific      business situation in the repository, for others to discover and re-use.

This is the kind of use scenario that we anticipate.

I hope this begins to explain what we have been trying to build, and why it is no longer a matter of "my industry is different from your industry." There will always be a need for variation in business data - the goal here is to manage those difference to promote interoperability.

Cheers,

Arofan Gregory

-----Original Message-----
From: Paul Horan [mailto:paulh@vcisolutions.com]
Sent: Thursday, October 18, 2001 12:13 PM
To: 'Duane Nickull'
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] RE: OASIS Members to Develop Universal Business
L anguage

Probert, Sue wrote:

> Hi Duane
>
> I guess I speak for the whole ebXML UN/CEFACT core components team in
> stating that it is definitely not in the interests of future e business
> interoperability to talk of encouraging anyone to build their own core
> component library separately from the global effort.
>>>

Agreed.  I think that is also expressed in the document I pointed out
(COre Components Discovery and Analysis).  Use what exists set rather
than developing your own, don't duplicate etc.

However,  there will be situations where people feel it necessary to
build their own (or have already built them) and ebXML does allow and
support that.

Cheers

Duane
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Sue (et. al.),
I don't understand how a "global effort" will be able to build a set of core
components for our industry (Television/Cable Advertising).  We're going to
*have* to do this ourselves and develop our own (unless I misunderstand the
concept of a core component).  Sure, we have RFPs and Purchase Orders and
Contracts and Invoices like somebody that sells toner cartridges, but our
clients are selling "time", and that's definitely apples and oranges.
Now, we want to be ebXML/OASIS-compliant (whatever that means), and as soon
as this all settles down and I can see an example of a working set of
applications that support this standard, I'll have something to model to.

Paul Horan
Sr. Architect
Video Communications Inc.
www.vcisolutions.com

----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>