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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

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


Subject: RE: [ubl-comment] Calling for a free, open metadata registry


Thank you, Mark.

What is the essence that is missed?  I agree, my proposal omits
many things.  I would be very grateful to hear which omitted things
(both within and outside the CCTS) are most essential.

At 04:42 AM 4/2/02, you wrote:

>Todd,
>
>Sorry, I can't agree.  Your proposal misses the essence of the core 
>components, and fails to adequately capture sufficient metadata to ensure 
>BIE's are usable.
>
>Mark
>
> > -----Original Message-----
> > From: Todd Boyle [<mailto:tboyle@rosehill.net>mailto:tboyle@rosehill.net]
> >
> > Please establish a free, Core Components registry service on the net.
> >
> > [ Provide programmatic and manual interfaces that allow any
> > user to upload any elements they need, a free programmatic
> > interface,  that a UID can be resolved into its meaning.  ]
> >
> > The table structure is just an eleven-column table, reflected in the
> > initial library of core components, which has not changed since May
> > 2001. (The Word doc or PDF doc.)
> >
> >     0  String    UID
> >     1  String    DictionaryEntryName
> >     2  String    CCTused
> >     3  String    BasicOrAggregate
> >     4  String    definition
> >     5  String    remarks
> >     6  String    ObjectClass
> >     7  String    PropertyTerm
> >     8  String    RepresentationTerm
> >     9  String    BusinessTerms
> >     10 String    CoreComponentChildren  (comma-delimited list)
> >
> > There is no need for ebXML Context, Constaints Language, or
> > distinction  between a Core Component and Business Entity. [..]

Actually, I regret the choice of words there.  Context and constraints
language are well-designed and meet particular requirements but my basic
point is that these mechanisms do not serve requirements of the
individual or SME but rather, the requirements of Enterprise and their
vendors.   Explicit support of context and constraints too easily allows
disparate vocabularies to continue-- I don't see any sufficient impetus
to converge vocabulary.

Explicit support of context and constraints also, easily results in a
political and economic dividing of territory among "standards
organizations" who publish vocabularies for "domains".  I am seeing that
mechanism already in my domain, which is accounting and the general
ledger.  The D14 is the bureaucracy that will control my vocabulary but
it's not democratic.  It is a top-down autocracy, its activities are
not transparent, and I don't like their designs.

Their decisions have real economic impacts. They favor one
class of user over another.  That does not bode well for adoption.

Rather than suggest intricate changes in governance of UN/CEFACT,
I call on the community to design a technological platform that
allows the interests of users to be quantitatively registered, in
a systematic way, and to start this discussion, I proposed the
open flat registry.

We need direct voting democracy, not a hegemony by self-appointed,
unelected representatives at the UN/CEFACT.  Core Components should
reflect the interests of the human population of the planet, or at least,
its actual weighting of computer users, instead of its largest
corporations and their IT suppliers who can afford to travel to
world capitals at frequent intervals, and the enormous mental effort
and commitment to engage all the issues across domains.

In consideration of the importance of large corporations and vendors,
they may be accorded quantitative weights.  But those weights should be
consciously decided, and their exercise should be transparent. I see
great danger in neglectfully allowing control by the UN/CEFACT permanent
working groups.

These comments are not aimed at any particular individual or
organization but what I see as inevitable, systematic phenomena
in any centrally-controlled economic planning,

Thank you for your patience,

Todd Boyle CPA



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


Powered by eList eXpress LLC