Issue 15314: Definition of Vocabulary (sbvr-rtf) Source: Business Rule Solutions, LLC (Mr. Ron Ross, rross(at)brsolutions.com) Nature: Uncategorized Issue Severity: Summary: In the course of discussion for Issue 13835 (re: "Fact Model"), I discovered what I believe to be a significant problem with the SBVR definition of "vocabulary" in Clause 11. To avoid complicating that original issue, I aim raising the problem here as a new issue. (Aside: I hope this new issue has not been overtaken by events ... it's been a long time since we've had a convenience document.) Included in this document: · pp. 1-2 Discussion and proposed resolution for the problem with "vocabulary" plus some additional observations about "terminological dictionary". · pp. 3 (for convenience only) Mark's response (08:48 AM 6/28/2010) to my e-mail summarizing a resolution on issue 13835. Mark's response caused me to look closely at the SBVR definitions of "terminological dictionary" and "vocabulary". · pp.4-7 (for convenience only) My original e-mail summarizing a resolution for issue 13835 (06/25/2010 07:54 PM). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DISCUSSION: The current definition of "vocabulary" in SBVR reads as follows: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings As far as I see, the definition says nothing directly or indirectly about *definitions*. This is inconsistent with (a) ISO, (b) MWUD, and (c) How real-world business people think of a "vocabulary". In these important ways, I believe the current SBVR definition is broken and needs to be fixed. (a) ISO says (1087): 3.7.2 vocabulary terminological dictionary (3.7.1) which contains designations (3.4.1) and definitions (3.3.1) from one or more specific subject fields (3.1.2) NOTE The vocabulary may be monolingual, bilingual or multilingual. RGR: Note the "and definitions (3.3.1)". We always based terms on ISO when we can - especially terms from their area of expertise. (b) MWUD says: 1 : a list or collection of words or of words and phrases usually alphabetically arranged and explained or defined; RGR: Note the "and explained or defined". This is the first and most common real-world meaning of "vocabulary". (c) When business hear or say "vocabulary" they don't think simply of a list of words, they think of what the words *mean*. The words are of little use by themselves without definitions. Clause 11, the business-facing side of SBVR, *must* cater to commonly accepted usage of terms in the real-world. PROPOSED RESOLUTION: Change the definition of "vocabulary" in SBVR to be: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings and the definitions for those concepts Also add: Source: based on ISO 1087-1 English (3.7.1) [vocabulary] ~~~~~~~~~~~~~ ADDITIONAL DISCUSSION Re: "terminological dictionary" Here is ISO's definition (expanded) ... 3.7.1 terminological dictionary technical dictionary collection of terminological entries (3.8.2) presenting information related to concepts (3.2.1) or designations (3.4.1) from one or more specific subject fields (3.1.2) 3.8.2 terminological entry part of a terminological data collection (ISO 1087-2:2000, 2.21) which contains the terminological data (3.8.1) related to one concept (3.2.1) NOTE Adapted from ISO 1087-2:2000. 3.8.1 terminological data data related to concepts (3.2.1) or their designations (3.4.1) NOTE The more common terminological data include entry term (3.8.4), definition (3.3.1), note (3.8.5), grammatical label (3.8.6), subject label (3.8.7), language identifier (3.8.8), country identifier (3.8.9) and source identifier (3.8.10). RGR: The bottom line is that for ISO, "terminological dictionary" seems to be simply a more complete, formally organized version of a vocabulary. Both are listed along with other terms under the heading: 3.7 Terminological products. I believe there is no reason not to stick as close as possible to the ISO sense of this term too(?). Otherwise, I question its usefulness for SBVR. At 08:48 AM 6/28/2010, Mark H Linehan wrote: Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com 06/25/2010 07:54 PM To: sbvr-rtf@omg.org From: "Ronald G. Ross" <rross@BRSolutions.com> Subject: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Resolution: Revised Text: Actions taken: June 30, 2000: received issue Discussion: End of Annotations:===== n the course of discussion for Issue 13835 (re: .Fact Model.), I discovered what I believe to be a significant problem with the SBVR definition of .vocabulary. in Clause 11. To avoid complicating that original issue, I aim raising the problem here as a new issue. (Aside: I hope this new issue has not been overtaken by events ... it's been a long time since we've had a convenience document.) Included in this document: · pp. 1-2 Discussion and proposed resolution for the problem with .vocabulary. plus some additional observations about .terminological dictionary.. · pp. 3 (for convenience only) Mark's response (08:48 AM 6/28/2010) to my e-mail summarizing a resolution on issue 13835. Mark.s response caused me to look closely at the SBVR definitions of "terminological dictionary" and "vocabulary". · pp.4-7 (for convenience only) My original e-mail summarizing a resolution for issue 13835 (06/25/2010 07:54 PM). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DISCUSSION: The current definition of "vocabulary" in SBVR reads as follows: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings As far as I see, the definition says nothing directly or indirectly about *definitions*. This is inconsistent with (a) ISO, (b) MWUD, and (c) How real-world business people think of a "vocabulary". In these important ways, I believe the current SBVR definition is broken and needs to be fixed. (a) ISO says (1087): 3.7.2 vocabulary terminological dictionary (3.7.1) which contains designations (3.4.1) and definitions (3.3.1) from one or more specific subject fields (3.1.2) NOTE The vocabulary may be monolingual, bilingual or multilingual. RGR: Note the "and definitions (3.3.1)". We always based terms on ISO when we can - especially terms from their area of expertise. (b) MWUD says: 1 : a list or collection of words or of words and phrases usually alphabetically arranged and explained or defined; RGR: Note the "and explained or defined". This is the first and most common real-world meaning of "vocabulary". (c) When business hear or say "vocabulary" they don't think simply of a list of words, they think of what the words *mean*. The words are of little use by themselves without definitions. Clause 11, the business-facing side of SBVR, *must* cater to commonly accepted usage of terms in the real-world. PROPOSED RESOLUTION: Change the definition of "vocabulary" in SBVR to be: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings and the definitions for those concepts Also add: Source: based on ISO 1087-1 English (3.7.1) [vocabulary] ~~~~~~~~~~~~~ ADDITIONAL DISCUSSION Re: "terminological dictionary" Here is ISO's definition (expanded) ... 3.7.1 terminological dictionary technical dictionary collection of terminological entries (3.8.2) presenting information related to concepts (3.2.1) or designations (3.4.1) from one or more specific subject fields (3.1.2) 3.8.2 terminological entry part of a terminological data collection (ISO 1087-2:2000, 2.21) which contains the terminological data (3.8.1) related to one concept (3.2.1) NOTE Adapted from ISO 1087-2:2000. 3.8.1 terminological data data related to concepts (3.2.1) or their designations (3.4.1) NOTE The more common terminological data include entry term (3.8.4), definition (3.3.1), note (3.8.5), grammatical label (3.8.6), subject label (3.8.7), language identifier (3.8.8), country identifier (3.8.9) and source identifier (3.8.10). RGR: The bottom line is that for ISO, "terminological dictionary" seems to be simply a more complete, formally organized version of a vocabulary. Both are listed along with other terms under the heading: 3.7 Terminological products. I believe there is no reason not to stick as close as possible to the ISO sense of this term too(?). Otherwise, I question its usefulness for SBVR. At 08:48 AM 6/28/2010, Mark H Linehan wrote: Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com 06/25/2010 07:54 PM To: sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). X-Yahoo-Newman-Id: 772075.30363.bm@omp1043.mail.ac4.yahoo.com X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: QjI8xAoVM1l1Fs82qkvkMFsRT1y9meTOXd9808APC61H7v. dohipHTBqcKaX4wNkP7uvTT8h0EZQy2VAd.OCYuCMkgFjy_gO9fvw0Xu1gdA FEyfblrO0K291.kiU22zzOSJqYoXitF_NRUV.6UdPkkHjA9iXswWW1dp1qH0 7jNlk0lExu7T62ayvdkA0RPONNdHjBnu_s8_daw694EdswyHEtf.C97pWTxy Y1TKkHByDgphCIW3FGf5SD35vmmWlp3LZRjAFocM- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Nov 2010 14:28:06 -0500 To: sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: issue 15314 -- SBVR RTF issue All, The revised definition I proposed for "vocabulary" is off-target for several reasons. Putting that aside, let me try again. * A designation is defined in SBVR as: representation of a concept by a sign which denotes it. * So we are not talking merely about a sign, we are talking about a sign *plus* the concept denoted. You have to know the meaning of the concept denoted by a sign; otherwise the sign is just a sign. * The meaning of a concept is given by a definition. To resolve this issue, could we add the following Note to the entry for "vocabulary": Note: Enumerating the designations in a vocabulary is not a matter of listing signifiers, but of associating signifiers with concepts, and a concept can be identified by a definition. From a business-facing point of view, I think it's important that the entry for vocabulary somewhere mention and explain how definitions relate. Ron At 02:48 PM 7/6/2010, Juergen Boldt wrote: Date: Wed, 30 Jun 2010 13:18:34 -0500 To: sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: new SBVR issue - Vocabulary Cc: "Mark H Linehan" , "Juergen Boldt" Juergen, Please post this as a *new* SBVR issue. Title: Definition of Vocabulary All, my apologies if you've gotten this message multiple times. *Terrible* time with e-mail at this hotel. This time I will try putting the discussion in a Word document and see if THAT gets through. Original subject line: New Issue [resend] - Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: Don Baisley To: "Ronald G. Ross" , "sbvr-rtf@omg.org" Subject: RE: issue 15314 -- SBVR RTF issue Thread-Topic: issue 15314 -- SBVR RTF issue Thread-Index: AQHLHUSR4h87UAOz+062avHfmqi8dpNeMKAA//+MyAA= Date: Mon, 1 Nov 2010 19:39:27 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Ron, Your resolution looks good. It adds clarification rather than making a breaking change. Thanks, Don From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Monday, November 01, 2010 12:28 PM To: sbvr-rtf@omg.org Subject: Re: issue 15314 -- SBVR RTF issue All, The revised definition I proposed for "vocabulary" is off-target for several reasons. Putting that aside, let me try again. * A designation is defined in SBVR as: representation of a concept by a sign which denotes it. * So we are not talking merely about a sign, we are talking about a sign *plus* the concept denoted. You have to know the meaning of the concept denoted by a sign; otherwise the sign is just a sign. * The meaning of a concept is given by a definition. To resolve this issue, could we add the following Note to the entry for "vocabulary": Note: Enumerating the designations in a vocabulary is not a matter of listing signifiers, but of associating signifiers with concepts, and a concept can be identified by a definition. >From a business-facing point of view, I think it's important that the entry for vocabulary somewhere mention and explain how definitions relate. Ron At 02:48 PM 7/6/2010, Juergen Boldt wrote: Date: Wed, 30 Jun 2010 13:18:34 -0500 To: sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: new SBVR issue - Vocabulary Cc: "Mark H Linehan" , "Juergen Boldt" Juergen, Please post this as a *new* SBVR issue. Title: Definition of Vocabulary All, my apologies if you've gotten this message multiple times. *Terrible* time with e-mail at this hotel. This time I will try putting the discussion in a Word document and see if THAT gets through. Original subject line: New Issue [resend] - Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org