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>How much lag time is possible between the time an extension is
requested and it gets approved by TBG17? Does the TGB17 Working Group meet
periodically to review proposed extensions or is it an ongoing process? If
they meet periodically, what is the frequency? Are the procedures and
decision criteria published somewhere? Where is the current library of CCs
and BIEs published?</Ron>

<Fred>TBG17 now has telecons every week. As a matter of fact yesterday,
during our mail-conversation we had one. The group is building up its
procedures, by assessing the first (eight?) submissions from industry
groups. As all this stuff is new to everybody we must find the best way by
just doing it. After next week we'll have a full week F2F. We envisage it
is ongoing work and we hope by finetuning the procedures and learning from
people like you who have experience in ontology-engineering in the future
to automize (or at least do an automatical pre-assessment of) most of the
work. Both the draft procedures and the first draft list of CC's have been
published in the UN/CEFACT community. Please contact Alan Stitzer
(Alan.Stitzer@marsh.com) who is leading the project.</Fred>

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? 

IMHO, the task that TGB17 is beginning to undertake will soon require the
support of automation (software and an underlying database) and a solid
ontology and a commitment from neutral third party subject matter experts
in order to populate the library with artifacts that do not conflict with
each other. I also believe that the library needs to have a structured ID
(like a Dewey Decimal ID) or the library will soon become useless due to
its size. 

The UDEF is an approach that could satisfy all of the above requirements -
an ontology that is relatively simple to understand and can be easily
mapped to CCTS, software (that invokes a workflow that ties in to subject
matter experts and provides an initial screening for conflicts) and a
database that helps prevent semantic collisions within the ontology, and a
built-in structured ID that provides an indexing mechanism that computers
can use across the globe. The ID uses a syntax very similar to an IP
address (number.number.number) that computers can handle quite readily and
that can leverage DNS technology to convert the ID to a name or vice
versa.

The UDEF tree structures need to be managed by a global non-profit. At
this point in time, the global non-profit that would take responsibility
for managing the UDEF tree structures has not been selected. Is TGB17
possibly interested in becoming that global non-profit? If so, I will
share the specification that was developed by the aerospace industry that
details the requirements that the global non-profit must do in order to
allow the "library" (global registry) to succeed.

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]