Fred,
<Fred>Thanks for all info. I'll table it at TBG17.</Fred>
I look forward to hearing the TBG17 thoughts/feedback/decision.
<Fred>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?</Fred>
The UDEF global host will be responsible for establishing memorandums of
agreement with non-profit organizations such TBG17 and other TBGs,
industry associations and professional societies to bring designated
subject matter experts into the approval loop as necessary (based on the
subject matter submitted) and driven by a workflow engine. It is quite
likely that multiple non-profits could have a vote on a given subject. For
example, IEEE, IEC, TBG17 and other major non-profits with subject matter
expertise could be granted a vote in the approval of proposed extensions
that involved the properties (attributes) of electronic components. The
global host would facilitate the review and approval process and then
announce the results to all affected organizations.
<Fred>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?</Fred>
REA has a possible role in helping to understand relationships across
industries but I believe that a better ontology for addressing the basic
semantics that are of primary interest to TBG17 is the UDEF. An OWL/RDF
overlay on UDEF would facilitate mapping between various other ontologies
such as REA.
<Fred>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.</Fred>
Alphabetic searching is the most natural approach that people use when
they don't have other choices - however, if you want a computer to
facilitate the search, a structured ID indexing mechanism based on a
standard ontology is much faster. A structured ID based on a globally
managed ontology is the basis for the Internet IP address allowing one
computer to find another anywhere on the planet. A structured ID approach
(if adopted globally and applied to all repositories and application APIs)
would facilitate finding data anywhere on the planet.
<Fred>Isn't the AFEI rather US-centric?</Fred>
AFEI is US centric but the UDEF was originally created by the global CALS
initiative. The UDEF concept was presented at the International CALS EXPO
93 and included in the published proceedings. AFEI is the non-profit that
organizes the ongoing EXPOs - now under the Enterprise Integration EXPO
moniker. Some countries still hold CALS conferences - for example South
Korea - http://www.kcals.or.kr/english/index.asp
<Fred>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>
At this time, the UDEF ontology is not cast in stone. However, once the
baseline is established and the global host has accomplished the four
major tasks required according to the specification which includes a full
scale pilot, the UDEF ontology will be close to being in stone at that
time. Changing the foundation ontology once organizations start to
implement it would defeat the purpose.
Hopefully, TBG17 will look favorably upon the UDEF concept and the
associated ontology driven structured ID approach. If they concur, then
perhaps they will support a change to the CCTS that representatives of the
aerospace industry suggested a few years ago while the CCTS was in its
earlier draft form. The recommended change would not mandate but simply
allow for a "permanent" structured ID to be assigned rather than the
current "temporary" 6 digit ID.
The current wording in Section 5.3.1 states
"Step 6. Assign a Temporary Identifier to the new item in the form of a 6
digit alphanumeric
string, chosen at the discretion of the user."
The suggested new wording in Section 5.3.1 would state
"Step 6. Assign an identifier to the new item in the form of a
alphanumeric string, chosen at the discretion of the user."
Ron
<<attachment: winmail.dat>>