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


<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>
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.

<Ron>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.</Ron>
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. 

<ron>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.</Ron>
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.  

<ron>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>
TBG17 will meet F2F after a week. If you can send some more material and
suggestions for cooperation I can table those.


<<attachment: winmail.dat>>

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