Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Local Vs Global Vocabularies
 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@b...] > > "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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
