Issue 17244: Keyword "another" (sbvr-rtf) Source: KnowGravity Inc. (Mr. Markus Schacher, markus.schacher(at)knowgravity.com) Nature: Enhancement Severity: Minor Summary: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another <person3>" refers to <person1> and/or <person2>: It is prohibited that a <person1> <is married to> <person2>, if that <person1> <is married to> another <person3>. Resolution: Revised Text: Actions taken: March 17, 2012: received issue Discussion: End of Annotations:===== m: webmaster@omg.org To: Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Subject: RE: issue 17244 -- SBVR RTF issue Date: Thu, 29 Mar 2012 08:34:24 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 17244 -- SBVR RTF issue Thread-Index: Ac0Nv3D0v7vrookpQoW+W7PHTGTqDAAAHaRw From: "Pete Rivett" To: More generally, is it implicit that is different from ? http://weeklyworldnews.com/headlines/45466/bride-marries-herself/ Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, March 29, 2012 8:20 AM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 17244 -- SBVR RTF issue From: webmaster@omg.org Date: 17 Mar 2012 06:17:29 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org X-Yahoo-Newman-Id: 793050.80282.bm@omp1007.access.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1333041879; bh=8i9Es9YqL9jgBN5/1HG9GfLMWCZJrMi/tDuH0errNf8=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:In-Reply-To:References:Mime-Version:Content-Type; b=P1ei4o3QT9fGjP4LnynPopT0M7FT0x9X+ncsM4nVtQm9Yt2SRl1IG5WiBegGE9yuNMNMcMPjczvIHSahJGfRroc7rPpV5DGSqTsumMYWLFLCg5fOvsN0QPgULNVlXQtqB78HcfZPGDRq3UmRsF/Ns3ownvpjE+3wlqnmX/kPeJk= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mwbIlmIVM1l1OBWTWRrviRmHWvGgsMXwOcqQ0C_Nhf8f6eY LU1La6MAcZV5HKwx.w4uOTVhe9wpxEv5aNpGok3tOXeQ4UVAzHzx.tJL.Ca4 kN9gVwJoYX8O_L3M.gc3yZAMHbJasyabrGhM8GOllAdMivuivuoEpoO8cPBX NSyZtfu2KOOC8ufA08o8rANIBT7rzUb5QifN0pRdtPf4VRShoD66iWRcmceG 4_dTxqOvnocuRKaq9g3kLsCyxyz55TvUa.eqt_MUCmn9CtuSdEi9d08OChz4 PGyqeSc4rzSy0Qy_qu9WUlkXJ3GLyzZadQuLpvfGmm48Te7Bff0grCfC5ly2 sx7bwyKqnVHhy4s57uJRhc2eJ..auJsIrxTQETZY9_thH84yU3_G1wZfx0QL v03JXASfgncF90c8jcCsOKQBoRlvoM5JTvNTO9Bqlo7xVCieLtgwvMOzGGZ. 5dTKwJIsiTxi4Zjyc45wXZghMnfjrreEyrphHvvYTi.9khiuE47T2ZzTBb8U BYb0tO3Yc_fjhWf2dBPl_NKYr3bjXYYmV4CTMW38j83bdMmJ5DOPKC_PqVUv HLzcHy2EAQn.vIp1JZHPzjr90hNwcBuiOHvtvi0GFBgGitW67_lXZ_nfmUPH wtqud9rbKE3uAhrTJ8fwVTYLyurEP.4yM1NNVFYB93fx4HL1JoZw0qqKgpYG Ixa7cde6lOXR.QjLe3vN7fgPtEAJsRIjutm9oS.3j1zSR2_404cC1aDlXyOC XogVbxM5C X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Mar 2012 12:24:25 -0500 To: Juergen Boldt , issues@omg.org, sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org Date: 17 Mar 2012 06:17:29 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info From: Markus Schacher To: "Ronald G. Ross" CC: "sbvr-rtf@omg.org" Subject: RE: issue 17244 [and issue 17243] -- SBVR RTF issue Thread-Topic: issue 17244 [and issue 17243] -- SBVR RTF issue Thread-Index: AQHNDdEC6wXltiJq10G0527lSRp/PZaCSk5w Date: Fri, 30 Mar 2012 05:37:33 +0000 Accept-Language: de-CH, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.60.249.28] Ron, Yes, my issue is strictly limited to SBVR-SE. However, it shows that we have fundamentally different expectations on languages like SBVR-SE. I know, you mentioned those concerns some time ago. I always believed (and still do) that in SBVR languages such as SBVR-SE (as well as RuleSpeak?) should be used to construct precise representations of underlying meanings. In other words: that there must be a .one to many.-association between a .meaning. and its .representation(s).. You propose that this association should be .many to many., i.e. that a representation is intentionally ambiguous in order to make it human comprehensible. This is not a problem per se, as long as you have an authoring tool as you describe it (and I assume you have it) or as long as human common sense is sufficient (and sufficiently common) to resolve any potential ambiguity. I believe that this is not always guaranteed: Many .rule texts. only come as their representation either on paper or as a PDF or Word document. If these rule texts are about a less common topic, common sense may fail and no disambiguation tool is available to resolve potential ambiguities . it.s up to the reader. Particularly in the context of law texts, this is what lawyers earn their living from. And for most of its readers, even SBVR only comes as a document represented in SBVR-SE written in Microsoft Word or Framemaker and read as a PDF file. This is where what consultants earn their living from. Best regards, Markus From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: Donnerstag, 29. Mä 2012 19:24 To: Juergen Boldt; issues@omg.org; sbvr-rtf@omg.org Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org Date: 17 Mar 2012 06:17:29 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info X-Yahoo-Newman-Id: 873013.90409.bm@omp1010.access.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1333117712; bh=mqqV0s3cXrKvof/gw2jt5kbbvxHGcM9mvzJA5KiR7z0=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:Content-Transfer-Encoding; b=gFrcztwUMImYDtjqTMYuXzJ3pr5UGtiqUr1WBchQcIajp9aX8nUGZECBJjSrdCvsWhNAKkUGwbgvfcYKT44hxgTbP3K8PyrozKJUB/7lV6KT1P9JtAYHjY7ig/G8zcZMB3+IeDltcH3z+kDBnp0yve4NyrYX1pbrQU+WqezcIXs= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9LFCKL8VM1mZ1xr7yayu01pUJOxhcMNi2N2R81oZNyUCkHB HgmEbIx_Cgl1OZOKq8Dp_RZMH4ahdvm53jxbwATX6H3GvnjmZ1kazZqCPRxN LmKjWN39QL_bVLsfcsTjAX2L13SU4XPSinMoLeQsWqOI1aoJfaN7i8bIaXem SKA.qJypbVgZYhRJgpotkI_7earg2J7FMFb0FWKqmKNweFDdbtbLEInwglLu OeKcAN9mrE3sOX.qoejs2V3T3fggv1qhrXIc3NV5KGhSv.FwiLKwxVX7Xxtc 0yURciLLVA6ZLYrRc2d_MGGnS8gTlwgwteWhyy_KBFnKgrSTbUEujFkzCR1E hupRBUmoZcuss.oR6vKrdWlCUaREeyFoDFUyER.V4v99YJ7739MY12TOSM6D 2OSjplDOPuYqOZOUC9sGkk31lKdTRBzaY6gvPBj1F65VC1z.ULXdS_ZUrExp g0gfuTQ7_cxWbDslLZuz0efFQ3PaZo4ZzaBscH1cjjzGQZz7cid32t05DGYR OzskDczYuaPrDlfnsVUXLoQjIcaHiymnouidl6Y1H6eKtjKG35X8BzeaNRN0 nEobuCLT1mSLzOFdaYjoPAucCsgLA6UaQyJPwLvDGkcr89t.ePICVCAXoKQ0 cMtqB19NMMkfJG3Y1j.xXy1Hn3.3BcNH6gLu1LrqADN9KCDs- X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 Mar 2012 08:58:02 -0500 To: Markus Schacher From: "Ronald G. Ross" Subject: RE: issue 17244 [and issue 17243] -- SBVR RTF issue Cc: "sbvr-rtf@omg.org" At 12:37 AM 3/30/2012, Markus Schacher wrote: Ron, Yes, my issue is strictly limited to SBVR-SE. However, it shows that we have fundamentally different expectations on languages like SBVR-SE. I know, you mentioned those concerns some time ago. I always believed (and still do) that in SBVR languages such as SBVR-SE (as well as RuleSpeak?) should be used to construct precise representations of underlying meanings. In other words: that there must be a .one to many.-association between a .meaning. and its .representation(s).. You propose that this association should be .many to many., i.e. that a representation is intentionally ambiguous in order to make it human comprehensible. --> Not sure exactly what you mean by "many-to-many" and "intentionally". But here is what I am saying. 1. Any meanings communicated between machines has to be 100% unambiguous (even if the disambiguation is based on defaults ... always well documented of course). I think we all agree on that point. 2. All meanings must be based on some expression, so for SBVR there must be *some* language (SBVR-SE) whose interpretation is completely unambiguous. I think we all agree on that point too. 3. However, the disambiguation can be achieved by documented assumptions rather than syntax. (But since I don't think SBVR-SE is the key to mass consumption of SBVR, for me it doesn't matter too much how it is done ... except that many people might be misled into thinking SBVR-SE is the only way to 'use' SBVR.) I don't know whether everyone agrees on this point. 4. The mass market for SBVR cannot be taught a syntax-precise 'natural' language (which is really an oxymoron anyway) to use SBVR tools. Not the average business person. Not the average business analyst. As far as I know, I have more hands-on experience trying to teach people to be as precise as possible in writing business rules than anyone, and I can tell you, general use of a syntax-precise 'natural' language is simply not going to happen. Lawyers are taught precision for multiple years ... and today, even what they write is not directly automatable (nor 'natural' language in many respects). 5. The world does not need another programming language even if it looks like natural language in many respects. This is not a problem per se, as long as you have an authoring tool as you describe it (and I assume you have it) or as long as human common sense is sufficient (and sufficiently common) to resolve any potential ambiguity. I believe that this is not always guaranteed: Many .rule texts. only come as their representation either on paper or as a PDF or Word document. If these rule texts are about a less common topic, common sense may fail and no disambiguation tool is available to resolve potential ambiguities . it.s up to the reader. --> We expect everyone (who is authorized) to know their vocabulary. Many vocabularies are not well-known to the public. That issue is not in question. Particularly in the context of law texts, this is what lawyers earn their living from. And for most of its readers, even SBVR only comes as a document represented in SBVR-SE written in Microsoft Word or Framemaker and read as a PDF file. This is where what consultants earn their living from. --> SBVR is not going to fly (economically) if the large majority of businesses have to hire consultants to use it. Either companies are too small to have budgets for that, or they have existing IT staffs who control budgets and will generally fight it tooth and nail (because their vested interests are threatened). We should really be giving more thought to what it will take to gain *acceptance* of SBVR. (Something else I have said many times.) We can pretend that the technical development and market acceptance of SBVR are separable issues ... but they are not ... and this discussion of syntax and ambiguity demonstrates it. SBVR is probably unique in all OMG offerings in that regard. (Thanks for providing the opportunity to bring up the matter. It really does need to play a role in the team's dialog.) Ron Best regards, Markus From: Ronald G. Ross [ mailto:rross@brsolutions.com] Sent: Donnerstag, 29. Mä 2012 19:24 To: Juergen Boldt; issues@omg.org; sbvr-rtf@omg.org Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org Date: 17 Mar 2012 06:17:29 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Date: Fri, 30 Mar 2012 12:49:09 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Markus Schacher CC: "sbvr-rtf@omg.org" Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: q2UGnFqK015121 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1333730958.75652@QtkW/NqE/9oSbYmLMnQ9gQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov I support Markus on this. If SBVR SE is not intended to be unambiguously interpreted into LRMV formulations, then we should not have written the definitions and rules in the SBVR and DTV standards in SBVR SE. What the real users of SBVR, such as they are, take from the standard is the vocabulary structures (based on examples in the standard) and SBVR SE as a formulation language. They didn't need SBVR to assist them in writing somewhat ambiguous English. There were already lots of books. The standard provides by example a vocabulary structure, vocabulary concepts, and a readable and apparently unambiguous language for expressing intent. What most troubles me is not that the standard is weakly defined in exactly those areas, but rather that the majority of the RTF seems not to understand that that is where the value is. -Ed Markus Schacher wrote: Ron, Yes, my issue is strictly limited to SBVR-SE. However, it shows that we have fundamentally different expectations on languages like SBVR-SE. I know, you mentioned those concerns some time ago. I always believed (and still do) that in SBVR languages such as SBVR-SE (as well as RuleSpeak?) should be used to construct precise representations of underlying meanings. In other words: that there must be a .one to many.-association between a .meaning. and its .representation(s).. You propose that this association should be .many to many., i.e. that a representation is intentionally ambiguous in order to make it human comprehensible. This is not a problem per se, as long as you have an authoring tool as you describe it (and I assume you have it) or as long as human common sense is sufficient (and sufficiently common) to resolve any potential ambiguity. I believe that this is not always guaranteed: Many .rule texts. only come as their representation either on paper or as a PDF or Word document. If these rule texts are about a less common topic, common sense may fail and no disambiguation tool is available to resolve potential ambiguities ­ it.s up to the reader. Particularly in the context of law texts, this is what lawyers earn their living from. And for most of its readers, even SBVR only comes as a document represented in SBVR-SE written in Microsoft Word or Framemaker and read as a PDF file. This is where what consultants earn their living from. Best regards, Markus *From:* Ronald G. Ross [mailto:rross@brsolutions.com] *Sent:* Donnerstag, 29. Mä 2012 19:24 *To:* Juergen Boldt; issues@omg.org; sbvr-rtf@omg.org *Subject:* Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org Date: 17 Mar 2012 06:17:29 -0500 To: > Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Yahoo-Newman-Id: 14461.39305.bm@omp1020.access.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1333296642; bh=YaXjFaDSNM+WiK2iLqOsQE6vQ0kIPa4qGrPncf/gbAA=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:Content-Transfer-Encoding; b=hyTVmHjYKIK0/7+A0nqGnRhfHj8uD3dSpNssdlVIvMFtcN+LqDPCW5twOEJwPAqKw59eeoAY3uGL+ET1xmg2Pxbu4uKI+ZPElV8iNyKfK03ZaBCkvOmyZ3MhoJFTRGEbDUJ0YOSEaOZFU6LJEDfyV8GZ34T647aXxUSB/AmiNpQ= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: p2nsjdAVM1monGc_FX6IXEcmYe4LqYZRDOKljoFJVIUqDo. b3BUSSTrOZmsMLUeRGTD0pyv2vMZs5Mijp1EH_st9G4vuh.qrS8TsiufRCUe dd7Rk3sWWUvZnMFELRkDw.gqdlctZo__KcRIrXhme4mS4fgEBLl.351HBPcg o_dNeTNwI15G8hEzVpHcRSCvY6pgItK7f_eAUi.C3zgAXmgFdOIhP4u7mbwV 0Nr9VZXmJX.1zl7eFQszgu2ZO2VfnEdBFlkagy_cLOMEF1F8UsIeh1fMLqhl aV905cPUnUo3unxHaV8vz7KLIspDzhWU4asNe_JIjfINug7af6usqz.JwBxc 4DdqkzbA9zMdVsGM_h9AsdLR6eYNzWWIUPPGJ9GDp.tkrgb27f4Tz5IUXOGe _pWFanuJpmVPUZvz0SUa7mvQ5KD.7bYMVQphREtgGYFnnXBdL0bV5mTDc8QG IvbRqoHJ1c8HDe.AemZVkk2knTzOs4YjhHUweY5NuoQq.wbQM_mxkzie_80u X4iB3tKtnWsH06q7mLcJKLKHLeM1ioBO4bOLpDubaBbnnNVTDrgR.3OdAr9X vvtxZiSeITjaU6fzg372sMYp1L7KrS0AvuWDEIiHdu7WmALYkovtocCzUYSB 6i4OPvC7VyBs- X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 01 Apr 2012 11:10:29 -0500 To: edbark@nist.gov, Markus Schacher From: "Ronald G. Ross" Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue Cc: "sbvr-rtf@omg.org" At 11:49 AM 3/30/2012, Ed Barkmeyer wrote: I support Markus on this. If SBVR SE is not intended to be unambiguously interpreted into LRMV formulations, then we should not have written the definitions and rules in the SBVR and DTV standards in SBVR SE. --> I have no problem with SBVR-SE being (or becoming) a language that can be 'unambiguously interpreted into LRMV formulations'. (We don't use it anyway.) My point is that SBVR is (and always has been) intended to support a far wider audience than will (or could) ever write in SBVR-SE per se. What the real users of SBVR, such as they are, take from the standard is the vocabulary structures (based on examples in the standard) and SBVR SE as a formulation language. They didn't need SBVR to assist them in writing somewhat ambiguous English. There were already lots of books. The standard provides by example a vocabulary structure, vocabulary concepts, and a readable and apparently unambiguous language for expressing intent. What most troubles me is not that the standard is weakly defined in exactly those areas, but rather that the majority of the RTF seems not to understand that that is where the value is. --> Ed, I should invite you onto to some of our engagements as an observer. I feel quite certain the experience would broaden your thinking about where the value and potential of SBVR really lies. Or it would shake your confidence about the skill level of the vast majority of business people and business workers in the real world. Or *both* ... and that has always been the raison d'etre for SBVR. Ron -Ed Markus Schacher wrote: Ron, Yes, my issue is strictly limited to SBVR-SE. However, it shows that we have fundamentally different expectations on languages like SBVR-SE. I know, you mentioned those concerns some time ago. I always believed (and still do) that in SBVR languages such as SBVR-SE (as well as RuleSpeak?) should be used to construct precise representations of underlying meanings. In other words: that there must be a .one to many.-association between a .meaning. and its .representation(s).. You propose that this association should be .many to many., i.e. that a representation is intentionally ambiguous in order to make it human comprehensible. This is not a problem per se, as long as you have an authoring tool as you describe it (and I assume you have it) or as long as human common sense is sufficient (and sufficiently common) to resolve any potential ambiguity. I believe that this is not always guaranteed: Many .rule texts. only come as their representation either on paper or as a PDF or Word document. If these rule texts are about a less common topic, common sense may fail and no disambiguation tool is available to resolve potential ambiguities ­ it.s up to the reader. Particularly in the context of law texts, this is what lawyers earn their living from. And for most of its readers, even SBVR only comes as a document represented in SBVR-SE written in Microsoft Word or Framemaker and read as a PDF file. This is where what consultants earn their living from. Best regards, Markus *From:* Ronald G. Ross [ mailto:rross@brsolutions.com] *Sent:* Donnerstag, 29. Mä 2012 19:24 *To:* Juergen Boldt; issues@omg.org; sbvr-rtf@omg.org *Subject:* Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org < mailto:webmaster@omg.org> Date: 17 Mar 2012 06:17:29 -0500 To: > Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com < mailto:markus.schacher@knowgravity.com> Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] < http://www.omg.org/signature.htm> < http://www.omg.org/signature.htm> [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ < http://www.ronross.info/blog/> http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png < https://twitter.com/Ronald_G_Ross> *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info < http://www.ronross.info/> -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Date: Mon, 02 Apr 2012 20:01:34 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Ronald G. Ross" CC: "sbvr-rtf@omg.org" Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov Ron. Ross wrote: --> I have no problem with SBVR-SE being (or becoming) a language that can be 'unambiguously interpreted into LRMV formulations'. (We don't use it anyway.) NIST doesn't use it, either. Unfortunately, the SBVR specification does. Also, many people are looking for an English-like language in which to phrase unambiguous business rules and definitions, and they are taking SBVR SE as a 'standard language' for that purpose. The particular problem we have is that DTV definitions and rules are written in that language, as if it were the SBVR standard. At this writing, we have only MRV representations of DTV; we don't have standard LRMV representations of the DTV definitions and rules, and we only believe that the SBVR SE text will produce the intended 'semantic formulations'. My point is that SBVR is (and always has been) intended to support a far wider audience than will (or could) ever write in SBVR-SE per se. Which, you will forgive me, is irrelevant to the issue. Given only MRV implementations, whatever language people write rules in will be exchanged verbatim and only may be interpretable by a receiving tool. In most cases, it will probably just be displayed to humans verbatim. DTV is written in SBVR SE, and its definitions are supposed to have a standard interpretation, as distinct from the 'annotation text' in OWL or the 'ownedComments' in UML, both of which are perfectly capable of capturing noun concepts, verb concepts, and definitions in natural languages. I wrote: The standard provides by example a vocabulary structure, vocabulary concepts, and a readable and apparently unambiguous language for expressing intent. What most troubles me is not that the standard is weakly defined in exactly those areas, but rather that the majority of the RTF seems not to understand that that is where the value is. Ron wrote: --> Ed, I should invite you onto to some of our engagements as an observer. I feel quite certain the experience would broaden your thinking about where the value and potential of SBVR really lies. I can't imagine how. No one on the other side of the table in your engagements is part of the audience for SBVR. The audience for SBVR is the people on your side of the table -- the people who know in general that they need to capture the business concepts and rules carefully, and need a model and tools to help them do that. What we see in the manufacturing world is a collection of business people and manufacturing engineers -- the other side of the table -- who need to be able to read the definitions and rules as captured by the analyst using whatever tool, and to verify that those definitions and rules are consistent with their (the business persons') intent. They also need to be sure that those captured rules and definitions are faithfully translated to the languages of whatever software engines they entrust part of their business operations to. They can't know that, but they might believe smart tools could do that, and their results will be at least consistent, by comparison with the programmer of the week. Now, in 2008-9, working with the Automotive Industry Action Group, we looked for commercial or academic tooling that actually does these two tasks: - capture and display terms, definitions and business rules in a "business-friendly" language - translate that language faithfully into a formal representation that can be used by "machine reasoning tools" to support the business operations Our concern was to validate incoming information from partners, suppliers and distributors, for completeness, meaningfulness, and consistency, using the formalized definitions and business rules to drive the testing. That was why I supported SBVR in the first place. By 2010, we found no such tools. Unisys RulesModeler had disappeared from the market, and there was no competitor. There are several tools that manage terms, definitions, and rules somehow or other, but most of them export SKOS, if anything, and none of them export anything useful for logical reasoning. So I gave up and wrote my own. There was no particular reason to input SBVR SE, because it is not a standard and the only tools that capture it depend on the markup and don't export even MRV. So, where is the audience for SBVR? It seems to be primarily a textbook for postgraduates trying to learn how to capture vocabularies and rules, and an occasional resource for business analysts trying to learn still more from the BRG about how to do what many of you do. That has its value, to be sure, but all of the value is to people on your side of the table. I consider myself to be a computer scientist and a rusty computational linguist who happens to have some experience in sitting on your side of the table on and off over the last 40 years. I can't do what you do nearly as well as you can, but I do know what you do, and I know that all of the value in SBVR is on your side of the table. It will become indirectly valuable to the other side -- the real business people -- if and when tooling is built that lets people with your expertise capture what the business people are trying to say in a way they can understand, and that can spit that out in a standard form that can be used by tools that analyze and implement those rules. Now, the tooling will be valuable if the form in which you capture business intent and display it to business people is standardized, which SBVR does not do, or if it can spit out the business intent in any formally complete standard form, so that other tools can do the analysis and conversion to automated implementation. SBVR defines the standard form, but no one implements it. So when either the standard grammar for a business friendly language is defined, or tools are built to export an unambiguous standard form for vocabulary, definitions and rules, the value will be realized. And SBVR will play some role in that, if and only if it happens to be the standard form the actual tools use. Or it would shake your confidence about the skill level of the vast majority of business people and business workers in the real world. Or *both* ... and that has always been the raison d'etre for SBVR. The vast majority of "business people", like the vast majority of any profession are, as my wife says, like auto mechanics. 20% of them are highly skilled and knowledgeable and can solve real problems. 60% of them are good enough at what they do to perform normal duties and operations without making many mistakes. The remaining 20% are what gives the profession a bad name. I have seen a fairly broad spectrum. It would probably not shake my confidence in the skills of business people. I might move the distribution percentages a bit. I fail to see how the skills of business persons are relevant to SBVR. I do understand that the variance in skills of business persons might be why there is little value to a standard "business friendly" language for writing definitions and rules. But if that is the case, why is SBVR written in such a language? It seems to me that the intent of SBVR SE is to make the definitions and rules readable to educated business analysts and consultants -- your side of the table. I have had the pleasure of working with several very gifted business analysts and consultants, some of whom are on this exploder, and it seems to me that they, and more to the point, the 60% of their profession that is capable if not gifted, are the primary audience for SBVR as written. But it is the toolsmiths who support them for whom the standard is usefully normative. -Ed Ron -Ed Markus Schacher wrote: Ron, Yes, my issue is strictly limited to SBVR-SE. However, it shows that we have fundamentally different expectations on languages like SBVR-SE. I know, you mentioned those concerns some time ago. I always believed (and still do) that in SBVR languages such as SBVR-SE (as well as RuleSpeak?) should be used to construct precise representations of underlying meanings. In other words: that there must be a .one to many.-association between a .meaning. and its .representation(s).. You propose that this association should be .many to many., i.e. that a representation is intentionally ambiguous in order to make it human comprehensible. This is not a problem per se, as long as you have an authoring tool as you describe it (and I assume you have it) or as long as human common sense is sufficient (and sufficiently common) to resolve any potential ambiguity. I believe that this is not always guaranteed: Many .rule texts. only come as their representation either on paper or as a PDF or Word document. If these rule texts are about a less common topic, common sense may fail and no disambiguation tool is available to resolve potential ambiguities ­ it.s up to the reader. Particularly in the context of law texts, this is what lawyers earn their living from. And for most of its readers, even SBVR only comes as a document represented in SBVR-SE written in Microsoft Word or Framemaker and read as a PDF file. This is where what consultants earn their living from. Best regards, Markus *From:* Ronald G. Ross [ mailto:rross@brsolutions.com] *Sent:* Donnerstag, 29. Mä 2012 19:24 *To:* Juergen Boldt; issues@omg.org; sbvr-rtf@omg.org *Subject:* Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org < mailto:webmaster@omg.org> Date: 17 Mar 2012 06:17:29 -0500 To: > Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com < mailto:markus.schacher@knowgravity.com> Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] < http://www.omg.org/signature.htm> < http://www.omg.org/signature.htm> [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ < http://www.ronross.info/blog/> http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png < https://twitter.com/Ronald_G_Ross> *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info < http://www.ronross.info/> -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Yahoo-Newman-Id: 204573.7559.bm@omp1003.access.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1333419067; bh=Nfvg2pbj3U0qgVa80nKSr5Bm+n6AHE612WZYIZjLRmc=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:Content-Transfer-Encoding; b=qxpGFJ7WLpmzZCicmiuLx1Tjl3uHqTqiQX9NxsLgQRCNIKV+IozxkwpDEJih8sHSTF+LJnKZtPZT6Y+Z+yVCf9hZmVafZVi9KKPL17W7m87Jnmoig9m32dLsAvrXdv/CTVmV57yAdKDEr5OklLAmeL4cRc9KHA8KYX+IN8ocgQI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NFsT3FgVM1m0_c4pFrNt78AcXSvF2N1l4_jsKo3fCK4aKHv BmClxzODTtXjzhX2x8AOSwM1Bs6qnzlh.3Yawe1QQ4x2_rPHdsZFDYdx3brB FnwfUowbJ6cym7LzIDjzRL6yopdhduB2kJIx8YbHdAKyN5p8o4T4MMXFzXJK yGiYQEf6BAOMS7XjiZy85UtFrCTwn1AAaBOd2OF.C4FzggfvQc2AWy8L83Nj 7J5q2YAYyaD6QmOJmvOW6HCqT8Tj2IygfIiTshnYHozimjjDKFbVHDlTifEh GaL.LNT6jiau7Scn475afd_s9.bURLXb1L5iBqGmWRy49uVlhAPJqt0xsovZ ZrL4B2D.aRLRMRBEHGOHfxQdoUKoKaR2pWAS8Pm4qMOn5Ge8aOoy4hTnf8e4 9h7kkiFoYOi654JpnR6CDbg88vA6nkTWAzUfu1DAhuJloNplt4jW3glElErz e3V7xUd53uxMUrbcOQvpK6a4J_T6TSUoIFsBdaSGd9566T0b4YoPQLuhmpWw EgIgaYdpdWISxQdTX3hBFc3YUZ68QTDt_INNMx3_cISgx3fdpYNs3rbxmesH HY7ZsIfwHl2ABKVn2IS0CvTXLDxdtz7fIVCi1YmQCRgZurQXJpiGzrSo7HOZ TV1ZZaah5zLoqWIuJmDIPz4Yb3IlisqE_dru5QSGZd0PeEQ-- X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Apr 2012 21:10:50 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue Cc: "sbvr-rtf@omg.org" Ed, My intent was not to lecture ... pardon me if it seemed I was doing so ... but rather to keep a focus on the original intent of SBVR, which remains valid ... even more so ... today. In some of the discussions it sure seems like there is a bit of purpose-drift. In any case, I remain vigilant for real-world business rules that SBVR-SE can't adequately handle. John Hall provided some excellent thinking about the examples recently being discussed. I think my point is this. Beyond a certain point (let's take John Hall's latest examples as a sample benchmark), humans are allowed to apply certain common-sense assumptions in interpreting the intended meaning of well-expressed business rules. I think tools might be allowed to do so too, as long as (a) they document the assumptions (which is something the tool should do for its own humans anyway), and (b) communicate the assumptions to other machines. However, at the level of John Hall's sample benchmark, I'm not even sure such common-sense assumptions need to be ... or even could be ... documented. But if so, why bend SBVR-SE itself out of shape to express them? The problem I'm having is the striving for a 100% solution, when the world could benefit hugely today from a 95% (99.9%?) solution. Ron At 07:01 PM 4/2/2012, Edward Barkmeyer wrote: Ron. Ross wrote: --> I have no problem with SBVR-SE being (or becoming) a language that can be 'unambiguously interpreted into LRMV formulations'. (We don't use it anyway.) NIST doesn't use it, either. Unfortunately, the SBVR specification does. Also, many people are looking for an English-like language in which to phrase unambiguous business rules and definitions, and they are taking SBVR SE as a 'standard language' for that purpose. The particular problem we have is that DTV definitions and rules are written in that language, as if it were the SBVR standard. At this writing, we have only MRV representations of DTV; we don't have standard LRMV representations of the DTV definitions and rules, and we only believe that the SBVR SE text will produce the intended 'semantic formulations'. My point is that SBVR is (and always has been) intended to support a far wider audience than will (or could) ever write in SBVR-SE per se. Which, you will forgive me, is irrelevant to the issue. Given only MRV implementations, whatever language people write rules in will be exchanged verbatim and only may be interpretable by a receiving tool. In most cases, it will probably just be displayed to humans verbatim. DTV is written in SBVR SE, and its definitions are supposed to have a standard interpretation, as distinct from the 'annotation text' in OWL or the 'ownedComments' in UML, both of which are perfectly capable of capturing noun concepts, verb concepts, and definitions in natural languages. I wrote: The standard provides by example a vocabulary structure, vocabulary concepts, and a readable and apparently unambiguous language for expressing intent. What most troubles me is not that the standard is weakly defined in exactly those areas, but rather that the majority of the RTF seems not to understand that that is where the value is. Ron wrote: --> Ed, I should invite you onto to some of our engagements as an observer. I feel quite certain the experience would broaden your thinking about where the value and potential of SBVR really lies. I can't imagine how. No one on the other side of the table in your engagements is part of the audience for SBVR. The audience for SBVR is the people on your side of the table -- the people who know in general that they need to capture the business concepts and rules carefully, and need a model and tools to help them do that. What we see in the manufacturing world is a collection of business people and manufacturing engineers -- the other side of the table -- who need to be able to read the definitions and rules as captured by the analyst using whatever tool, and to verify that those definitions and rules are consistent with their (the business persons') intent. They also need to be sure that those captured rules and definitions are faithfully translated to the languages of whatever software engines they entrust part of their business operations to. They can't know that, but they might believe smart tools could do that, and their results will be at least consistent, by comparison with the programmer of the week. Now, in 2008-9, working with the Automotive Industry Action Group, we looked for commercial or academic tooling that actually does these two tasks: - capture and display terms, definitions and business rules in a "business-friendly" language - translate that language faithfully into a formal representation that can be used by "machine reasoning tools" to support the business operations Our concern was to validate incoming information from partners, suppliers and distributors, for completeness, meaningfulness, and consistency, using the formalized definitions and business rules to drive the testing. That was why I supported SBVR in the first place. By 2010, we found no such tools. Unisys RulesModeler had disappeared from the market, and there was no competitor. There are several tools that manage terms, definitions, and rules somehow or other, but most of them export SKOS, if anything, and none of them export anything useful for logical reasoning. So I gave up and wrote my own. There was no particular reason to input SBVR SE, because it is not a standard and the only tools that capture it depend on the markup and don't export even MRV. So, where is the audience for SBVR? It seems to be primarily a textbook for postgraduates trying to learn how to capture vocabularies and rules, and an occasional resource for business analysts trying to learn still more from the BRG about how to do what many of you do. That has its value, to be sure, but all of the value is to people on your side of the table. I consider myself to be a computer scientist and a rusty computational linguist who happens to have some experience in sitting on your side of the table on and off over the last 40 years. I can't do what you do nearly as well as you can, but I do know what you do, and I know that all of the value in SBVR is on your side of the table. It will become indirectly valuable to the other side -- the real business people -- if and when tooling is built that lets people with your expertise capture what the business people are trying to say in a way they can understand, and that can spit that out in a standard form that can be used by tools that analyze and implement those rules. Now, the tooling will be valuable if the form in which you capture business intent and display it to business people is standardized, which SBVR does not do, or if it can spit out the business intent in any formally complete standard form, so that other tools can do the analysis and conversion to automated implementation. SBVR defines the standard form, but no one implements it. So when either the standard grammar for a business friendly language is defined, or tools are built to export an unambiguous standard form for vocabulary, definitions and rules, the value will be realized. And SBVR will play some role in that, if and only if it happens to be the standard form the actual tools use. Or it would shake your confidence about the skill level of the vast majority of business people and business workers in the real world. Or *both* ... and that has always been the raison d'etre for SBVR. The vast majority of "business people", like the vast majority of any profession are, as my wife says, like auto mechanics. 20% of them are highly skilled and knowledgeable and can solve real problems. 60% of them are good enough at what they do to perform normal duties and operations without making many mistakes. The remaining 20% are what gives the profession a bad name. I have seen a fairly broad spectrum. It would probably not shake my confidence in the skills of business people. I might move the distribution percentages a bit. I fail to see how the skills of business persons are relevant to SBVR. I do understand that the variance in skills of business persons might be why there is little value to a standard "business friendly" language for writing definitions and rules. But if that is the case, why is SBVR written in such a language? It seems to me that the intent of SBVR SE is to make the definitions and rules readable to educated business analysts and consultants -- your side of the table. I have had the pleasure of working with several very gifted business analysts and consultants, some of whom are on this exploder, and it seems to me that they, and more to the point, the 60% of their profession that is capable if not gifted, are the primary audience for SBVR as written. But it is the toolsmiths who support them for whom the standard is usefully normative. -Ed Ron -Ed Markus Schacher wrote: Ron, Yes, my issue is strictly limited to SBVR-SE. However, it shows that we have fundamentally different expectations on languages like SBVR-SE. I know, you mentioned those concerns some time ago. I always believed (and still do) that in SBVR languages such as SBVR-SE (as well as RuleSpeak?) should be used to construct precise representations of underlying meanings. In other words: that there must be a .one to many.-association between a .meaning. and its .representation(s).. You propose that this association should be .many to many., i.e. that a representation is intentionally ambiguous in order to make it human comprehensible. This is not a problem per se, as long as you have an authoring tool as you describe it (and I assume you have it) or as long as human common sense is sufficient (and sufficiently common) to resolve any potential ambiguity. I believe that this is not always guaranteed: Many .rule texts. only come as their representation either on paper or as a PDF or Word document. If these rule texts are about a less common topic, common sense may fail and no disambiguation tool is available to resolve potential ambiguities ­ it.s up to the reader. Particularly in the context of law texts, this is what lawyers earn their living from. And for most of its readers, even SBVR only comes as a document represented in SBVR-SE written in Microsoft Word or Framemaker and read as a PDF file. This is where what consultants earn their living from. Best regards, Markus *From:* Ronald G. Ross [ mailto:rross@brsolutions.com] *Sent:* Donnerstag, 29. Mä 2012 19:24 *To:* Juergen Boldt; issues@omg.org; sbvr-rtf@omg.org *Subject:* Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org < mailto:webmaster@omg.org> Date: 17 Mar 2012 06:17:29 -0500 To: > Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com < mailto:markus.schacher@knowgravity.com> Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] < http://www.omg.org/signature.htm> < http://www.omg.org/signature.htm> [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ < http://www.ronross.info/blog/> http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png < https://twitter.com/Ronald_G_Ross> *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info < http://www.ronross.info/> -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Date: Tue, 03 Apr 2012 13:32:09 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Ronald G. Ross" CC: "sbvr-rtf@omg.org" Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov Ronald G. Ross wrote: Ed, My intent was not to lecture ... pardon me if it seemed I was doing so ... Well, I apologize. I think my email was a lecture. (I'm not sure. I should never write emails at 8 p.m.) but rather to keep a focus on the original intent of SBVR, which remains valid ... even more so ... today. In some of the discussions it sure seems like there is a bit of purpose-drift. I have never understood the 'original intent', or whether it was simply perverted by the diverse interests of the proposal team. I am trying to guess the intent of the product, based on my perception of its effective place in a panoply of software tools that capture human knowledge in some way that is supposed to assist human endeavours. And whatever the original intent was, the product is a dog's breakfast. It is a demonstration that the several submitters had no common intent. How does what SBVR actually standardizes relate to its intent? Or to its organization? And what is the role of SBVR SE in fulfilling that intent? Why does it exist? In any case, I remain vigilant for real-world business rules that SBVR-SE can't adequately handle. John Hall provided some excellent thinking about the examples recently being discussed. I think my point is this. Beyond a certain point (let's take John Hall's latest examples as a sample benchmark), humans are allowed to apply certain common-sense assumptions in interpreting the intended meaning of well-expressed business rules. I think tools might be allowed to do so too, as long as (a) they document the assumptions (which is something the tool should do for its own humans anyway), and (b) communicate the assumptions to other machines. But you don' t need a standard for a tool. You need a standard for one or both of the things it communicates with: humans and other tools. If the other tools are going to do nothing more than present the same material to different humans, then you have to document your assumptions and pass them along. But if all you are assuming is human common sense, then all you are expecting from the partner tool is that it will present to humans who have the same common sense. There is no value to the LRMV. The problem we run into is not common sense, but different viewpoints -- humans who misunderstand because they don't see the world the same way. So you have to document the context in which the 'common sense' is being deployed. However, at the level of John Hall's sample benchmark, I'm not even sure such common-sense assumptions need to be ... or even could be ... documented. But if so, why bend SBVR-SE itself out of shape to express them? So, not all business definitions and rules can be written in SBVR SE. Sure. All that the issue asks is that SBVR be clear that it doesn't assign any interpretation to tense and aspect and mood in SBVR SE statements, and if that interpretation is important to the meaning of the definition or rule, then the text should be unstyled, because it requires natural language interpretation. The problem I'm having is the striving for a 100% solution, when the world could benefit hugely today from a 95% (99.9%?) solution. I fully understand that, and I agree. But I don't know what problem SBVR is the 95% solution to. Based on the existing set of would-be SBVR implementations, I assume that the only real intent of SBVR is to provide for the exchange of business vocabularies, with definitions and rules in natural language, or in each tool's favorite approximation to natural language, and to allow those vocabularies to be sorted out into all the exciting subcategories of terms in clause 11, some of which are useful. If that is the intent, I don't see the value of writing the standard in a pseudo-formal language that is weakly defined and not standardized. Which 95% solution is that language part of? And why should DTV be written in that form, thus lending further credibility to the apparently erroneous idea that SBVR SE is the form of text representation defined by the SBVR standard? SBVR does not standardize a language that humans can read, nor does SBVR in fact /define/ (in any of the established ways) any such language. (For example, SBVR SE does not have a metamodel.) Therefore, no human-readable element of a standard can be "written in SBVR", and the DTV lies when it makes that claim! SBVR SE does not have to be a 100% solution to anything. It has to be either well-defined or deprecated. We must either make SBVR SE a well-defined formal language that we do expect people to use, or stop promulgating the fiction that it plays any useful role in SBVR or in OMG. The cost of writing definitions and rules in a complex non-language is not justifiable. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 Ron At 07:01 PM 4/2/2012, Edward Barkmeyer wrote: Ron. Ross wrote: --> I have no problem with SBVR-SE being (or becoming) a language that can be 'unambiguously interpreted into LRMV formulations'. (We don't use it anyway.) NIST doesn't use it, either. Unfortunately, the SBVR specification does. Also, many people are looking for an English-like language in which to phrase unambiguous business rules and definitions, and they are taking SBVR SE as a 'standard language' for that purpose. The particular problem we have is that DTV definitions and rules are written in that language, as if it were the SBVR standard. At this writing, we have only MRV representations of DTV; we don't have standard LRMV representations of the DTV definitions and rules, and we only believe that the SBVR SE text will produce the intended 'semantic formulations'. My point is that SBVR is (and always has been) intended to support a far wider audience than will (or could) ever write in SBVR-SE per se. Which, you will forgive me, is irrelevant to the issue. Given only MRV implementations, whatever language people write rules in will be exchanged verbatim and only may be interpretable by a receiving tool. In most cases, it will probably just be displayed to humans verbatim. DTV is written in SBVR SE, and its definitions are supposed to have a standard interpretation, as distinct from the 'annotation text' in OWL or the 'ownedComments' in UML, both of which are perfectly capable of capturing noun concepts, verb concepts, and definitions in natural languages. I wrote: The standard provides by example a vocabulary structure, vocabulary concepts, and a readable and apparently unambiguous language for expressing intent. What most troubles me is not that the standard is weakly defined in exactly those areas, but rather that the majority of the RTF seems not to understand that that is where the value is. Ron wrote: --> Ed, I should invite you onto to some of our engagements as an observer. I feel quite certain the experience would broaden your thinking about where the value and potential of SBVR really lies. I can't imagine how. No one on the other side of the table in your engagements is part of the audience for SBVR. The audience for SBVR is the people on your side of the table -- the people who know in general that they need to capture the business concepts and rules carefully, and need a model and tools to help them do that. What we see in the manufacturing world is a collection of business people and manufacturing engineers -- the other side of the table -- who need to be able to read the definitions and rules as captured by the analyst using whatever tool, and to verify that those definitions and rules are consistent with their (the business persons') intent. They also need to be sure that those captured rules and definitions are faithfully translated to the languages of whatever software engines they entrust part of their business operations to. They can't know that, but they might believe smart tools could do that, and their results will be at least consistent, by comparison with the programmer of the week. Now, in 2008-9, working with the Automotive Industry Action Group, we looked for commercial or academic tooling that actually does these two tasks: - capture and display terms, definitions and business rules in a "business-friendly" language - translate that language faithfully into a formal representation that can be used by "machine reasoning tools" to support the business operations Our concern was to validate incoming information from partners, suppliers and distributors, for completeness, meaningfulness, and consistency, using the formalized definitions and business rules to drive the testing. That was why I supported SBVR in the first place. By 2010, we found no such tools. Unisys RulesModeler had disappeared from the market, and there was no competitor. There are several tools that manage terms, definitions, and rules somehow or other, but most of them export SKOS, if anything, and none of them export anything useful for logical reasoning. So I gave up and wrote my own. There was no particular reason to input SBVR SE, because it is not a standard and the only tools that capture it depend on the markup and don't export even MRV. So, where is the audience for SBVR? It seems to be primarily a textbook for postgraduates trying to learn how to capture vocabularies and rules, and an occasional resource for business analysts trying to learn still more from the BRG about how to do what many of you do. That has its value, to be sure, but all of the value is to people on your side of the table. I consider myself to be a computer scientist and a rusty computational linguist who happens to have some experience in sitting on your side of the table on and off over the last 40 years. I can't do what you do nearly as well as you can, but I do know what you do, and I know that all of the value in SBVR is on your side of the table. It will become indirectly valuable to the other side -- the real business people -- if and when tooling is built that lets people with your expertise capture what the business people are trying to say in a way they can understand, and that can spit that out in a standard form that can be used by tools that analyze and implement those rules. Now, the tooling will be valuable if the form in which you capture business intent and display it to business people is standardized, which SBVR does not do, or if it can spit out the business intent in any formally complete standard form, so that other tools can do the analysis and conversion to automated implementation. SBVR defines the standard form, but no one implements it. So when either the standard grammar for a business friendly language is defined, or tools are built to export an unambiguous standard form for vocabulary, definitions and rules, the value will be realized. And SBVR will play some role in that, if and only if it happens to be the standard form the actual tools use. Or it would shake your confidence about the skill level of the vast majority of business people and business workers in the real world. Or *both* ... and that has always been the raison d'etre for SBVR. The vast majority of "business people", like the vast majority of any profession are, as my wife says, like auto mechanics. 20% of them are highly skilled and knowledgeable and can solve real problems. 60% of them are good enough at what they do to perform normal duties and operations without making many mistakes. The remaining 20% are what gives the profession a bad name. I have seen a fairly broad spectrum. It would probably not shake my confidence in the skills of business people. I might move the distribution percentages a bit. I fail to see how the skills of business persons are relevant to SBVR. I do understand that the variance in skills of business persons might be why there is little value to a standard "business friendly" language for writing definitions and rules. But if that is the case, why is SBVR written in such a language? It seems to me that the intent of SBVR SE is to make the definitions and rules readable to educated business analysts and consultants -- your side of the table. I have had the pleasure of working with several very gifted business analysts and consultants, some of whom are on this exploder, and it seems to me that they, and more to the point, the 60% of their profession that is capable if not gifted, are the primary audience for SBVR as written. But it is the toolsmiths who support them for whom the standard is usefully normative. -Ed Ron -Ed Markus Schacher wrote: Ron, Yes, my issue is strictly limited to SBVR-SE. However, it shows that we have fundamentally different expectations on languages like SBVR-SE. I know, you mentioned those concerns some time ago. I always believed (and still do) that in SBVR languages such as SBVR-SE (as well as RuleSpeak?) should be used to construct precise representations of underlying meanings. In other words: that there must be a .one to many.-association between a .meaning. and its .representation(s).. You propose that this association should be .many to many., i.e. that a representation is intentionally ambiguous in order to make it human comprehensible. This is not a problem per se, as long as you have an authoring tool as you describe it (and I assume you have it) or as long as human common sense is sufficient (and sufficiently common) to resolve any potential ambiguity. I believe that this is not always guaranteed: Many .rule texts. only come as their representation either on paper or as a PDF or Word document. If these rule texts are about a less common topic, common sense may fail and no disambiguation tool is available to resolve potential ambiguities ­ it.s up to the reader. Particularly in the context of law texts, this is what lawyers earn their living from. And for most of its readers, even SBVR only comes as a document represented in SBVR-SE written in Microsoft Word or Framemaker and read as a PDF file. This is where what consultants earn their living from. Best regards, Markus *From:* Ronald G. Ross [ mailto:rross@brsolutions.com] *Sent:* Donnerstag, 29. Mä 2012 19:24 *To:* Juergen Boldt; issues@omg.org ; sbvr-rtf@omg.org *Subject:* Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org < mailto:webmaster@omg.org> Date: 17 Mar 2012 06:17:29 -0500 To: < mailto:issues@omg.org >> Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com < mailto:markus.schacher@knowgravity.com> Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org > [] < http://www.omg.org/signature.htm> < http://www.omg.org/signature.htm> [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ < http://www.ronross.info/blog/> http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png < https://twitter.com/Ronald_G_Ross> *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info < http://www.ronross.info/> -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info X-Yahoo-Newman-Id: 985592.48642.bm@omp1018.access.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1333498387; bh=6iExNpSSmo9u02bOR2IGslHBrL4KyXAjZb6vLl7I08o=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:Content-Transfer-Encoding; b=s0Ah8+R5FyEcRyVo8eORMxwu7p8m7GKn6COseCB9ePn11iD1hXVl8Jd7EnPNNqxi6/ZTQhNZkYfqZT0bwOqDeLKcZFGNIfiL4rjrf4hpTl67qVQnDQ33roht23Lwy1WGXESbn3S8FeEM5O/I+022WW8HrXwhhSkhAWCWTN+8egY= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: OZl2xisVM1nTMox_grn3yqwns154mg_3Nhv.leZVl2o0KpN IjPac_YteElrlDpb3cy4GMgSuS0zoZtiocCOEafFMb5OX1Yk5JNqVSHSGdDh f2UGdaSBrH.3wT3qXe92rbA8ZOrN8sWAMvJuKm6owG1f76pUBGhc244Rbo9S Sk7BxHglC7BM7BOlw02iiPztY8PdPbokEROVMxb6P55OUnQR42Rb3qvFsW7z D4DRL4gS5Hk6A4I6cgSlJBkF0bDOHDDENOJD6qSLsGedaNPHO1fNVUQQefob 8m18hDIYUnfyi3mQc5yXmdFqZcAylQ05uYjwSrbUXRsW.bAtFhM0kw1Fg1LG FTmiRX6wAGuEyxQFtky2FUb_02yaKwJ8kxVOjzs626usnl2nB4KJznPbJeHe eQGr1GJpqvMgQy.k- X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Apr 2012 19:12:50 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 17244 [and issue 17243] -- SBVR RTF issue Cc: "sbvr-rtf@omg.org" Ed, Some replies like this ... Ron At 12:32 PM 4/3/2012, Edward Barkmeyer wrote: Ronald G. Ross wrote: Ed, My intent was not to lecture ... pardon me if it seemed I was doing so ... Well, I apologize. I think my email was a lecture. (I'm not sure. I should never write emails at 8 p.m.) but rather to keep a focus on the original intent of SBVR, which remains valid ... even more so ... today. In some of the discussions it sure seems like there is a bit of purpose-drift. I have never understood the 'original intent', or whether it was simply perverted by the diverse interests of the proposal team. I am trying to guess the intent of the product, based on my perception of its effective place in a panoply of software tools that capture human knowledge in some way that is supposed to assist human endeavours. --> I frankly have no idea why you say that. The original intent was (and is) quite clear. Its purpose was (and is) to permit business people to express meanings (primarily definitions and business rules) unambiguously in natural language, structured and delineated, but as close to what they would normally use for more formal business communication as possible. And to bypass 'programming' in the process. If there is any doubt as to this original and current intent, we can take a poll of the original cast of SBVR to verify it. My money is that we will all agree. Why would you think differently?? By the way, the purpose of SBVR was never (and still isn't) to enable natural language verbalizations of data models, executable rules, data, etc. But my feeling is that we are all in agreement on that point(?). And whatever the original intent was, the product is a dog's breakfast. It is a demonstration that the several submitters had no common intent. I know all the original submitters pretty well, and I have no idea why you say that. There was a difference in understanding about fact models vs. concept models. But we have now sorted that out. There was a difference in opinion about definitional rules, but that was sorted out long ago. I don't believe anyone had any significant sense that RulesModeler was off-target, a telling fact in itself. In all honesty, I just can't make out what you are talking about. How does what SBVR actually standardizes relate to its intent? Or to its organization? And what is the role of SBVR SE in fulfilling that intent? Why does it exist? Because to organize a standard about meanings, you have to have words to talk about it. But everything about SBVR-SE is about establishing a precise vocabulary so that business vocabularies and rulebooks can be specified. That positioning is absolutely 100% self-consistent and the only way possible to address the bootstrap problem of defining semantics without resorting to formal computer-science style expression. It's elegant. And it does the same for tool builders and machines in clauses 8 and part of 10. Actually, we've had this conversation time and time again. I keep telling you that the SBVR business vocabulary (especially clause 11 & 12) is for both people and for machines, so they can 'speak' a common language (share concepts). And every time I say it, your reaction is that what SBVR standardizes has nothing to do with people. Well, speaking as one of the original submitters, that's simply not the case. That perhaps makes SBVR unique among OMG standards and computer science approaches, but isn't that the very question you're asking? In any case, I remain vigilant for real-world business rules that SBVR-SE can't adequately handle. John Hall provided some excellent thinking about the examples recently being discussed. I think my point is this. Beyond a certain point (let's take John Hall's latest examples as a sample benchmark), humans are allowed to apply certain common-sense assumptions in interpreting the intended meaning of well-expressed business rules. I think tools might be allowed to do so too, as long as (a) they document the assumptions (which is something the tool should do for its own humans anyway), and (b) communicate the assumptions to other machines. --> Let me repeat my challenge. Show me some real-world definitions or business rules that SBVR-SE can't handle, then adjustments should be discussed. But first the examples please. I'm not saying they don't exist. I'm just saying I've looked at a great number, and I haven't seen any yet. But you don' t need a standard for a tool. You need a standard for one or both of the things it communicates with: humans and other tools. If the other tools are going to do nothing more than present the same material to different humans, then you have to document your assumptions and pass them along. But if all you are assuming is human common sense, then all you are expecting from the partner tool is that it will present to humans who have the same common sense. There is no value to the LRMV. --> Sorry, I fail to understand your point. Even if the definitions and business rules weren't going to be communicated with any other tool or person, they need to be semantically digested to identify logical anomalies. There are no tools around today that can do that comprehensively, and it's a huge problem (opportunity) in the marketplace. It's a very real problem that traditional programming languages et al have never really addressed. The problem we run into is not common sense, but different viewpoints -- humans who misunderstand because they don't see the world the same way. So you have to document the context in which the 'common sense' is being deployed. --> If there are different assumptions for whatever reason, they need to be captured, validated, documented and communicated. However, at the level of John Hall's sample benchmark, I'm not even sure such common-sense assumptions need to be ... or even could be ... documented. But if so, why bend SBVR-SE itself out of shape to express them? So, not all business definitions and rules can be written in SBVR SE. Sure. --> No, I never said that. Again, my challenge: Show me a real-world definition or business rule that SBVR-SE can't handle. What I said was that even for well-expressed meanings (at the John Hall threshold) there *might* be common-sense assumptions that would be safe 99.9% of the time that you might want to document. But there is no need or reason to turn SBVR-SE into something that it was never intended to be to support those. All that the issue asks is that SBVR be clear that it doesn't assign any interpretation to tense and aspect and mood in SBVR SE statements, and if that interpretation is important to the meaning of the definition or rule, then the text should be unstyled, because it requires natural language interpretation. --> Let's see examples of real-world definitions and business rules please. The problem I'm having is the striving for a 100% solution, when the world could benefit hugely today from a 95% (99.9%?) solution. I fully understand that, and I agree. But I don't know what problem SBVR is the 95% solution to. --> Well Ed I invited you to come as a silent observer on some of our projects (subject to a Gladys veto, of course), but you maintain you are well-exposed to the 'other side of the table' so doing that would not be useful to you. I'm beginning to think we must live in different universes. Based on the existing set of would-be SBVR implementations, I assume that the only real intent of SBVR is to provide for the exchange of business vocabularies, with definitions and rules in natural language, or in each tool's favorite approximation to natural language, and to allow those vocabularies to be sorted out into all the exciting subcategories of terms in clause 11, some of which are useful. --> Ed, in all honesty, I have to say I find that to be a deliberate misrepresentation of the value and potential of the standard. And you are smart enough to know it, so please, let's not play games here. If that is the intent, I don't see the value of writing the standard in a pseudo-formal language that is weakly defined and not standardized. Which 95% solution is that language part of? And why should DTV be written in that form, thus lending further credibility to the apparently erroneous idea that SBVR SE is the form of text representation defined by the SBVR standard? SBVR does not standardize a language that humans can read, nor does SBVR in fact /define/ (in any of the established ways) any such language. (For example, SBVR SE does not have a metamodel.) Therefore, no human-readable element of a standard can be "written in SBVR", and the DTV lies when it makes that claim! SBVR SE does not have to be a 100% solution to anything. It has to be either well-defined or deprecated. --> No it doesn't. It merely needs to serve its original purpose. Again, my challenge ... show me the examples of real-world definitions and business rules where it fails, and then we can gladly talk. SBVR standardizes the language-independent concept model needed to digest the meaning of real-world definitions and business rules. It doesn't standardize notation, and for very good reason ... there is no single best or even preferred language to express real-world definitions and business rules. We must either make SBVR SE a well-defined formal language that we do expect people to use, or stop promulgating the fiction that it plays any useful role in SBVR or in OMG. --> If you can say that, then all I can say in response is that your purpose and need seems not to align with the original (and current) intent of SBVR. Let's not play cat and mouse here. Ron The cost of writing definitions and rules in a complex non-language is not justifiable. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 Ron At 07:01 PM 4/2/2012, Edward Barkmeyer wrote: Ron. Ross wrote: --> I have no problem with SBVR-SE being (or becoming) a language that can be 'unambiguously interpreted into LRMV formulations'. (We don't use it anyway.) NIST doesn't use it, either. Unfortunately, the SBVR specification does. Also, many people are looking for an English-like language in which to phrase unambiguous business rules and definitions, and they are taking SBVR SE as a 'standard language' for that purpose. The particular problem we have is that DTV definitions and rules are written in that language, as if it were the SBVR standard. At this writing, we have only MRV representations of DTV; we don't have standard LRMV representations of the DTV definitions and rules, and we only believe that the SBVR SE text will produce the intended 'semantic formulations'. My point is that SBVR is (and always has been) intended to support a far wider audience than will (or could) ever write in SBVR-SE per se. Which, you will forgive me, is irrelevant to the issue. Given only MRV implementations, whatever language people write rules in will be exchanged verbatim and only may be interpretable by a receiving tool. In most cases, it will probably just be displayed to humans verbatim. DTV is written in SBVR SE, and its definitions are supposed to have a standard interpretation, as distinct from the 'annotation text' in OWL or the 'ownedComments' in UML, both of which are perfectly capable of capturing noun concepts, verb concepts, and definitions in natural languages. I wrote: The standard provides by example a vocabulary structure, vocabulary concepts, and a readable and apparently unambiguous language for expressing intent. What most troubles me is not that the standard is weakly defined in exactly those areas, but rather that the majority of the RTF seems not to understand that that is where the value is. Ron wrote: --> Ed, I should invite you onto to some of our engagements as an observer. I feel quite certain the experience would broaden your thinking about where the value and potential of SBVR really lies. I can't imagine how. No one on the other side of the table in your engagements is part of the audience for SBVR. The audience for SBVR is the people on your side of the table -- the people who know in general that they need to capture the business concepts and rules carefully, and need a model and tools to help them do that. What we see in the manufacturing world is a collection of business people and manufacturing engineers -- the other side of the table -- who need to be able to read the definitions and rules as captured by the analyst using whatever tool, and to verify that those definitions and rules are consistent with their (the business persons') intent. They also need to be sure that those captured rules and definitions are faithfully translated to the languages of whatever software engines they entrust part of their business operations to. They can't know that, but they might believe smart tools could do that, and their results will be at least consistent, by comparison with the programmer of the week. Now, in 2008-9, working with the Automotive Industry Action Group, we looked for commercial or academic tooling that actually does these two tasks: - capture and display terms, definitions and business rules in a "business-friendly" language - translate that language faithfully into a formal representation that can be used by "machine reasoning tools" to support the business operations Our concern was to validate incoming information from partners, suppliers and distributors, for completeness, meaningfulness, and consistency, using the formalized definitions and business rules to drive the testing. That was why I supported SBVR in the first place. By 2010, we found no such tools. Unisys RulesModeler had disappeared from the market, and there was no competitor. There are several tools that manage terms, definitions, and rules somehow or other, but most of them export SKOS, if anything, and none of them export anything useful for logical reasoning. So I gave up and wrote my own. There was no particular reason to input SBVR SE, because it is not a standard and the only tools that capture it depend on the markup and don't export even MRV. So, where is the audience for SBVR? It seems to be primarily a textbook for postgraduates trying to learn how to capture vocabularies and rules, and an occasional resource for business analysts trying to learn still more from the BRG about how to do what many of you do. That has its value, to be sure, but all of the value is to people on your side of the table. I consider myself to be a computer scientist and a rusty computational linguist who happens to have some experience in sitting on your side of the table on and off over the last 40 years. I can't do what you do nearly as well as you can, but I do know what you do, and I know that all of the value in SBVR is on your side of the table. It will become indirectly valuable to the other side -- the real business people -- if and when tooling is built that lets people with your expertise capture what the business people are trying to say in a way they can understand, and that can spit that out in a standard form that can be used by tools that analyze and implement those rules. Now, the tooling will be valuable if the form in which you capture business intent and display it to business people is standardized, which SBVR does not do, or if it can spit out the business intent in any formally complete standard form, so that other tools can do the analysis and conversion to automated implementation. SBVR defines the standard form, but no one implements it. So when either the standard grammar for a business friendly language is defined, or tools are built to export an unambiguous standard form for vocabulary, definitions and rules, the value will be realized. And SBVR will play some role in that, if and only if it happens to be the standard form the actual tools use. Or it would shake your confidence about the skill level of the vast majority of business people and business workers in the real world. Or *both* ... and that has always been the raison d'etre for SBVR. The vast majority of "business people", like the vast majority of any profession are, as my wife says, like auto mechanics. 20% of them are highly skilled and knowledgeable and can solve real problems. 60% of them are good enough at what they do to perform normal duties and operations without making many mistakes. The remaining 20% are what gives the profession a bad name. I have seen a fairly broad spectrum. It would probably not shake my confidence in the skills of business people. I might move the distribution percentages a bit. I fail to see how the skills of business persons are relevant to SBVR. I do understand that the variance in skills of business persons might be why there is little value to a standard "business friendly" language for writing definitions and rules. But if that is the case, why is SBVR written in such a language? It seems to me that the intent of SBVR SE is to make the definitions and rules readable to educated business analysts and consultants -- your side of the table. I have had the pleasure of working with several very gifted business analysts and consultants, some of whom are on this exploder, and it seems to me that they, and more to the point, the 60% of their profession that is capable if not gifted, are the primary audience for SBVR as written. But it is the toolsmiths who support them for whom the standard is usefully normative. -Ed Ron -Ed Markus Schacher wrote: Ron, Yes, my issue is strictly limited to SBVR-SE. However, it shows that we have fundamentally different expectations on languages like SBVR-SE. I know, you mentioned those concerns some time ago. I always believed (and still do) that in SBVR languages such as SBVR-SE (as well as RuleSpeak?) should be used to construct precise representations of underlying meanings. In other words: that there must be a .one to many.-association between a .meaning. and its .representation(s).. You propose that this association should be .many to many., i.e. that a representation is intentionally ambiguous in order to make it human comprehensible. This is not a problem per se, as long as you have an authoring tool as you describe it (and I assume you have it) or as long as human common sense is sufficient (and sufficiently common) to resolve any potential ambiguity. I believe that this is not always guaranteed: Many .rule texts. only come as their representation either on paper or as a PDF or Word document. If these rule texts are about a less common topic, common sense may fail and no disambiguation tool is available to resolve potential ambiguities ­ it.s up to the reader. Particularly in the context of law texts, this is what lawyers earn their living from. And for most of its readers, even SBVR only comes as a document represented in SBVR-SE written in Microsoft Word or Framemaker and read as a PDF file. This is where what consultants earn their living from. Best regards, Markus *From:* Ronald G. Ross [ mailto:rross@brsolutions.com] *Sent:* Donnerstag, 29. Mä 2012 19:24 *To:* Juergen Boldt; issues@omg.org < mailto:issues@omg.org>; sbvr-rtf@omg.org < mailto:sbvr-rtf@omg.org> *Subject:* Re: issue 17244 [and issue 17243] -- SBVR RTF issue Markus, At the risk of misunderstanding your intent (which may be strictly limited to SBVR-SE?), let me say the following. With respect to both your new issues, I think we want to be careful about the degree of absolute rigor we expect or require of people writing business rules. Writing business rules to run a business is (clearly) not the same as programming to build a system. Yes, both of your issues might cause some ambiguity. But let's look at the "another" question, for example. Along with the subscripting, "another" makes it clear enough that the intent is that person1 not be married to some person3 who is not person2 ... or person1. I'd say it's 99%+ certain that's what's meant. How should the 1% (or less) of uncertainty be dealt with? That's where the value-add of good front-end tooling comes to bear. To clear up uncertainties, the tool could and should do all the following: * Enter a dialog with the specifier. * Identify the potential anomaly or ambiguity and refer it to a more-skilled analyst/administrator. * Fall back on tool-specified defaults, which are well documented and available for inspection and manipulation. * Support company-, administrator-, project-, or end-user-specific settings. I've written a number of times about this before. We should not ... and indeed *cannot* ... force-fit the droves of people would will need to specify know-how and business rules into a programming mindset. It's not going to happen. (And the beauty of SBVR is that it doesn't have to.) Ron At 10:19 AM 3/29/2012, Juergen Boldt wrote: From: webmaster@omg.org < mailto:webmaster@omg.org> < mailto:webmaster@omg.org> Date: 17 Mar 2012 06:17:29 -0500 To: < mailto:issues@omg.org >> Subject: Issue/Bug Report ******************************************************************************* Name: Markus Schacher Employer: KnowGravity Inc. mailFrom: markus.schacher@knowgravity.com < mailto:markus.schacher@knowgravity.com> < mailto:markus.schacher@knowgravity.com> Terms_Agreement: I agree Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: C.1.2 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: 2008 Doc_Month: January Doc_Day: Day Page: 241 Title: Keyword "another" Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: The Structured English keyword "another" is sometimes ambiguous. For an example, in the following rule, it is formally not clear whether "another " refers to and/or : It is prohibited that a , if that another . Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org > [] < http://www.omg.org/signature.htm> < http://www.omg.org/signature.htm> [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png < http://www.brsolutions.com/email/wordpress-2.png%A0> *Blog* || http://www.RonRoss.info/blog/ < http://www.ronross.info/blog/> < http://www.ronross.info/blog/> < http://www.ronross.info/blog/%3E%A0%A0%A0%A0> http://www.brsolutions.com/email/linkedin.png < http://www.brsolutions.com/email/linkedin.png%A0> *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png < https://twitter.com/Ronald_G_Ross> < https://twitter.com/Ronald_G_Ross%3E%A0> *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png < http://www.brsolutions.com/email/button-green.png%A0> *Homepage* || http://www.RonRoss.info < http://www.ronross.info/> < http://www.ronross.info/> -- Edward J. Barkmeyer Email: edbark@nist.gov < mailto:edbark@nist.gov> National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ < http://www.ronross.info/blog/> http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png < https://twitter.com/Ronald_G_Ross> < https://twitter.com/Ronald_G_Ross> *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info < http://www.ronross.info/> -- Edward J. Barkmeyer Email: edbark@nist.gov < mailto:edbark@nist.gov> National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ < http://www.ronross.info/blog/> http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png < https://twitter.com/Ronald_G_Ross> < https://twitter.com/Ronald_G_Ross> *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info < http://www.ronross.info/> Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info