OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [ebxml-dev] ebXML core components derivation by restriction

Fred,

<Ron>If a health and medical organization submits proposed extensions,
does TGB17 intend to consult neutral third party subject matter experts in
the health and medical field who are also knowledgeable of the total
current content in the CCs and BIEs library and therefore will assure all
users that there is no conflict?</Ron>

<Fred>TBG17 only assesses submissions with the submitting expert present.
Unfortunately there is no such thing as a "neutral third party". Therefore
all experts are invited to be represented in their respective TBG domain
group. For Health Care that is TBG10. In the domain group conflicts within
the domain should be resolved before a submission is sent to TBG17.</Fred>

Why can't a non-profit organization such as IEEE be viewed by TBG17 as a
neutral third party comprised of subject matter experts in the field of
properties (attributes) associated with electronic components?

How does TGB17 know that the "submitting expert" is presenting a proposed
extension that has the support of the industry that is seeking the
extension - especially for those domains that currently do not have a TBG?


How do semantic conflicts get resolved when the proposed extension by
"submitting expert" transcends multiple domains? 

<Fred>CCTS has already a mechanism for identifying and qualifying ABIE's,
ASBIE's and BBIE's. I think that is even the most powerful feature of
CCTS. Just by the (ISO 1179 compliant) Dictionary Entry Name the entire
structure of the library can be reconstructed. The DEN functions as your
structured ID. Apart from that there is the purely identifying UID.</Fred>

A Dictionary Entry Name (DEN) has a limited capability as an indexing
mechanism and it is only useful if the user knows the first letter of the
first name. A structured ID that is based on an ontology (such as that
available via the UDEF) is very similar to the ontology-based Dewey
Decimal ID used in libraries to find books.

<Fred>I had a look at your PPT and I wonder how the UDEF ontology has been
constructed. Was it a (standardisation) committee with an open process?
Are you sure the upper ontology is the proper one? Is it sufficiently
extensible? I am sure we can learn a lot from what your group
accomplished, but the view on how the ontology will be used and in what
directions it may be extended needs to be aligned.</Fred>  

The PowerPoint version that you see on the Web site has been replaced by
an XML version that will be made available to the TBD global host. By
design, the UDEF has unlimited extensibility. 

The UDEF was initially developed in an open process within the CALS
initiative in the early 1990s. The oversight non-profit responsible for
UDEF is The Association For Enterprise Integration (AFEI) - see
http://www.afei.org/ 

The UDEF upper ontology for the objects is enterprise centric by design. I
can't say for certain that the upper ontology is the "proper one" but
based on those who have actually applied it, there is growing grass roots
support for the upper ontology. In addition to support within the Supplier
Management Council of the Aerospace Industry Association, others who have
applied it include the Electronics Industry Data Exchange (EIDX) Cross
Reference (XRef) project - see
http://www.eidx.org/guidelines/xref_download.aspx and the EIA-836
Configuration Management Data Exchange and Interoperability standard - see
http://63.249.145.5/836/default.htm

The UDEF upper ontology for the properties is based on Table 8-3 in the
CCTS. Hopefully you will find that to be a suitable match.

<Fred>TBG17 will meet F2F after a week. If you can send some more material
and suggestions for cooperation I can table those.</Fred>

There are four basic categories of responsibilities. They include:

1.	Build a robust on-line Web Service that hosts the UDEF tree
structures.
2.	Build the necessary software that enables the UDEF tree structures
to be expanded as necessary and with support from applicable global
subject matter experts. For example, zoologists would be consulted to
expand the UDEF tree structure under the object "animal." 
3.	Provide both on-line and in-person UDEF training.
4.	Promote the UDEF among the solution providers (major application
and middleware vendors) and the primary end-users (software developers and
application interface developers).

In a private email, I will send you the specification that provides
additional details regarding the performance responsibilities of the
global host in each of the four areas. Perhaps TBG17 would decide to take
responsibility for tasks 1 and 2 and defer tasks 3 and 4 to another global
non-profit.

Ron Schuldt
Senior Staff Systems Architect
Lockheed Martin Enterprise Information Systems
11757 W. Ken Caryl Ave.
#F521 Mail Point DC5694
Littleton, CO 80127
303-977-1414
ron.l.schuldt@lmco.com

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]