[
Lists Home |
Date Index |
Thread Index
]
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.
|
