Ron,
Thanks for all info. I'll table it at TBG17.
<Ron>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?</Ron>
Because more organisations may exist around data structures of electronic
components. But if IEEE is *the* recognised body, it might apply for a
liaison with TBG17.
<Ron>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?</Ron>
Liaisons must widely and internationally represent their industry. And it
is always possible to start a new TBG (at the moment e.g. we are assessing
the options for an agricultural TBG). BTW, what structure do you have in
mind to keep everybody happy?
<Ron>How do semantic conflicts get resolved when the proposed extension by
"submitting expert" transcends multiple domains?</Ron>
That is the task of TBG17, where representatives of all domains meet.
Another instrument imo is to start with an upper ontology that is
generically covering trade relationships across industries. Did you have a
look at REA?
<Ron>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.</Ron>
Every (tree-type) index mechanism has its draw backs. Therefore we'll need
more intelligent registries and look-up mechanisms that include e.g. cross
references. The advantage of the DEN is that it contains the full
structure: both the associations can be reconstructed from it and the
abstractions. So by starting at the top ("thing") you can find all objects
and properties. Alphabetic searching anyway imo is more powerful than
numeric.
<Ron>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.</Ron>
Extensibility is not the problem. A CCTS library is infinitely extensible
as well. Problems arise when the same object type pops up in different
places because of different viewpoints on it. In a true hierarchical
system that can hardly be prevented. CC libraries are lattices rather than
trees, in which that will be easier (but still a hard job).
<Ron>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/<Ron>
Isn't the AFEI rather US-centric?
<Ron>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.</Ron>
I surely think we are on speaking terms. I also hope the ontology is not
cast in stone but allows adaptation when needed (what is the maintenance
procedure?). The TBG17 draft results certainly are still fluid and
debatable.
<Fred>TBG17 will meet F2F after a week. If you can send some more material
and suggestions for cooperation I can table those.</Fred>
<Ron>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>
Thanks. Keep in mind that UN/CEFACT is an organisation of volunteers with
little (in fact no) professional support from the UN.
BTW taking your "animal" as an example: zoologists will build up the
animal tree different from agriculture, transportation or wild-life
control. Conflicts like these will show up all over the place.
Fred
<<attachment: winmail.dat>>