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: [ubl-comment] Calling for a free, open metadata registry


Whoops, I posted the wrong list!  Hope you find this interesting,
Respectfully,
Todd

To: oagis-users@yahoogroups.com
Subject: Calling for a free, open metadata registry
Cc: 
ebtwg-ccs@lists.ebtwg.org,bl-discussion@lists.commerce.net,xbrl-public@yahoogroups.com


This is an open request to OAG, which I will also post to other e-
business metadata standards organizations.

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, and archive them forever on a read-only basis
with a GUIDs starting from 00000000001.

Provide a free programmatic interface forever thereafter, so that a UID
can be resolved into its meaning.  Become the "Hotmail" of e-business
metadata.

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.

A simple CC has no CoreComponentChildren.  Aggregate CCs have
CoreComponentChildren which may also be Aggregates.  Therefore, entire
business documents may be represented in this registry.

I have worked with this approach and provide sample python code,
documentation, and a sample registry at http://www.arapxml.net. (I am
not an employee of the ARAP Project or its owners, and this message is
my personal opinion. )

At ebTWG Seattle, Feb. 6th, Arofan Gregory argued at length that the
requirement of uniqueness in DictionaryEntryName be dropped, thus
allowing all of the large (incompatible) libraries to be entered into
ebXML registries entirely, without change.  This allows the registry to
be a one-stop mapping and transformation resource.

Transformation today is an expensive, bilateral, custom job -- because
of the N-squared problem, cost of tools, and fundamentally incompatible
visions (ISO 11179/reg.rep's, versus UML/BP, vs XML/XSLT etc.)

This free, public registry could provide a 2nd interface dedicated to
mappings. Thereby, potentially accumulating all of the mappings in the
world, in computable format. Of course you run straight into the
constraints language and numerous patented proprietary mapping systems.
Therefore, best approach is the law of the jungle:  let the best
elements and schemas beat the others to death, in public adoption.

Registry content could be replicated to mirror sites or local caches
since it would be completely static (write-once, read-only).

I think an organization like OAG should start up this server, pay the
money to make it blazing fast, and put in the governance to prevent any
tracing or tracking of accesses of the metadata other than to maintain
usage counts and analytics of data elements for public consideration.

Registry content could be replicated to mirror sites or local caches
since it would be completely static (write-once, read-only). Licensing
of mirror sites might require they report usage metrics to a summary
counter.  So, you may end up with a federation of trusted metadata
registries.

Registry subsets could be published by orders of magnitude: the top 100
elements, the top 1000 elements, top 10000 elements, etc.

Like the NASDAQ your vocabulary gets bumped out of the top 1000 if it's
not being used. Arcane and rarely-used elements and schemas will be
demoted into the 10,000,000 element registry subset where it takes five
seconds to get a UID resolved, and there's no computable mapping.
Meanwhile, ordinary users of the top 1000 will get an element resolved
in microseconds, from their cache in the local PC.

This server will require adequate technical measures to prevent denial
of service attacks, intrusion, or other malicious behaviors.

Within a short period of time, the elements having the best conceptual
definition and shape, would start to see large numbers of users, and
voila:  A de-facto standard based on usage, instead of the decisions of
dominant vendors.

Some further comments, in this ebTWG Core Components message,
http://lists.ebtwg.org/archives/ebtwg/200203/msg00047.html

Just one final note.  The ISO 11179 concept of expert, highly skilled
Registration Authority, is not appropriate to business, because the
financial and political consequences of metadata design decision
predominate.  In contrast to scientific domains, business metadata lacks
any sufficient empirical or expert basis for decisionmaking.

The UN/CEFACT has failed to articulate any objective basis and has a
failure of intellect.  Its vision of central planning and benevolent
philosopher kings ignores markets, and ignores democratic principles.

Its process for populating registries will be politically delegated to
its Domains. It has even provided separate "Contexts" in registries for
duplicative implementations of the same semantic entities by domains.
There is an obvious problem of concentrated benefit and distributed
cost, i.e. the decisions favor participating organizations at the
expense of nonparticipating ones: individuals and small business,
as well as huge segments of the software industry who don't participate.

Todd Boyle CPA  9745-128th Ave NE  Kirkland WA
International Accounting Services, LLC  www.gldialtone.com
tboyle@rosehill.net  425-827-3107    alt.recovery.ebxml



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


Powered by eList eXpress LLC