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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Local Vs Global Vocabularies

[ Lists Home | Date Index | Thread Index ]

Thanks Len - all excellent thoughts. Acknowledging that I'm stating the
obvious, ontologies - and cross-ontology reasoning - go a long way in
realizing the approaches that you outline below.

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World

"Bullard, Claude L (Len)" wrote:
> Thanks Joe.  Good conversation as always.
> That's the way to design the language.  The implementation may
> be a bit different.  The trick here is to discern precisely
> in what applications the global language should be used
> and when the local optimized language should be used.  Again,
> it is difficult to change a tire on a moving car in an
> intersection.  The vendor faces the problem that the local
> user has both a culture and a legacy to cope with and so
> does the vendor.  A global industry that does
> not interoperate or share a vocabulary at this time won't
> do it quickly even with incentives, and may not ever (See CALS).
> The systems sold to them have to be efficient locally today.
> That is the usual "rock and a hard place" of the market.
> So the approaches I would consider normal are roughly these:
> 1.  Acknowledge the value of shared vocabularies (the baby
> isn't ugly [1]).  Communities are denoted by the vocabularies they
> share.  Sharing increases over time as opportune (convergence).
> 2.  Apply the shared vocabulary to the right parts of the
> system today.  This can increase over time, but it won't change
> on command but by demand.
> a) Transform into and out of the global vocabulary (up or down)
> for communication services between internal and external agencies.
> Thus, couple loosely.
> b) Use the Data dictionary that defines the global vocabulary as
> a source of bulk-loaded data for things such as code lists.
> c) Where required, use the global vocabulary for archiving where
> the archive has a longer lifecycle than the daily report (for
> short lifecycles, image archiving is typically better).
> This doesn't address the problem of indexing.  Indexing is why
> one usually prefers a highly optimized local vocabulary and
> a shrinkwrap system that can be lightly extended.  Data fields
> can be added to tables by the customer but not code beyond that
> inherited from the GUI control.  So they can search and report on
> these fields, validate them based on base types, but using them
> in extensive cross table relationship validation requiring code
> is not done without additional development costs.
> If high performance based on these optimizations is to be obtained,
> it is likely one does not want to implement the global vocabulary
> as the data dictionary for the local system.  One treats it the way
> the Romans used Aramaic:  learned but spoken as necessary given
> two speakers who recognize the need for it on encounter.
> [1]  The customer and marketing staff barely understand
> formal technical terms, so explaining why they can't have an
> implementation of the global language AND all of their local
> requests and still meet the performance requirements is a non-starter.
> It is painful and they move on to someone who buys them a beer
> and talks sports.  The 'elevator pitch' mentality pervades
> the marketplace.
> len
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> "Bullard, Claude L (Len)" wrote:
> >
> > Possibly but I don't think so.  I get a message from
> > that address about twice a week.  Because of the title,
> > this mail will get one too.  It just doesn't appreciate
> > Monty Python. :-)
> >
> > "Spam Spam Spam Spam"
> >
> > Anywho... better topic.  When designing vocabularies for
> > very large communities, how do youse guys/y'all/anyone
> > approach the dilemma of scale vs localization?
> With a well-thought-out and well-publicized extension methodology that
> provides clear guidance for the local usage of a vocabulary as to how it
> should extend the core vocabulary, and under what circumstances. Also
> how extensions should be fed back to the governance body (there should
> be one!) for consideration for incorporation into the core vocabulary.
> UBL has a nice Working Draft [1] for "Guidelines for the Customization
> of UBL Schemas" that one might find interesting and useful.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS