[
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.
|
