Issue 9475: missing definitions (sbvr-ftf) Source: International Business Machines (Mr. Mark H. Linehan, mlinehan@us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2. Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation). Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant. Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned. Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibilty, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1. Section 10.1.2 defines prohibition but not impossibility. Suggestions: 1. It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. Alternatively, section F.1.1 should be aligned with section 12.2.1 -- but that seems undesirable since the unrestricted forms do appear in the real world. 2. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality. 3. Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications. 4. Adopt a consistent approach to the negative forms (prohibition, impossibility): a) Adopt one designation for nonpermission/forbidden/prohibition. b) Define impossibility in section 10.1.2. c) Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities. Resolution: Revised Text: see dtc/2007-06-04 for details Actions taken: March 27, 2006: received issue January 15, 2008: closed issue Discussion: Make the following set of changes, based on FTF discussion, with final agreement in the telcon of 01/03/2007. End of Annotations:===== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MimeOLE:Thread-Index:In-Reply-To; b=dVJSmsTNUTdAJ8vbxXpwDDrzl/Fkr7Q3JqdKbeQ4E3WKz+9wTUUnv5vRBA5pYuvOkL7RO57TNVL/yHUgU6ELd8USff0JFwusYVtlK91PVikUNsJS6xWVWG2lS3EjIDFPsjgr3Fmh3THpDpmINWC1dRq/EgFV36eT1M+ChhjwyxA= ; X-YMail-OSG: EMtCc6cVM1mst4sJ67H6QCx_q3zlabY.J6uLA7ilvS09HOXoQgjz_noVkGRJt3tkEkCjXj.5MHiDeISXq5dCdqj7UZJFQJlZH6N8msXAqhTo4wEen2WdJ_OO1dKzGs3RD.wr.ZG65ZCakxBtIHjsPl0bN2W.mpyn Reply-To: From: "Donald Chapin" To: Subject: RE: issue 9475 -- SBVR FTF issue - Label on Necessity Statements in Chapter 12 Date: Mon, 13 Nov 2006 06:25:04 -0500 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZR1bTPWh75uVruS3+yyl+8tGP9bi1QAz9g A point overlooked in the discussion on Saturday. Since Necessity Statements in an SBVR concept entry must always be implied by the definition of the concept, the SBVR Structured English label for them should be changed from .Necessity:. to .Implied:.. This will remove two current potential misunderstandings: 1. that Necessity Statements change the definition in some way, when they only make things that are implicit in the definitions explicit. 2. that Necessity Statements are required, when in fact they are always optional. Unless this change is made I think we should drop the necessity statements from Chapter 12. The sentiment was almost 50/50 and these two misunderstandings, if not corrected, really tip the decision to removing the Necessity Statements. Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 27 March 2006 14:36 To: issues@omg.org; sbvr-ftf@omg.org Subject: issue 9475 -- SBVR FTF issue To: issues@omg.org Subject: SBVR question X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Mon, 27 Mar 2006 10:26:40 -0500 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 6.5.4FP3 HF3|February 22, 2006) at 03/27/2006 10:26:41, Serialize complete at 03/27/2006 10:26:41 Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2. Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation). Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant. Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned. Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibilty, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1. Section 10.1.2 defines prohibition but not impossibility. Suggestions: 1. It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. Alternatively, section F.1.1 should be aligned with section 12.2.1 -- but that seems undesirable since the unrestricted forms do appear in the real world. 2. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality. 3. Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications. 4. Adopt a consistent approach to the negative forms (prohibition, impossibility): a) Adopt one designation for nonpermission/forbidden/prohibition. b) Define impossibility in section 10.1.2. c) Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities. -------------------------------- Mark H. Linehan Juergen Boldt Director, Member Services 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index; b=kl8MZkCtEqZcrGX51a/C7kqtQbS9f4zUsEZgOCljNnuZBhxdg3WqgIpV+ev5WFzunpK+6z91L++iODZaLXbbdivVmgiRnYAVhdP9HrO4EUQ0qbU0Tn3Y3ANvYNGuiM0h8gfKuQvNVoEFPT508BMH7koo4y6qzapP0SkmUnbCFyg= ; X-YMail-OSG: NI4Kkk8VM1narprOyHyp7WiAL0jN2Qrc1Cstbh8aGapyqEuhpWAPr9df_opHUEdy_030L7DsP3gO1cuvHkcT3ISuf82kXss5JVO8SHZN4EALvvc770ux6vZJPpT6MVECEZZXBWglX06iH6txa0Hz..pDnzJ89GUi Reply-To: From: "Donald Chapin" To: Subject: FW: issue 9475 -- SBVR FTF issue - Label on Necessity Statements in Chapter 12 Date: Mon, 13 Nov 2006 07:23:44 -0500 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccHHb7OeQpFXwxsTmu/varuXathjAAAKsVA Forwarded on behalf of Keri. > -----Original Message----- > From: Keri Anderson Healy [mailto:keri_ah@mac.com] > Sent: 13 November 2006 07:18 > To: Donald Chapin > Cc: Don Baisley; Ronald G. Ross; Keri > Subject: Re: issue 9475 -- SBVR FTF issue - Label on Necessity Statements > in Chapter 12 > > Donald, Since I cannot send to the FTF list, please send on my reply. > (Ron or Don, If Donald has not sent on my reply (below) by noon, PST, > please send it on to the FTF my behalf.) > ~~~~~~~~~~~~~~~~~~~ > Donald, > > You have misrepresented why I was in the half that voted to maintain the > Necessities in Clause 12. I stated that they should be retained while we > continue to do the work on 9475. I do not agree with what you are > proposing as a change in the captioning. > > ~ Keri > > On 11/13/06 6:25 AM, "Donald Chapin" wrote: > > A point overlooked in the discussion on Saturday. > > > > Since Necessity Statements in an SBVR concept entry must always be > implied by > > the definition of the concept, the SBVR Structured English label for > them > > should be changed from ?Necessity:? to ?Implied:?. > > > > This will remove two current potential misunderstandings: > > > > 1. that Necessity Statements change the definition in some way, > when > > they only make things that are implicit in the definitions explicit. > > 2. that Necessity Statements are required, when in fact they are > always > > optional. > > > > Unless this change is made I think we should drop the necessity > statements > > from Chapter 12. The sentiment was almost 50/50 and these two > > misunderstandings, if not corrected, really tip the decision to removing > the > > Necessity Statements. DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:In-Reply-To; b=wgj9UjHddMgMaXa3l2fpm8z0GdjIpMlGyGBcJsPsdk8fLPVC6ltJLQT6OgoON8QAmDPaz9ZsxOh7GMJwXC1cY/LRkuguh4dWzRA+pyVBzRxsypYprwgmmmn+fPxWrSSsSU8zNLNJId94r4lEXypbOHMTDtEmQmRoVMtZP5t217g= ; X-YMail-OSG: D7ts9SYVM1nQzo7ZbTk4ExIx50bFp8fJrDXML9d_S1T7Z9PhUjB6zdROKKFsaz.vTsIghO8n7U8nswPnVEBM8BLhW1dKLHO7WyAy6nOXVGr26b3hL4eYPOraahNSPJyvBM8zX8PE3qIM1ttF89pwpB9uaMY6Tz6z Reply-To: From: "Donald Chapin" To: Subject: RE: issue 9475 -- SBVR FTF issue - Label on Necessity Statements in Chapter 12 Date: Mon, 13 Nov 2006 07:32:44 -0500 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccHHb7OeQpFXwxsTmu/varuXathjAAAKsVAAAAnXgA= Keri, Since Necessity Statements do not add anything to (i.e. do not change the meaning of) definitions and are always optional, it would be helpful to understand: a. why you feel "Implied:" is not a better label in Structured English, and b. how you would remove the two potential misunderstanding inherent in the label "Necessity:". Do I understand from you email below that you are proposing that all the necessities be removed from Clause 12 as part of 9475, but at the end when everything else for 9475 is finished? Many Thanks, Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 13 November 2006 07:24 > To: sbvr-ftf@omg.org > Subject: FW: issue 9475 -- SBVR FTF issue - Label on Necessity Statements > in Chapter 12 > > Forwarded on behalf of Keri. > > > > -----Original Message----- > > From: Keri Anderson Healy [mailto:keri_ah@mac.com] > > Sent: 13 November 2006 07:18 > > To: Donald Chapin > > Cc: Don Baisley; Ronald G. Ross; Keri > > Subject: Re: issue 9475 -- SBVR FTF issue - Label on Necessity > Statements > > in Chapter 12 > > > > Donald, Since I cannot send to the FTF list, please send on my reply. > > (Ron or Don, If Donald has not sent on my reply (below) by noon, PST, > > please send it on to the FTF my behalf.) > > ~~~~~~~~~~~~~~~~~~~ > > Donald, > > > > You have misrepresented why I was in the half that voted to maintain the > > Necessities in Clause 12. I stated that they should be retained while > we > > continue to do the work on 9475. I do not agree with what you are > > proposing as a change in the captioning. > > > > ~ Keri > > > > On 11/13/06 6:25 AM, "Donald Chapin" > wrote: > > > A point overlooked in the discussion on Saturday. > > > > > > Since Necessity Statements in an SBVR concept entry must always be > > implied by > > > the definition of the concept, the SBVR Structured English label for > > them > > > should be changed from ?Necessity:? to ?Implied:?. > > > > > > This will remove two current potential misunderstandings: > > > > > > 1. that Necessity Statements change the definition in some way, > > when > > > they only make things that are implicit in the definitions explicit. > > > 2. that Necessity Statements are required, when in fact they are > > always > > > optional. > > > > > > Unless this change is made I think we should drop the necessity > > statements > > > from Chapter 12. The sentiment was almost 50/50 and these two > > > misunderstandings, if not corrected, really tip the decision to > removing > > the > > > Necessity Statements. > DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MimeOLE:Thread-Index; b=b8uWNOmQXPivNvvxMp9wuPNbJStAIDYMstNKmWVMdrwI+/XuIwuCvcFo13faKBpQyl/ZxKRUBfrs4HLHpcgPZ5j7PBXw5iyioJfKeGvEv2eAWHRc7Yjm/8Q3NeIiUtb5Vdl6ZWl3Eos0zfCPzFptKsW6hZ+iXaNM6NtWimoXmM8= ; X-YMail-OSG: s1ZWhfsVM1mt07cIuBUdt_kQszqkr9hSTR9IgKlkAL6TfgQuWOMyaT_rijnrmLFE0smatzGcVd0FpLNm7e1httMjMYFCATSTajr5EIt0dNkS3VjxkPTwxgtDQjew7VTZh8ECqrtQ8MziwEdG5xKxN1f0.n5n693K Reply-To: From: "Donald Chapin" To: Subject: FW: issue 9475 -- SBVR FTF issue - Label on Necessity Statements in Chapter 12 Date: Mon, 13 Nov 2006 08:31:55 -0500 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZR1bTPWh75uVruS3+yyl+8tGP9bi1QAz9gAAR5eqA= The email below is a problem statement on 9475 to be added to the list that was compiled in the face to face meeting on Nov. 11-12. It is a key factor with respect to the decision of whether or not to keep the Necessity Statements in Clause 12. Donald -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: 13 November 2006 06:25 To: 'sbvr-ftf@omg.org' Subject: RE: issue 9475 -- SBVR FTF issue - Label on Necessity Statements in Chapter 12 A point overlooked in the discussion on Saturday. Since Necessity Statements in an SBVR concept entry must always be implied by the definition of the concept, the SBVR Structured English label for them should be changed from .Necessity:. to .Implied:.. This will remove two current potential misunderstandings: 1. that Necessity Statements change the definition in some way, when they only make things that are implicit in the definitions explicit. 2. that Necessity Statements are required, when in fact they are always optional. Unless this change is made I think we should drop the necessity statements from Chapter 12. The sentiment was almost 50/50 and these two misunderstandings, if not corrected, really tip the decision to removing the Necessity Statements. Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 27 March 2006 14:36 To: issues@omg.org; sbvr-ftf@omg.org Subject: issue 9475 -- SBVR FTF issue To: issues@omg.org Subject: SBVR question X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Mon, 27 Mar 2006 10:26:40 -0500 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 6.5.4FP3 HF3|February 22, 2006) at 03/27/2006 10:26:41, Serialize complete at 03/27/2006 10:26:41 Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2. Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation). Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant. Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned. Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibilty, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1. Section 10.1.2 defines prohibition but not impossibility. Suggestions: 1. It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. Alternatively, section F.1.1 should be aligned with section 12.2.1 -- but that seems undesirable since the unrestricted forms do appear in the real world. 2. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality. 3. Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications. 4. Adopt a consistent approach to the negative forms (prohibition, impossibility): a) Adopt one designation for nonpermission/forbidden/prohibition. b) Define impossibility in section 10.1.2. c) Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities. -------------------------------- Mark H. Linehan Juergen Boldt Director, Member Services 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index; b=lHEJrCcVb3bEAE71RX38OayPot0yhd49LhRdyjr5tZtm74J/xTs/sodgM1LnLC1WdzjPILlHmNY4+dnXnPgezY2cco8R3A/7JuNm3klGiMQ+9JZ59qcZyKcZdvOpgAji5slemnoYMn7MD4SviAr06eHCc2ad/CTgQVguMug2Pdg= ; X-YMail-OSG: SrK5aToVM1kwpl.dgJiDpg5mIcAE0Jsvuak7H_NmAxWBlSDdSjX2QO_efSgKjSYB4SyGd..nIcSxF0TwE9FAdgpJY779ywLK9DjfNNvqJhq4o2cbzjBO.p4r1jYHTh0MCkRCehCVZj3mlNORDL2bFWFjNVMmb_An Reply-To: From: "Donald Chapin" To: Subject: FW: issue 9475 -- SBVR FTF issue - Label on Necessity Statements in Chapter 12 Date: Mon, 13 Nov 2006 15:25:34 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccHJchbVjC00WL1RbCunac7XmJ9xwAEiNiw > -----Original Message----- > From: Keri Anderson Healy [mailto:keri_ah@mac.com] > Sent: 13 November 2006 13:15 > To: Donald Chapin > Cc: Keri > Subject: Re: issue 9475 -- SBVR FTF issue - Label on Necessity Statements > in Chapter 12 > > Donald, Please share my replies, below. ~ Keri > > On 11/13/06 7:32 AM, "Donald Chapin" wrote: > > Since Necessity Statements do not add anything to (i.e. do not change > the > > meaning of) definitions and are always optional, it would be helpful to > > understand: > > > > a. why you feel "Implied:" is not a better label in Structured > English, > > and > > > > b. how you would remove the two potential misunderstanding inherent > in > > the label "Necessity:". > > I understand the questions you are raising here are already in Issue 9613. > So I defer comment on that until there is a better understanding of what > you see to be the problem. > > > Do I understand from you email below that you are proposing that all the > > necessities be removed from Clause 12 as part of 9475, but at the end > when > > everything else for 9475 is finished? > > All I am saying is that there was no 'misunderstanding' in the room at the > end of Saturday, other than the normal state of affairs that (a) we had > discussed/proposed many rearrangements of things that we have not actually > seen written up and (b) we were out of time to confirm which line items > were being proposed for removal vs. which were to be retained. > > Don't read too much into the informal vote -- it reflected end-of-a-long- > day (& long week) fatigue, rather than confusion. (And, I've checked with > John, and he too does not wish his vote to be characterized as > misunderstanding or confusion.) > > ~ Keri Date: Mon, 13 Nov 2006 11:12:00 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: Donald.Chapin@btinternet.com CC: sbvr-ftf@omg.org Subject: Re: issue 9475 -- SBVR FTF issue - Label on Necessity Statements in Chapter 12 X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Donald Chapin wrote: A point overlooked in the discussion on Saturday. Since Necessity Statements in an SBVR concept entry must always be implied by the definition of the concept, the SBVR Structured English label for them should be changed from "Necessity:" to "Implied:". Disagree. Not that this would be hard to do, because it involves only changing the Style. But this seems to me to be a totally unnecessary change, unless we have some other intent for the Necessity clauses attached to glossary items. We have so many real clarifications and corrections to make, why should we make a needless change to the SBVR terminology? This will remove two current potential misunderstandings: 1. that Necessity Statements change the definition in some way, when they only make things that are implicit in the definitions explicit. If we write the clause in Annex C to make this clear, there is no excuse for misreading this intent. 2. that Necessity Statements are required, when in fact they are always optional. Perhaps I misunderstand this misunderstanding. Donald apparently means that formulators of vocabularies might believe that a Definition that contains implied necessities cannot stand on its own without them. And the fact is that they might be right. Whether "necessity" statements are "required" or not depends on the purpose and intended completeness of the vocabulary 'model'. To move back into the space of MOF models for a moment, the Definition of a glossary item in an SBVR M1 model becomes the Documentation of the corresponding MOF object (Class, Association, etc.). The Necessities become Constraints attached to the MOF object. MOF suppports the idea that a Constraint can be specified in any of several languages. So, SBVR Structured English can be the language of some Constraints, while Natural English or French or Arabic or Chinese can be the language of others. Definitions need not be formally processable, and a tool would actually need a MOF TaggedValue to convey a 'formal definition', because the presumption of the mapping must be that Definitions are partly or mostly natural language. But Necessity statements that are formal should be marked as such, so that they are always formally processable: Formal Necessity statements should be marked Structured English or Rulespeak or OCL or whatever, and should not contain any terms that appeal to the NODE for definition. While they may have the same meaning to a human reader, these distinctions in formalism of the model are important! (Much more so, I aver, than how we spell the clause title.) I believe that Note adequately covers the case of *informally stated* implications that may not be inherent in the text of the definition. But if the author produces non-formalized "Necessity" clauses to document "implications", they can go as "natural language" Constraints in the XMI, which are likely to be handled as Notes by most tooling. Unless this change is made I think we should drop the necessity statements from Chapter 12. The sentiment was almost 50/50 and these two misunderstandings, if not corrected, really tip the decision to removing the Necessity Statements. "Contrariwise", I think the decision must be made on the basis of the intent to formalize those Necessities as Constraints in the BusinessRules MOF package (vocabulary). Finally, I believe this is an entirely separate issue. I am at a complete loss to understand how Donald's proposal, much less my view of Necessity clauses, is related to Mark's issue 9475, which is about categories of propositions. -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 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." ubject: SBVR question X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Mon, 27 Mar 2006 10:26:40 -0500 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 6.5.4FP3 HF3|February 22, 2006) at 03/27/2006 10:26:41, Serialize complete at 03/27/2006 10:26:41 Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2. Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation). Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant. Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned. Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibilty, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1. Section 10.1.2 defines prohibition but not impossibility. Suggestions: 1. It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. Alternatively, section F.1.1 should be aligned with section 12.2.1 -- but that seems undesirable since the unrestricted forms do appear in the real world. 2. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality. 3. Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications. 4. Adopt a consistent approach to the negative forms (prohibition, impossibility): a) Adopt one designation for nonpermission/forbidden/prohibition. b) Define impossibility in section 10.1.2. c) Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities. -------------------------------- Mark H. Linehan To: sbvr-ftf@omg.org Subject: follow-up on issue #9475 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Thu, 11 May 2006 11:29:36 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 6.5.4FP3 HF3|February 22, 2006) at 05/11/2006 11:29:36, Serialize complete at 05/11/2006 11:29:36 I'm writing to follow-up on issue #9475. I found the following in the minutes of the March 30th FTF phone call. 1. Where can I find the referenced paper from the December, 2003 Scottsdale meeting? 2. I have not heard from John Hall, and am wondering about that. (But I can completely understand if he's just very busy.) A couple of comments regarding admonitions & affirmations: * By definition, these are elements of guidance ... "where, by custom or practice, one might not be assumed" (12.1.4). That seems unsatisfactory when you have a statement such as "the manager may approve the purchase request". The statement appears to state unrestricted permission. By custom, one might assume that the manager may do this. So why should such a statement be an affirmation? * Why classify admonitions and affirmations separately from other kinds of elements of guidance? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com ------------the following is extracted from the FTF minutes of March 30, 2006 ---------------------------------------------------- Issue #9475 Donald Chapin: Need a chart or table to demonstrate cohesiveness(?). Donald Chapin: The BRG produced/submitted a paper on this from its Scottsdale meeting in December, 2003. Ed B.: F1.1 is legitimate with respect to how business people really express themselves. Ed B.: Mark is expecting a straightforward mapping, but the world is not that simple. With respect to F1.1 and 12.2.1, Mark is not mapping comparable things. There are 8 statements, but only 6 business rules because (1) unrestricted permissions and (2) unrestricted possibilities are *not* business rules per se. (They are admonitions/affirmations.) Element of guidance is .higher. than business rule. John Hall: Point him toward explanation/example/diagram and see if that fixes. John Hall agrees to e-mail directly. Then, depending on the result, perhaps add Introduction to some section(s) (not sure where) to explain. Ed B.: Maybe Notes where the ideas are introduced in 9 or 10. Date: Wed, 26 Jul 2006 15:45:11 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: SBVR-FTF Subject: [SBVR] Response to issue 9475 Hello all, I have produced a response to Mark Linehan's issue 9475, raised some time ago. There is likely to be further discussion before the issue can be resolved. Regards, John Issue9475response.doc Issue 9475: Missing Definitions Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2. These are two alethic (necessity, possibility); two deontic (obligation, permissibility). Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation). Section 10.1.2 elaborates the four basic modalities by including their negations: alethic (necessity, non-necessity, possibility, impossibility); deontic (obligation, non-obligation, permissibility, prohibition). They can be related as in the two tables below: Alethic Possibility Impossibility Necessity Necessity Inconsistency Non-necessity Contingency Impossibility Deontic Permissibility Prohibition Obligation Obligation Inconsistency Non-obligation Option Prohibition (The Stanford Encyclopaedia of Philosophy [http://plato.stanford.edu/entries/logic-deontic] calls this view "folk logic", but it's about as far as we have gone with modal logic in SBVR.) Section 10.1.2 says that Contingency (possible but not necessary) is not relevant in a business rules context. We don.t mention .Option. (permitted but not obligatory, sometimes called .gratuitous.), but we could make a similar claim, since neither contingencies nor options are rules. Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant. The operators in table I.3 have some overlaps in scope. If we remove these overlaps there are: · Four modal operators that are used to form rules: · Necessity (which implies Possibility) · Impossibility · Obligation (which implies Permissibility) · Prohibition · Two modal operators that are not about rules: · Possibility that is not a Necessity (Contingency) · Permissibility that is not an Obligation (Option) But Annex I is about ORM, so I.d be happy to leave it as it is. Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned. Section 12.2.2 (not 12.2.1) describes: · Three syntactic forms for operative business rules (Obligations and Prohibitions): obligation, prohibitive, restricted permissive · Three syntactic forms for structural business rules (Necessities and Impossibilities): necessity, impossibility, restricted possibility These are not in direct correspondence with the modal operator in the abstract form of the rule. For example, an obligation can be expressed in prohibitive form, e.g. .It is prohibited that a rental is open unless it has a provisional charge against the credit card of the renter. rather than .It is obligatory that each open rental has a provisional charge against the credit card of the renter. (an open rental is one where the renter has possession of the car). The syntactic form used is a business choice. The prohibitive form may be a more effective way of expressing the rule to staff: .Don.t give the renter the car keys without making a charge against his credit card.. Unrestricted permission and possibility statements seem to me to be statements of Option (permitted but not obligatory) and Contingency (possible but not necessary). They are not statements of rules, they just provide information. Businesses don.t explicitly list everything possible or permissible - they would never finish. They may need to state specific options and contingencies to deal with operational requirements. The most common of these is when staff act as if something were necessary, impossible, obligatory or prohibited, when it actually isn.t. Then the business provides reminders that there aren.t rules (necessities, impossibilities, obligations or prohibitions), and staff should not act as if there were, for example: .There is no minimum age requirement for a savings account.; .A rental booking does not have to include a car model.. The underlying intention is that staff should apply only the company.s rules, and not make up their own. Staff sometimes do this because it is common practice in their industry, or because their former employers in the same industry had such rules, or because .It.s common sense, innit?. These reminders are currently called Admonitions and Affirmations (I have raised an issue about this) - contingency and option statements to remind staff that there are not rules. Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibility, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1. Annex F is about RuleSpeak, a proprietary standard for expression of rules, and I.d be happy to leave it as it is. Section 10.1.2 defines prohibition but not impossibility. This is true. Suggested Resolution (as provided with the issue) It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. We need to deal with this in sections 12.2.1 and 12.2.2 in resolving Admonition and Affirmation Alternatively, section F.1.1 should be aligned with section 12.2.1 -- but that seems undesirable since the unrestricted forms do appear in the real world. Preferably not. Annex F is about RuleSpeak, a proprietary standard for expression of rules. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality. We need to deal with this in resolving Admonition and Affirmation. My preferred option (personal, not yet discussed with the rest of the FTF) is to include Contingency (structural) and Option (operative) instead of Affirmation and Admonition in 12.1 and Admonitory Form and Affirmatory Form in 12.2.1 Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications. I agree Adopt a consistent approach to the negative forms (prohibition, impossibility): I agree Adopt one designation for nonpermission/forbidden/prohibition. I agree Define impossibility in section 10.1.2. Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities. I agree Note that .I agree. does not necessarily mean that the rest of the FTF will agree. To: SBVR-FTF Subject: Re: [SBVR] Response to issue 9475 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Wed, 26 Jul 2006 15:15:02 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 6.5.4FP3 HF3|February 22, 2006) at 07/26/2006 15:15:03 I read this, and still find it quite confusing. I have inserted comments in the original response to identify which aspects are unclear to me. Ironically, I think John Hall and I mostly agree on the suggested resolution. I do want to make these additional points: * I think that Appendices F (RuleSpeak) and I (ORM) should be clearly aligned with the rest of the document. It creates confusion if these seem to have different schema than the normative part of the spec. If the difference is just vocabulary, then the relationship of their terms to the SBVR basic terms should be made explicit. If the difference is one of outlook then there's something more to be worked out. * Whenever I look at section 12, the definition of affirmations & admonitions seems artificial: (a) "custom or practice" is not defined and is likely to vary among different user perspectives and vary over time; (b) one can't tell from a statement whether it is an affirmation or admonition because you need additional knowledge about "custom or practice"; (c) distinguishing affirmations & admonitions from rules does not seem consistent with real world practice. I'd prefer to say that affirmations & admonitions are kinds of rules so that then I can make statements about all rules instead of about "elements of guidance." Or should this specification really be titled "Semantics of Business Vocabulary and Elements of Guidance"? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John Hall 07/26/2006 10:45 AM Please respond to john.hall@modelsys.com To SBVR-FTF cc Subject [SBVR] Response to issue 9475 Hello all, I have produced a response to Mark Linehan's issue 9475, raised some time ago. There is likely to be further discussion before the issue can be resolved. Regards, John [attachment "Issue9475response.doc" deleted by Mark H Linehan/Watson/IBM] Issue9475response MHL.doc Issue 9475: Missing Definitions Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2. These are two alethic (necessity, possibility); two deontic (obligation, permissibility). Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation). Section 10.1.2 elaborates the four basic modalities by including their negations: alethic (necessity, non-necessity, possibility, impossibility); deontic (obligation, non-obligation, permissibility, prohibition). They can be related as in the two tables below: Alethic Possibility Impossibility Necessity Necessity Inconsistency Non-necessity Contingency Impossibility Deontic Permissibility Prohibition Obligation Obligation Inconsistency Non-obligation Option Prohibition (The Stanford Encyclopaedia of Philosophy [http://plato.stanford.edu/entries/logic-deontic] calls this view "folk logic", but it's about as far as we have gone with modal logic in SBVR.) Section 10.1.2 says that Contingency (possible but not necessary) is not relevant in a business rules context. We don.t mention .Option. (permitted but not obligatory, sometimes called .gratuitous.), but we could make a similar claim, since neither contingencies nor options are rules. Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant. The operators in table I.3 have some overlaps in scope. If we remove these overlaps there are: · Four modal operators that are used to form rules: · Necessity (which implies Possibility) · Impossibility · Obligation (which implies Permissibility) · Prohibition · Two modal operators that are not about rules: · Possibility that is not a Necessity (Contingency) · Permissibility that is not an Obligation (Option) But Annex I is about ORM, so I.d be happy to leave it as it is. Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned. Section 12.2.2 (not 12.2.1) describes: · Three syntactic forms for operative business rules (Obligations and Prohibitions): obligation, prohibitive, restricted permissive · Three syntactic forms for structural business rules (Necessities and Impossibilities): necessity, impossibility, restricted possibility These are not in direct correspondence with the modal operator in the abstract form of the rule. For example, an obligation can be expressed in prohibitive form, e.g. .It is prohibited that a rental is open unless it has a provisional charge against the credit card of the renter. rather than .It is obligatory that each open rental has a provisional charge against the credit card of the renter. (an open rental is one where the renter has possession of the car). The syntactic form used is a business choice. The prohibitive form may be a more effective way of expressing the rule to staff: .Don.t give the renter the car keys without making a charge against his credit card.. Unrestricted permission and possibility statements seem to me to be statements of Option (permitted but not obligatory) and Contingency (possible but not necessary). They are not statements of rules, they just provide information. Businesses don.t explicitly list everything possible or permissible - they would never finish. They may need to state specific options and contingencies to deal with operational requirements. The most common of these is when staff act as if something were necessary, impossible, obligatory or prohibited, when it actually isn.t. Then the business provides reminders that there aren.t rules (necessities, impossibilities, obligations or prohibitions), and staff should not act as if there were, for example: .There is no minimum age requirement for a savings account.; .A rental booking does not have to include a car model.. The underlying intention is that staff should apply only the company.s rules, and not make up their own. Staff sometimes do this because it is common practice in their industry, or because their former employers in the same industry had such rules, or because .It.s common sense, innit?. These reminders are currently called Admonitions and Affirmations (I have raised an issue about this) - contingency and option statements to remind staff that there are not rules. Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibility, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1. Annex F is about RuleSpeak, a proprietary standard for expression of rules, and I.d be happy to leave it as it is. Section 10.1.2 defines prohibition but not impossibility. This is true. Suggested Resolution (as provided with the issue) It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. We need to deal with this in sections 12.2.1 and 12.2.2 in resolving Admonition and Affirmation Alternatively, section F.1.1 should be aligned with section 12.2.1 -- but that seems undesirable since the unrestricted forms do appear in the real world. Preferably not. Annex F is about RuleSpeak, a proprietary standard for expression of rules. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality. We need to deal with this in resolving Admonition and Affirmation. My preferred option (personal, not yet discussed with the rest of the FTF) is to include Contingency (structural) and Option (operative) instead of Affirmation and Admonition in 12.1 and Admonitory Form and Affirmatory Form in 12.2.1 Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications. I agree Adopt a consistent approach to the negative forms (prohibition, impossibility): I agree Adopt one designation for nonpermission/forbidden/prohibition. I agree Define impossibility in section 10.1.2. Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities. I agree Note that .I agree. does not necessarily mean that the rest of the FTF will agree. Date: Wed, 02 Aug 2006 10:47:35 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: Mark H Linehan Cc: SBVR-FTF Subject: Re: [SBVR] Response to issue 9475 Hello Mark, Attached is an updated copy of my note.. Regards, John Mark H Linehan wrote: I read this, and still find it quite confusing. I have inserted comments in the original response to identify which aspects are unclear to me. Ironically, I think John Hall and I mostly agree on the suggested resolution. I do want to make these additional points: * I think that Appendices F (RuleSpeak) and I (ORM) should be clearly aligned with the rest of the document. It creates confusion if these seem to have different schema than the normative part of the spec. If the difference is just vocabulary, then the relationship of their terms to the SBVR basic terms should be made explicit. If the difference is one of outlook then there's something more to be worked out. * Whenever I look at section 12, the definition of affirmations & admonitions seems artificial: (a) "custom or practice" is not defined and is likely to vary among different user perspectives and vary over time; (b) one can't tell from a statement whether it is an affirmation or admonition because you need additional knowledge about "custom or practice"; (c) distinguishing affirmations & admonitions from rules does not seem consistent with real world practice. I'd prefer to say that affirmations & admonitions are kinds of rules so that then I can make statements about all rules instead of about "elements of guidance." Or should this specification really be titled "Semantics of Business Vocabulary and Elements of Guidance"? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Issue9475response2.doc Issue 9475: Missing Definitions Referencing dtc/06-03-02, section 8.1.2 defines four basic modalities (necessity, possibility, obligation, permissibility). This agrees with table 10.2. These are two alethic (necessity, possibility); two deontic (obligation, permissibility). Section 10.1.2 defines a total of eight modes of thinking, of which one (contingency) "is not relevant in a business rules context." This leaves three alethic modes (necessity, possibility, and impossibility), and four deontic modes (permission, obligation, nonpermission/forbidden/prohibition, and non-obligation). Section 10.1.2 elaborates the four basic modalities by including their negations: alethic (necessity, non-necessity, possibility, impossibility); deontic (obligation, non-obligation, permissibility, prohibition). They can be related as in the two tables below: Alethic Possibility Impossibility Necessity Necessity Non-necessity Contingency Impossibility Deontic Permissibility Prohibition Obligation Obligation Non-obligation Option Prohibition (The Stanford Encyclopaedia of Philosophy [http://plato.stanford.edu/entries/logic-deontic] calls this view "folk logic", but it's about as far as we have gone with modal logic in SBVR.) Section 10.1.2 says that Contingency (possible but not necessary) is not relevant in a business rules context. We don.t mention .Option. (permitted but not obligatory, sometimes called .gratuitous.), but we could make a similar claim, since neither contingencies nor options are rules. Table I.3 lists six modal operators: necessary, possible, impossible, obligatory, permitted, forbidden. This matches section 10.1.2 if we assume that non-obligation (like contingency) is not relevant. The operators in table I.3 have some overlaps in scope. If we remove these overlaps there are: · Four modal operators that are used to form rules: · Necessity (which implies Possibility) · Impossibility · Obligation (which implies Permissibility) · Prohibition · Two modal operators that are not about rules: · Possibility that is not a Necessity (Contingency) · Permissibility that is not an Obligation (Option) But Annex I is about ORM, so I.d be happy to leave it as it is. Section 12.2.1 defines six forms of business rule statements: obligation, prohibitive, restricted permissive, necessity, impossibility, restricted possibility. The two restricted forms are defined as composites of either permission or possibility and a condition. Notice that unrestricted permissive and unrestricted possibility statement forms are not mentioned. Section 12.2.2 (not 12.2.1) describes: · Three syntactic forms for operative business rules (Obligations and Prohibitions): obligation, prohibitive, restricted permissive · Three syntactic forms for structural business rules (Necessities and Impossibilities): necessity, impossibility, restricted possibility These are not in direct correspondence with the modal operator in the abstract form of the rule. For example, an obligation can be expressed in prohibitive form, e.g. .It is prohibited that a rental is open unless it has a provisional charge against the credit card of the renter. rather than .It is obligatory that each open rental has a provisional charge against the credit card of the renter. (an open rental is one where the renter has possession of the car). The syntactic form used is a business choice. The prohibitive form may be a more effective way of expressing the rule to staff: .Don.t give the renter the car keys without making a charge against his credit card.. Unrestricted permission and possibility statements seem to me to be statements of Option (permitted but not obligatory) and Contingency (possible but not necessary). They are not statements of rules, they just provide information. Businesses don.t explicitly list everything possible or permissible - they would never finish. They may need to state specific options and contingencies to deal with operational requirements. The most common of these is when staff act as if something were necessary, impossible, obligatory or prohibited, when it actually isn.t. Then the business provides reminders that there aren.t rules (necessities, impossibilities, obligations or prohibitions), and staff should not act as if there were, for example: .There is no minimum age requirement for a savings account.; .A rental booking does not have to include a car model.. The underlying intention is that staff should apply only the company.s rules, and not make up their own. Staff sometimes do this because it is common practice in their industry, or because their former employers in the same industry had such rules, or because .It.s common sense, innit?. These reminders are currently called Admonitions and Affirmations (I have raised an issue about this) - contingency and option statements to remind staff that there are not rules. Section F.1.1 describes eight statement forms: obligative statement, prohibitive statement, restricted permission, unrestricted permission, necessity, impossibility, restricted possibility, unrestricted possibility. It has both of the forms (unrestricted permission, unrestricted possibility) that seem to be missing from section 12.2.1. Annex F is about RuleSpeak, a proprietary standard for expression of rules, and I.d be happy to leave it as it is. Section 10.1.2 defines prohibition but not impossibility. This is true. Suggested Resolution (as provided with the issue) It seems that section 12.2.1 should include the two unrestricted forms: unrestricted permission, unrestricted possibility. We need to deal with this in sections 12.2.1 and 12.2.2 in resolving Admonition and Affirmation Alternatively, section F.1.1 should be aligned with section 12.2.1 -- but that seems undesirable since the unrestricted forms do appear in the real world. Preferably not. Annex F is about RuleSpeak, a proprietary standard for expression of rules. Section 10.1.2, in the discussion of deontic modality, should make it clear that "non-obligation" is not relevant, as it already does for "contingency" in the definition of alethic modality. We need to deal with this in resolving Admonition and Affirmation. My preferred option (personal, not yet discussed with the rest of the FTF) is to include Contingency (structural) and Option (operative) instead of Affirmation and Admonition in 12.1 and Admonitory Form and Affirmatory Form in 12.2.1 Make the definition of the restricted forms explicit by defining them in terms of the equivalent logical formulations using the underlying basic modalities plus implications. I agree Adopt a consistent approach to the negative forms (prohibition, impossibility): I agree Adopt one designation for nonpermission/forbidden/prohibition. I agree Define impossibility in section 10.1.2. Make the definition of the negative forms (impossibility, prohibition) explicit by defining them in terms of the equivalent logical formulations using "not" and the underlying basic modalities. I agree Note that .I agree. does not necessarily mean that the rest of the FTF will agree. To: sbvr-ftf@omg.org Subject: Re: [SBVR] Response to issue 9475 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Thu, 3 Aug 2006 09:31:02 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/03/2006 09:31:03, Serialize complete at 08/03/2006 09:31:03 John, Thanks for taking the time to respond to my comments. I think I understand better what you mean, but I still don't fully agree that the net result makes sense. Rather than insert further comments within the Word document -- which would make it hard to follow the various threads -- I've tried to summarize my reaction below in two sections: (1) points where the discussion still doesn't make sense to me; (2) points which (I suggest) deserve clarification in the spec. Points that don't make sense to me * Regarding affirmations/admonitions: * John said business operations have to operate in the context of .everything that is not explicitly forbidden is permitted.. I think some rules work this way but that many others start with "all xyz is forbidden" and then layer it with exceptions. Examples are security access control rules, configuration constraints, and some laws that forbid some behavior, but with some exceptions. An example of the latter is the 3rd Amendment to the U.S Constitution about Quartering of Soldiers, which says "No Soldier shall, in time of peace be quartered in any house, without the consent of the Owner, nor in time of war, but in a manner to be prescribed by law." * The current definition makes the definition of admonitions/affirmations dependent upon "custom or practice" but provides no way to express that "custom or practice". If context is really important to affirmations/admonitions, then the spec should provide a way to state the context and relate an affirmation/admonition to the context. For example, there might be an affirmation that "an Owner can consent to the quartering of a Soldier in the Owner's house". It seems like that affirmation should be associated with the underlying context that "No Soldier shall, in time of peace be quartered in any house." * I think the "Categories of Guidance" would be simpler & clearer if affirmations/admonitions were seen as kinds of structural and operative business rules, according to whether the affirmations/admonitions embed necessities or obligations. The distinguishing characteristics of affirmations / admonitions would then be whether they are associated with a context that gives the "default rule". Then the example above about "an Owner can consent ..." would be an affirmative operative business rule associated with a default context about "No soldier shall ...." * A question: consider a statement such as "A USB port may connect up to 4 USB devices". This looks to me like a permission statement, but it doesn't seem to have an underlying "custom or practice" (i.e. a "default context" if you agree with my statements above). If there is no "custom or practice" then this statement can't be an affirmation or admonition. Then what is it? * John said that the statement .a doctor may prescribe medications. "... addresses operational behaviour, but it doesn.t require enforcement - it. not a business rule." Two comments (a) I don't see anything in the definition of rules about "enforcement." (b) John said the statement ".Only a doctor may prescribe medications. is a rule. To me, this depends upon context. If the context is a law that lays down the basic rule "no one can prescribe medications" and then later adds "a doctor may prescribe medications" then the latter statement must be a rule. * Regarding consistency between the RuleSpeak and ORM annexes and the normative part of the document: it seems to me that any inconsistency among these does a disservice to readers and undercuts the usefulness and reputation of the spec. It's already hard to understand what the document means, without builtin inconsistencies. Points that (I think we agree) deserve clarification in the spec * The terminology around modalities and the relationships of the modalities. I prefer the terms used by John Hall but it's not clear how to read his table. I find the Stanford diagram clearer. One way to proceed would be to start by defining the 6 basic "modes of thinking" (necessity, contingency, impossibility, obligation, option, prohibition) and then define "modalities" in terms of those "modes of thinking". For example, "possibility" could be defined very straightforwardly as "necessity or contingency". * In section 10.1.2, the definition of alethic modality implies that possibility is an alternative to necessity and contingency, whereas the discussion above says that possibility includes both necessity and contingency. Similarly, the definition of deontic modality implies that permission and obligations are alternatives whereas the discussion above says that obligation is a category of permission. * Distinguishing among restricted and unrestricted permission and possibility statements. * The correspondance between the various forms of guidance statements and the various modalities. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John Hall 08/02/2006 05:47 AM Please respond to john.hall@modelsys.com To Mark H Linehan/Watson/IBM@IBMUS cc SBVR-FTF Subject Re: [SBVR] Response to issue 9475 Hello Mark, Attached is an updated copy of my note.. Regards, John X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 08 Aug 2006 16:18:51 -0500 To: Mark H Linehan , sbvr-ftf@omg.org From: "Ronald G. Ross" Subject: Re: [SBVR] Response to issue 9475 At 08:31 AM 8/3/2006, Mark H Linehan wrote: John, Thanks for taking the time to respond to my comments. I think I understand better what you mean, but I still don't fully agree that the net result makes sense. Rather than insert further comments within the Word document -- which would make it hard to follow the various threads -- I've tried to summarize my reaction below in two sections: (1) points where the discussion still doesn't make sense to me; (2) points which (I suggest) deserve clarification in the spec. Points that don't make sense to me * Regarding affirmations/admonitions: * John said business operations have to operate in the context of .everything that is not explicitly forbidden is permitted.. I think some rules work this way but that many others start with "all xyz is forbidden" and then layer it with exceptions. Examples are security access control rules, configuration constraints, and some laws that forbid some behavior, but with some exceptions. Correct. Euphemistically, I have always talked about this as the "light world" vs. the "dark world". However, SBVR doesn't currently address the 'dark world' explicitly. An example of the latter is the 3rd Amendment to the U.S Constitution about Quartering of Soldiers, which says "No Soldier shall, in time of peace be quartered in any house, without the consent of the Owner, nor in time of war, but in a manner to be prescribed by law." * The current definition makes the definition of admonitions/affirmations dependent upon "custom or practice" but provides no way to express that "custom or practice". If context is really important to affirmations/admonitions, then the spec should provide a way to state the context and relate an affirmation/admonition to the context. For example, there might be an affirmation that "an Owner can consent to the quartering of a Soldier in the Owner's house". It seems like that affirmation should be associated with the underlying context that "No Soldier shall, in time of peace be quartered in any house." The notion that SBVR has always focused on in the area of "admonitions/affirmations" are claims of possibility and permission that are unfettered (unrestricted) by any condition(s). I know the signifiers don't reflect that. That's a big part of the problem. The problem has always been coming up with a good signifier for the concept "claim of possibility or permission unfettered (unrestricted) by any condition(s)". * I think the "Categories of Guidance" would be simpler & clearer if affirmations/admonitions were seen as kinds of structural and operative business rules, according to whether the affirmations/admonitions embed necessities or obligations. If you see a sign at a swimming hole that says "No Swimming", that clearly reflects a rule. If you see a sign at another swimming hole that says "Swimming Permitted", would you take that to be a rule? I wouldn't. Where you are free to act or decide as you will, there really is no rule. Note that I am assuming a "light world" in the example. But even in a "dark world", the latter is still an (unfettered) permission, and the former is a rule. It's just that in the "light world" "Swimming Permitted" is not necessary to state, whereas in the "dark world" "No Swimming" is not necessary to state. The distinguishing characteristics of affirmations / admonitions would then be whether they are associated with a context that gives the "default rule". Then the example above about "an Owner can consent ..." would be an affirmative operative business rule associated with a default context about "No soldier shall ...." * A question: consider a statement such as "A USB port may connect up to 4 USB devices". This looks to me like a permission statement, but it doesn't seem to have an underlying "custom or practice" (i.e. a "default context" if you agree with my statements above). If there is no "custom or practice" then this statement can't be an affirmation or admonition. Then what is it? * John said that the statement .a doctor may prescribe medications. "... addresses operational behaviour, but it doesn.t require enforcement - it. not a business rule." Two comments (a) I don't see anything in the definition of rules about "enforcement." Exactly right. Enforcement is relevant only to operative business rules (obligations and prohibitions). (b) John said the statement ".Only a doctor may prescribe medications. is a rule. To me, this depends upon context. If the context is a law that lays down the basic rule "no one can prescribe medications" and then later adds "a doctor may prescribe medications" then the latter statement must be a rule. The full rule is: A person may prescribe medications only if the person is a doctor. This is a *restricted* permission ... a rule. * Regarding consistency between the RuleSpeak and ORM annexes and the normative part of the document: it seems to me that any inconsistency among these does a disservice to readers and undercuts the usefulness and reputation of the spec. It's already hard to understand what the document means, without builtin inconsistencies. The RuleSpeak and ORM annexes are quite different in their content and structure. Could you be a little more specific about which parts of the RuleSpeak annex you find problematic?? Points that (I think we agree) deserve clarification in the spec * The terminology around modalities and the relationships of the modalities. I prefer the terms used by John Hall but it's not clear how to read his table. I find the Stanford diagram clearer. One way to proceed would be to start by defining the 6 basic "modes of thinking" (necessity, contingency, impossibility, obligation, option, prohibition) "Contingency" and "option" may be the correct logic terms, but they have too many connotations it seems to me to be suitable signifiers in the business-facing part of the specification. Please refer to Webster's Unabridged. and then define "modalities" in terms of those "modes of thinking". For example, "possibility" could be defined very straightforwardly as "necessity or contingency". Saying that a possibility could be a necessity doesn't seem very straightforward to me. The trick (on the business-facing side of SBVR) is to be able to explain these notions to business people. * In section 10.1.2, the definition of alethic modality implies that possibility is an alternative to necessity and contingency, whereas the discussion above says that possibility includes both necessity and contingency. Similarly, the definition of deontic modality implies that permission and obligations are alternatives whereas the discussion above says that obligation is a category of permission. In logical formulations, a restricted permission is an obligation, and a restricted possibility is a necessity. But that's intentionally under the covers, at least as I view it. Ron * Distinguishing among restricted and unrestricted permission and possibility statements. * The correspondance between the various forms of guidance statements and the various modalities. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John Hall 08/02/2006 05:47 AM Please respond to john.hall@modelsys.com To Mark H Linehan/Watson/IBM@IBMUS cc SBVR-FTF Subject Re: [SBVR] Response to issue 9475 Hello Mark, Attached is an updated copy of my note.. Regards, To: sbvr-ftf@omg.org Subject: Re: [SBVR] Response to issue 9475 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Wed, 9 Aug 2006 08:52:45 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/09/2006 08:52:46, Serialize complete at 08/09/2006 08:52:46 My comments inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" 08/08/2006 05:18 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-ftf@omg.org cc Subject Re: [SBVR] Response to issue 9475 At 08:31 AM 8/3/2006, Mark H Linehan wrote: John, Thanks for taking the time to respond to my comments. I think I understand better what you mean, but I still don't fully agree that the net result makes sense. Rather than insert further comments within the Word document -- which would make it hard to follow the various threads -- I've tried to summarize my reaction below in two sections: (1) points where the discussion still doesn't make sense to me; (2) points which (I suggest) deserve clarification in the spec. Points that don't make sense to me * Regarding affirmations/admonitions: * John said business operations have to operate in the context of .everything that is not explicitly forbidden is permitted.. I think some rules work this way but that many others start with "all xyz is forbidden" and then layer it with exceptions. Examples are security access control rules, configuration constraints, and some laws that forbid some behavior, but with some exceptions. Correct. Euphemistically, I have always talked about this as the "light world" vs. the "dark world". However, SBVR doesn't currently address the 'dark world' explicitly. Shouldn't this be considered a problem in SBVR? There are many "dark world" examples, as illustrated above. An example of the latter is the 3rd Amendment to the U.S Constitution about Quartering of Soldiers, which says "No Soldier shall, in time of peace be quartered in any house, without the consent of the Owner, nor in time of war, but in a manner to be prescribed by law." * The current definition makes the definition of admonitions/affirmations dependent upon "custom or practice" but provides no way to express that "custom or practice". If context is really important to affirmations/admonitions, then the spec should provide a way to state the context and relate an affirmation/admonition to the context. For example, there might be an affirmation that "an Owner can consent to the quartering of a Soldier in the Owner's house". It seems like that affirmation should be associated with the underlying context that "No Soldier shall, in time of peace be quartered in any house." The notion that SBVR has always focused on in the area of "admonitions/affirmations" are claims of possibility and permission that are unfettered (unrestricted) by any condition(s). I know the signifiers don't reflect that. That's a big part of the problem. The problem has always been coming up with a good signifier for the concept "claim of possibility or permission unfettered (unrestricted) by any condition(s)". I certainly do not see the "unrestricted by any condition" aspect anywhere in the definitions of affirmation & admonition. * I think the "Categories of Guidance" would be simpler & clearer if affirmations/admonitions were seen as kinds of structural and operative business rules, according to whether the affirmations/admonitions embed necessities or obligations. If you see a sign at a swimming hole that says "No Swimming", that clearly reflects a rule. If you see a sign at another swimming hole that says "Swimming Permitted", would you take that to be a rule? I wouldn't. Where you are free to act or decide as you will, there really is no rule. Maybe this concept of "where you are free to act or decide as you will, there is no rule" should be added as a note to the definition of "rule". That would make it clearer. Note that I am assuming a "light world" in the example. But even in a "dark world", the latter is still an (unfettered) permission, and the former is a rule. It's just that in the "light world" "Swimming Permitted" is not necessary to state, whereas in the "dark world" "No Swimming" is not necessary to state. So there needs to be some way to state the context in which rules apply. It seems to me that, without the context, one can't decide whether a statement is a rule or an affirmation/admonition. Moreover, one can't really understand the meaning of a true rule without understanding the "light world" versus "dark world" distinction and which applies for a given rule. The distinguishing characteristics of affirmations / admonitions would then be whether they are associated with a context that gives the "default rule". Then the example above about "an Owner can consent ..." would be an affirmative operative business rule associated with a default context about "No soldier shall ...." * A question: consider a statement such as "A USB port may connect up to 4 USB devices". This looks to me like a permission statement, but it doesn't seem to have an underlying "custom or practice" (i.e. a "default context" if you agree with my statements above). If there is no "custom or practice" then this statement can't be an affirmation or admonition. Then what is it? * John said that the statement .a doctor may prescribe medications. "... addresses operational behaviour, but it doesn.t require enforcement - it. not a business rule." Two comments (a) I don't see anything in the definition of rules about "enforcement." Exactly right. Enforcement is relevant only to operative business rules (obligations and prohibitions). (b) John said the statement ".Only a doctor may prescribe medications. is a rule. To me, this depends upon context. If the context is a law that lays down the basic rule "no one can prescribe medications" and then later adds "a doctor may prescribe medications" then the latter statement must be a rule. The full rule is: A person may prescribe medications only if the person is a doctor. This is a *restricted* permission ... a rule. * Regarding consistency between the RuleSpeak and ORM annexes and the normative part of the document: it seems to me that any inconsistency among these does a disservice to readers and undercuts the usefulness and reputation of the spec. It's already hard to understand what the document means, without builtin inconsistencies. The RuleSpeak and ORM annexes are quite different in their content and structure. Could you be a little more specific about which parts of the RuleSpeak annex you find problematic?? My original issue was about incomplete alignment between various sections of the spec. In particular, the table in F.1.1 references the following statement forms that do not appear in the normative sections: unrestricted permission unrestricted possibility Apparently these are either affirmations or admonitions but one can't tell from the information in the table since the table does not describe the underlying "custom or practice". Furthermore, the definitions of admonition/affirmation do not distinguish permission from possibility. Points that (I think we agree) deserve clarification in the spec * The terminology around modalities and the relationships of the modalities. I prefer the terms used by John Hall but it's not clear how to read his table. I find the Stanford diagram clearer. One way to proceed would be to start by defining the 6 basic "modes of thinking" (necessity, contingency, impossibility, obligation, option, prohibition) "Contingency" and "option" may be the correct logic terms, but they have too many connotations it seems to me to be suitable signifiers in the business-facing part of the specification. Please refer to Webster's Unabridged. I agree that "contingency" and "option" are not very good terms for SBVR. I would suggest alternatives if I could think of any. and then define "modalities" in terms of those "modes of thinking". For example, "possibility" could be defined very straightforwardly as "necessity or contingency". Saying that a possibility could be a necessity doesn't seem very straightforward to me. The trick (on the business-facing side of SBVR) is to be able to explain these notions to business people. Sections 1.1 and 1.2 of the site referenced by John Hall made this clearer to me:http://plato.stanford.edu/entries/logic-deontic/. If you think about, I believe you would agree that things that are necessary are a subset of things that are possible. Similarly, things that are obligatory are a subset of things that are permissible. I absolutely agree with your comment about the need to explain these notions to business people. * In section 10.1.2, the definition of alethic modality implies that possibility is an alternative to necessity and contingency, whereas the discussion above says that possibility includes both necessity and contingency. Similarly, the definition of deontic modality implies that permission and obligations are alternatives whereas the discussion above says that obligation is a category of permission. In logical formulations, a restricted permission is an obligation, and a restricted possibility is a necessity. But that's intentionally under the covers, at least as I view it. This doesn't seem right. I understand a restricted permission as a permission that applies when a condition is met. That doesn't make it an obligation. For example, the statement "A person may prescribe medications only if the person is a doctor" gives permission to those persons who are doctors, but does not represent an obligation. Ditto for restricted possibilities. Ron * Distinguishing among restricted and unrestricted permission and possibility statements. * The correspondance between the various forms of guidance statements and the various modalities. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John Hall 08/02/2006 05:47 AM Please respond to john.hall@modelsys.com To Mark H Linehan/Watson/IBM@IBMUS cc SBVR-FTF Subject Re: [SBVR] Response to issue 9475 Hello Mark, Attached is an updated copy of my note.. Regards, John User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 09 Aug 2006 06:35:10 -0700 Subject: Re. SBVR Issues 9475 and 9945 From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: Re. SBVR Issues 9475 and 9945 Thread-Index: Aca7uKJr4OqaRSerEduR5AARJM+Cgg== Donald, I am finding it difficult to file/follow the dialogs on the two .A & A. (Affirmation & Admonition) Issues, given the two Issue numbers we have going for this subject area. Could we consider bringing Issues 9475 and 9945 together under one umbrella so that we can consider the problem and proposals as a whole? thanks, Keri PS . In addition to the emails that have the issue numbers in their .Subject. line, I ran across an addition set that simply show .Reminder. (i.e., the term from last week.s meeting discussion of these issues) in the subject line. Somehow these need to be threaded with the rest. X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 09 Aug 2006 12:03:24 -0500 To: Mark H Linehan , sbvr-ftf@omg.org From: "Ronald G. Ross" Subject: Re: [SBVR] Response to issue 9475 At 07:52 AM 8/9/2006, Mark H Linehan wrote: My comments inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research If you see a sign at a swimming hole that says "No Swimming", that clearly reflects a rule. If you see a sign at another swimming hole that says "Swimming Permitted", would you take that to be a rule? I wouldn't. Where you are free to act or decide as you will, there really is no rule. Maybe this concept of "where you are free to act or decide as you will, there is no rule" should be added as a note to the definition of "rule". That would make it clearer. Note that I am assuming a "light world" in the example. But even in a "dark world", the latter is still an (unfettered) permission, and the former is a rule. It's just that in the "light world" "Swimming Permitted" is not necessary to state, whereas in the "dark world" "No Swimming" is not necessary to state. So there needs to be some way to state the context in which rules apply. It seems to me that, without the context, one can't decide whether a statement is a rule or an affirmation/admonition. Moreover, one can't really understand the meaning of a true rule without understanding the "light world" versus "dark world" distinction and which applies for a given rule. I think perhaps you might have misunderstood me(?). I'm saying a rule is a rule, and an affirmation/affirmation is an affirmation/admonition, irrespective of whether 'light world" or "dark world" applies. It's just that you need not explicitly call out a rule in a "dark world", and you need not call out an affirmation/admonition in a 'light world". That's consistent, I believe, with the SBVR approach. To: sbvr-ftf@omg.org Subject: Re: [SBVR] Response to issue 9475 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Thu, 10 Aug 2006 17:58:44 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/10/2006 17:58:45, Serialize complete at 08/10/2006 17:58:45 So the categorization of an element of guidance among the choices of {rule, affirmation, admonition} depends upon "custom or practice" that itself cannot be expressed in SBVR. Furthermore, the meaning of an affirmation/admonition depends upon the underlying "custom or practice". This means that one cannot understand an admonition/affirmation that is expressed in SBVR. Seems to me that SBVR should do one of: Provide a way to express "custom or practice". Drop affirmation/admonition as incomplete and not useful without a way to express "custom or practice". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Ronald G. Ross" 08/09/2006 01:03 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-ftf@omg.org cc Subject Re: [SBVR] Response to issue 9475 At 07:52 AM 8/9/2006, Mark H Linehan wrote: My comments inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research If you see a sign at a swimming hole that says "No Swimming", that clearly reflects a rule. If you see a sign at another swimming hole that says "Swimming Permitted", would you take that to be a rule? I wouldn't. Where you are free to act or decide as you will, there really is no rule. Maybe this concept of "where you are free to act or decide as you will, there is no rule" should be added as a note to the definition of "rule". That would make it clearer. Note that I am assuming a "light world" in the example. But even in a "dark world", the latter is still an (unfettered) permission, and the former is a rule. It's just that in the "light world" "Swimming Permitted" is not necessary to state, whereas in the "dark world" "No Swimming" is not necessary to state. So there needs to be some way to state the context in which rules apply. It seems to me that, without the context, one can't decide whether a statement is a rule or an affirmation/admonition. Moreover, one can't really understand the meaning of a true rule without understanding the "light world" versus "dark world" distinction and which applies for a given rule. I think perhaps you might have misunderstood me(?). I'm saying a rule is a rule, and an affirmation/affirmation is an affirmation/admonition, irrespective of whether 'light world" or "dark world" applies. It's just that you need not explicitly call out a rule in a "dark world", and you need not call out an affirmation/admonition in a 'light world". That's consistent, I believe, with the SBVR approach. Ron User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sun, 29 Oct 2006 15:54:36 -0800 Subject: SBVR Issue: Error in sentence on double negation From: John and Keri To: Juergen Boldt , SBVR-issues , SBVR-FTF Thread-Topic: SBVR Issue: Error in sentence on double negation Thread-Index: Acb7tZaL1THR3GeoEdupugARJM+Cgg== Issue name: Error in sentence on double negation Location: SBVR Clause 10.1.1.4, last sentence of the paragraph following Table 10.2 (p. 86). Issue: This sentence has an error. In principle, these rules could be used with double negation to get by with just one alethic modal operator (e.g., ... Proposed Resolution: Change sentence to: In principle, these rules could be used with double negation to get by with just one alethic and one deontic operator (e.g., ... Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 30 Oct 2006 16:36:44 -0800 Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) - updated 3rd graphic From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] issue 9475 -- content and context (initial draft) - updated 3rd graphic Thread-Index: Acb8gij5Z3P/2mh1EduWXgARJM+CggAAnrLj I grabbed the wrong (older) version of the 3rd image. Please use this one instead. ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 30 Oct 2006 16:44:44 -0800 Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] issue 9475 -- content and context (initial draft) Thread-Index: Acb8gij5Z3P/2mh1EduWXgARJM+CggAA5jlk I would like to hear the preference of the Team on the approach for one of the items under this Issue. The Table below reflects, in Col. 4, terms that SBVR uses in discussions of the various modalities. Five of the terms (shown in purple TimesNewRoman) are not defined as SBVR glossary entries. Should we: 1) Add entries for them (in Clause 10)? - or - 2) Consider them as termed concepts that are .defined by adoption. -- i.e., not needing explicit SBVR entries since the terms take their meaning from the Clause-10 cited sources)? Please reply if you have a preference for the approach this Issue will take. regards, ~ Keri To: sbvr-ftf@omg.org Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Tue, 31 Oct 2006 11:04:42 -0500 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 10/31/2006 11:04:44, Serialize complete at 10/31/2006 11:04:44 Keri, My suggestion is that you should add a glossary entry (in clause 10) for "impossibility" because that concept is referenced by the definition of "impossibility business rule statement". The entry should explicitly define "impossibility" as the negation of "possibility" and include the modal equivalence of "necessary that not". This additional entry will eliminate the need to hunt through the text of clause 10 when one really wants to understand "impossibility business rule statement". I suggest that you extend the clause 10 glossary entry for "prohibition" to: * Include a synonym caption for "forbidden" * Extend the definition to make clear that "prohibition" is the negative of obligation, and include the modal equivalence of "obligatory that not". The existing definition of "prohibition" as "nonpermissability" is not helpful since there is no glossary entry for "nonpermissability" and it is not a standard English term. I don't think SBVR needs entries for "non-necessity", "non-obligation" since these terms are not used in clause 12. I would prefer to delete the reference to "nonpermissability" in the existing definition of "prohibition", rather than add a glossary entry for "nonpermission". This would make the definition of "prohibition" parallel (in structure) to those of "permission" and "obligation", neither of which give alternate terms. Alternatively, "nonpermission" or "nonpermissability" should be given via a "Synonym:" caption of "prohibition" rather than be embedded in the definition in a manner not consistent with SBVR style. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John and Keri 10/30/2006 07:44 PM To SBVR-FTF cc Subject Re: [SBVR] issue 9475 -- content and context (initial draft) I would like to hear the preference of the Team on the approach for one of the items under this Issue. The Table below reflects, in Col. 4, terms that SBVR uses in discussions of the various modalities. Five of the terms (shown in purple TimesNewRoman) are not defined as SBVR glossary entries. Should we: 1) Add entries for them (in Clause 10)? - or - 2) Consider them as termed concepts that are .defined by adoption. -- i.e., not needing explicit SBVR entries since the terms take their meaning from the Clause-10 cited sources)? Please reply if you have a preference for the approach this Issue will take. regards, ~ Keri To: sbvr-ftf@omg.org Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Tue, 31 Oct 2006 11:19:29 -0500 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 10/31/2006 11:19:30, Serialize complete at 10/31/2006 11:19:30 On the Distinction of "Proposition of Possibility/Permissibility" from Business Rules I don't understand why "proposition of possibility" and "proposition of permissibility" are not business rules. They are practicable or enforceable. They are under business jurisdiction. Furthermore, a true business rule (per the current definition) must also be a "proposition of possibility" or a "proposition of permissibility" per this argument: * Everything that is necessary is possible. Everything that is obligatory is also permissible. * Therefore a necessity statement such as "it is necessary that the pick-up branch of a one-way rental is not the return branch of that rental" also implies an obligation such as "it is obligatory that the pick-up branch of a one-way rental is not the rental branch of that rental." If the key distinction of "proposition of possibility" and "proposition of permissibility" is the point made in the two note captions, then that key distinction should be part of the definitions of these concepts. On the other hand, if it's ok to make that point in notes, then it would make more sense (to me) to define these concepts as subtypes of business rules. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com To: sbvr-ftf@omg.org Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Tue, 31 Oct 2006 12:17:07 -0500 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 10/31/2006 12:17:09, Serialize complete at 10/31/2006 12:17:09 (An earlier version of this got away from me by mistake. This is the complete version.) On the Distinction of "Proposition of Possibility/Permissibility" from Business Rules I don't understand why "proposition of possibility" and "proposition of permissibility" are not business rules and policies. They are practicable or enforceable. They are under business jurisdiction. And we've recently exchanged many real examples used just like business rules: * "Everyone may travel by plane. Persons on the 'no fly list' may not fly." * (from page 209) "It is possible that a vocabulary is mapped to more than one target package." * .Each EU-Rent financial record may be viewed by each person on the EU-Rent Board. Furthermore, a true business rule (per the current definition) must also be a "proposition of possibility" or a "proposition of permissibility" per this argument: * Everything that is necessary is also possible. Everything that is obligatory is also permissible. * Therefore a necessity statement such as "it is necessary that the pick-up branch of a one-way rental is not the return branch of that rental" also implies a possibility such as "it is possible that the pick-up branch of a one-way rental is not the rental branch of that rental." The former is clearly a statement of a business rule. But the latter is not a statement of a business rule. Furthermore, if one starts with a "statement of possibility" or a "statement of permissibility" and chooses to add a condition (as with "only if") then one has converted from something that is not a business rule statement to something that is a business rule statement. Just by adding a condition. If the key distinction of "proposition of possibility" and "proposition of permissibility" is the point made in the two note captions, then that key distinction should be part of the definitions of these concepts. On the other hand, if it's ok to make that point in notes, then it would make more sense (to me) to define these concepts as subtypes of business rules. On use of Negation in "Proposition of Possibility/Permission" For clarity, I suggest adding a note to the entries for "proposition of possibility" and "proposition of permissibility" to say that the propositions may incorporate negation. Something like: Note: The proposition may be formulated using negation. On Terminology My preferences, for what they're worth: possibility proposition permission proposition possibility statement permission statement Also, why are some of the clause 12.2 statement forms given as plain "statements", and some given as "business rule statements"? I'm in favor of consistency. Also, why do some terms use "permissive" (as in "restricted permissive statement"), some use "permissibility" (as in "proposition of permissibility") and some use "permission" (as in the definition of "restricted permissive statement")? I'm in favor of consistency, and I prefer "permission" as being the usual English word. Similarly, why do some terms use "prohibitive" (as in "prohibitive statement") versus "prohibition"? The reason I'm uptight about consistency is that sometimes slightly different terms are intentionally used in SBVR for different meanings. So a careful reader has to notice such differences. When there is no real distinction (as in "permissibility" versus "permission") then using different terms is a disfavor to the reader. On Examples I suggest that examples should only be given in SBVR-SE. These examples seem to use RuleSpeak (or something else): * (in "statement of possibility") .The notification date/time of a bad experience that occurs during a rental is sometimes after the actual return date/time of the rental.. ["sometimes" is not in SBVR-SE] * (in "statement of possibility") .The notification date/time of a bad experience that occurs during a rental can be after the actual return date/time of the rental.. ["can" is not in SBVR-SE] * (in "statement of permissibility") .The drop-off branch of a rental is sometimes not the return branch of the rental.. ["sometimes" is not in SBVR-SE] * (in "statement of permissibility") .The drop-off branch of a rental need not be the return branch of the rental.. ["need not" is not in SBVR-SE] On Conditions in Restricted Permissive/Possibility Statements The text of "restricted permissive statement" and "restricted possibility business rule statement" say that both of these have a condition such as "only if". Presumably just plain "if" may also be used. I suggest text or a note to make clear that both forms of condition may be used. On Necessity Statements I see that "proposition of possibility" has 3 necessity statements, but "proposition of permissibility" copies just 2 of them. Logically, the 3rd Necessity need not be stated twice. But I think the overall construction would be clearer if the Necessity were given in both places. Plus, a reader who happens to look at just one of the two entries doesn't see all the Necessities. The same discussion applies to the necessities in "obligation statement" versus "prohibitive statement" and "necessity business rule statement" versus "impossibility business rule statement". On Alternative Statement Forms The glossary entries for the following statement types all have notes saying that a rule "... can be expressed as various equivalent kinds of statements by introducing or removing negation." That's fine but the examples also show that equivalent statements can be expressed by introducing or removing conditions. I think the notes should say that too. And they should say what kinds of conditions ("only if" as in the example, or also plain "if"). This affects notes in: obligation statement prohibitive statement restricted permissive statement necessity business rule statement impossibility business rule statement restricted possibility business rule statement -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 31 Oct 2006 09:38:17 -0800 Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) From: John and Keri To: "Ronald G. Ross" , Terry Halpin CC: SBVR-FTF , Mark H Linehan Thread-Topic: [SBVR] issue 9475 -- content and context (initial draft) Thread-Index: Acb9E1k8l6EJCGkGEduXUgARJM+Cgg== On 10/31/06 9:17 AM, "Mark H Linehan" wrote: I don't understand why "proposition of possibility" and "proposition of permissibility" are not business rules and policies. ... Ron, Terry, Perhaps you can address the alternative perspective to what Mark proposes . i.e., to his proposal that the concepts that reflect .possibility. and .permissibility. (permission) be treated as categories of .business rule.. Why did we (SBVR) have it the way it is currently (not categories) and why it should remain that way? ...assuming (of course) that you feel the taxonomy should remain as-is. Thanks ~ Keri X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 31 Oct 2006 15:04:53 -0600 To: John and Keri , Terry Halpin From: "Ronald G. Ross" Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) Cc: SBVR-FTF , Mark H Linehan At 11:38 AM 10/31/2006, John and Keri wrote: On 10/31/06 9:17 AM, "Mark H Linehan" wrote: I don't understand why "proposition of possibility" and "proposition of permissibility" are not business rules and policies. ... The literal reason is that SBVR defines "rule" as a proposition that introduces an obligation or a necessity. The two concepts (elements of guidance) above do not do that. Any *form of expression* that might appear under 12.2 (i.e., *Statement* of an Element of Guidance) that uses the sense of "possibility" or "permissibility", but puts a restriction or condition on it, is considered to be a *rule* in 12.1. You understand that, right? You are also aware that SBVR was developed using a "light world" assumption (anything not explicitly prohibited is permitted). From other discussion, we do recognize 'dark regions' exist (anything not explicitly permitted is prohibited). But that is a separate issue, and in any case, I don't think any of us with experience in the field believes "dark regions" to be anywhere near the majority case for business problems. So, the question then is, what good does it do to go around articulating: "Oh yes, you can do x." "Oh yes, you can decide y any way you like." "Oh yes, you can compute z any way you like." You are simply telling people what can already be done or what already is possible. Why would such things be considered rules? How are they shaping behavior? From a real-world point of view, rules are things that *govern* (i.e., shape behavior, decisions or computations). In essence they always remove some degree of freedom. (Even "the right of free speech must not be abridged" removes a degree of freedom.) Propositions of possibility or permissibility do not remove any degrees of freedom. Is 'you may speak freely" a rule? No, I already could do that. Well, not of course if I am a junior officer speaking to the captain of a ship. But in that context, a rule exists "A junior officer must ask a senior officer for permission to speak freely." That's a rule because it removes a degree of freedom. (Note: I suppose in theory you could consider communication on a ship to be a dark region, but I don't think that would be very practical. If the ship were sinking, I'd like to hear about it even if not authorized explicitly. Business is sort of like that.) Ron P.S. I don't know exactly how or if SBVR will handle "dark world", but in any event, authorizations are still about giving permissions. The real rule remains "you must not do anything you're not explicitly authorized to do." That's a rule that simply removes *all* degrees of freedom. Ron, Terry, Perhaps you can address the alternative perspective to what Mark proposes ­ i.e., to his proposal that the concepts that reflect .possibility. and .permissibility. (permission) be treated as categories of .business rule.. Why did we (SBVR) have it the way it is currently (not categories) and why it should remain that way? ...assuming (of course) that you feel the taxonomy should remain as-is. Thanks ~ Keri X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 31 Oct 2006 15:20:09 -0600 To: John and Keri , Terry Halpin From: "Ronald G. Ross" Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) Cc: SBVR-FTF , Mark H Linehan On 10/31/06 9:17 AM, "Mark H Linehan" wrote: I don't understand why "proposition of possibility" and "proposition of permissibility" are not business rules and policies. ... Ron, Terry, Perhaps you can address the alternative perspective to what Mark proposes ­ i.e., to his proposal that the concepts that reflect .possibility. and .permissibility. (permission) be treated as categories of .business rule.. Why did we (SBVR) have it the way it is currently (not categories) and why it should remain that way? ...assuming (of course) that you feel the taxonomy should remain as-is. Thanks ~ Keri ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All, A few weeks back I had the following exchange with Terry H. I posed the question: "Would you consider the following to be a rule: "A person of any age my hold a bank account." He graciously consented to sharing the exchange with the whole team. I wanted to verify his position on this important question. Here is the entire thread, edited only to remove personal stuff. (I believe he is out of the country at the moment, but perhaps he will jump in.) Ron ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hi Ron Yes, I.d be happy for you to share my response. As a minor refinement to it, the deontic version of a .statement of possibility. is a .statement of permissibility.. Cheers Terry -------------------------------------------------------------------------------- From: Ronald G. Ross [ mailto:rross@brsolutions.com] Sent: Friday, October 13, 2006 12:23 PM To: Terry Halpin Subject: RE: quick question for you At 09:56 AM 10/13/2006, Terry Halpin wrote: Hi Ron I consider your example to be a statement of possibility rather than a rule. Alethic and deontic rules respectively specify something that needs to be the case or that ought to be the case, not something that simply might be the case. Allowing such an example as a rule opens up the possibility of an infinite number of such rules (e.g. A person of any gender/religion/height etc. may hold a bank account). I treat your example as the lack of a constraint or rule, rather than a rule itself. That said, it is often useful to verbalize the lack of a constraint (this is what I call default verbalization . in contrast to positive and negative verbalization). For example, if the fact type .Person was born on Date. is many-to-one, we may verbalize the many-to-one constraint (uniqueness constraint on first role) in positive form as .Each Person was born on at most one Date., in negative form as .It is impossible that the same Person was born on more than one Date., and we may verbalize the lack of a uniqueness constraint on the second role as the default verbalization .It is possible that more than one Person was born on the same Date.. All 3 forms are useful in validating rules with domain experts. Hope this helps Yes, much. (And I agree with all.) Do you mind if I share the message with the SBVR FTF? There has been some [discussion] that "rule" should be broad enough to cover pure permissions and possibilities, and I want to reinforce that at least in this respect, we've got it right. Thanks, Ron Terry -------------------------------------------------------------------------------- From: Ronald G. Ross [ mailto:rross@brsolutions.com] Sent: Wednesday, October 11, 2006 2:22 PM To: Terry Halpin Subject: quick question for you Terry, I have a quick question for you. I don't want to put you on the spot, but your view would be helpful. A little background ... Keri has been analyzing your BRJ installment ( http://www.BRCommunity.com/a2006/b313.html) to suggest some changes to the SBVR definitions related to rules. We've been passing ideas back and forth. Here's the question: Would you consider the following to be a rule: "A person of any age my hold a bank account." Note that it is unrestricted -- not conditional. It is clearly a permission (statement). As far as I can tell, there is no equivalent expression in obligation or prohibition form that would be meaningful to the business. So the bottom line is that I have never considered an unconditional (unrestricted) permission (or possibility) to be a rule. ... Your (quick) thoughts would be extremely valuable (as background). Thanks, Ron X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 31 Oct 2006 15:32:39 -0600 To: Mark H Linehan , sbvr-ftf@omg.org From: "Ronald G. Ross" Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) At 11:17 AM 10/31/2006, Mark H Linehan wrote: (An earlier version of this got away from me by mistake. This is the complete version.) On the Distinction of "Proposition of Possibility/Permissibility" from Business Rules I don't understand why "proposition of possibility" and "proposition of permissibility" are not business rules and policies. They are practicable or enforceable. An Element of Guidance like "A person of any age may hold a bank account" is not enforceable per se. There's nothing that can be broken. However, an Element of Guidance like "A person must not be denied holding a bank account due to their age" *is* (potentially) enforceable. It *can* be broken. Something like that would be the *rule* you'd be looking for in a case such as the above. You see, propositions of permissibility and possibilities just don't bring much to the table, except as 'documentation'. It's the (business) *rules* you want. Ron X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 31 Oct 2006 16:13:55 -0600 To: Mark H Linehan , sbvr-ftf@omg.org From: "Ronald G. Ross" Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) At 11:17 AM 10/31/2006, Mark H Linehan wrote: (An earlier version of this got away from me by mistake. This is the complete version.) On the Distinction of "Proposition of Possibility/Permissibility" from Business Rules I don't understand why "proposition of possibility" and "proposition of permissibility" are not business rules and policies. They are practicable or enforceable. They are under business jurisdiction. And we've recently exchanged many real examples used just like business rules: * "Everyone may travel by plane. Persons on the 'no fly list' may not fly." The first statement just isn't true. The second statement (a rule) contradicts it. In a light world, there would be no reason to give the first statement, because (a) it would be assumed anyway unless a rule restricts it, and (b) there's a rule that contradicts it. In a dark world, why would you turn around and make the world 'light' (with a), then take it away some (with b)? Doesn't make sense either way. Speaking only for myself, we have to assume that business people will try to give us meaning elements of guidance, and when they don't, the tooling will help them catch it (but only within certain bounds). * (from page 209) "It is possible that a vocabulary is mapped to more than one target package." That's already a given. So there is no 'governing' of decisions or computations. (See earlier message.) Not a rule. * .Each EU-Rent financial record may be viewed by each person on the EU-Rent Board. In a light world, that's already a given, so there's no 'governing' of behavior. It's a no-op (to use old assembler language terminology). In a dark world, the real rule is "A EU-Rent financial record must not be viewed (by a person)." That's the *rule*. In a real-world sense, the above 'authorization' is a permission. Isn't that what you do when you authorize ... you give permission?! As discussed in my earlier message, rules always remove degrees of freedom. So it would be inconsistent to call a "rule" something that *gives* (or gives up) a degree of freedom. That's why SBVR doesn't. Furthermore, a true business rule (per the current definition) must also be a "proposition of possibility" or a "proposition of permissibility" per this argument: * Everything that is necessary is also possible. Everything that is obligatory is also permissible. * Therefore a necessity statement such as "it is necessary that the pick-up branch of a one-way rental is not the return branch of that rental" also implies a possibility such as "it is possible that the pick-up branch of a one-way rental is not the rental branch of that rental." The former is clearly a statement of a business rule. But the latter is not a statement of a business rule. I'm not the logician, but something that is *implied* by something is not the same as being *equivalent* to the something. So I don't follow here. Furthermore, if one starts with a "statement of possibility" or a "statement of permissibility" and chooses to add a condition (as with "only if") then one has converted from something that is not a business rule statement to something that is a business rule statement. Just by adding a condition. Well, all I call say is ... in English, we do that all the time. That's one reason SBVR doesn't depend on surface syntax for its fundamental classification (12.1) of elements of guidance. Natural language is slippery stuff. If the key distinction of "proposition of possibility" and "proposition of permissibility" is the point made in the two note captions, then that key distinction should be part of the definitions of these concepts. On the other hand, if it's ok to make that point in notes, then it would make more sense (to me) to define these concepts as subtypes of business rules. On use of Negation in "Proposition of Possibility/Permission" For clarity, I suggest adding a note to the entries for "proposition of possibility" and "proposition of permissibility" to say that the propositions may incorporate negation. Something like: Note: The proposition may be formulated using negation. I'm not the expert here. On Terminology My preferences, for what they're worth: possibility proposition permission proposition possibility statement permission statement I'm good with these. Good symmetry, simplest form of "permission". I like it. Also, why are some of the clause 12.2 statement forms given as plain "statements", and some given as "business rule statements"? I'm in favor of consistency. Not all necessities and impossibilities are 'under business jurisdiction'. Also, why do some terms use "permissive" (as in "restricted permissive statement"), some use "permissibility" (as in "proposition of permissibility") and some use "permission" (as in the definition of "restricted permissive statement")? I'm in favor of consistency, and I prefer "permission" as being the usual English word. Me too. Definitely. Similarly, why do some terms use "prohibitive" (as in "prohibitive statement") versus "prohibition"? Ditto. The reason I'm uptight about consistency is that sometimes slightly different terms are intentionally used in SBVR for different meanings. So a careful reader has to notice such differences. When there is no real distinction (as in "permissibility" versus "permission") then using different terms is a disfavor to the reader. Absolutely correct. Hard enough to get through the document as it is. On Examples I suggest that examples should only be given in SBVR-SE. These examples seem to use RuleSpeak (or something else): * (in "statement of possibility") .The notification date/time of a bad experience that occurs during a rental is sometimes after the actual return date/time of the rental.. ["sometimes" is not in SBVR-SE] * (in "statement of possibility") .The notification date/time of a bad experience that occurs during a rental can be after the actual return date/time of the rental.. ["can" is not in SBVR-SE] * (in "statement of permissibility") .The drop-off branch of a rental is sometimes not the return branch of the rental.. ["sometimes" is not in SBVR-SE] * (in "statement of permissibility") .The drop-off branch of a rental need not be the return branch of the rental.. ["need not" is not in SBVR-SE] SBVR does not standardize or dictate surface syntax for rules. That was a major going-in agreement point. It's important to give examples in more than one surface syntax. IBM wouldn't want the world having to speak only in SBVR-SEese would it?! On Conditions in Restricted Permissive/Possibility Statements The text of "restricted permissive statement" and "restricted possibility business rule statement" say that both of these have a condition such as "only if". Presumably just plain "if" may also be used. I suggest text or a note to make clear that both forms of condition may be used. What does it specifically mean to say "It is permitted that a person hold a bank account if the person is over 18 years of age." Are you expressing a rule or a permission?? In my view highly and unnecessarily ambiguous. On Necessity Statements I see that "proposition of possibility" has 3 necessity statements, but "proposition of permissibility" copies just 2 of them. Logically, the 3rd Necessity need not be stated twice. But I think the overall construction would be clearer if the Necessity were given in both places. Plus, a reader who happens to look at just one of the two entries doesn't see all the Necessities. The same discussion applies to the necessities in "obligation statement" versus "prohibitive statement" and "necessity business rule statement" versus "impossibility business rule statement". I'll have to look at that. On Alternative Statement Forms The glossary entries for the following statement types all have notes saying that a rule "... can be expressed as various equivalent kinds of statements by introducing or removing negation." That's fine but the examples also show that equivalent statements can be expressed by introducing or removing conditions. I think the notes should say that too. Ditto. And they should say what kinds of conditions ("only if" as in the example, or also plain "if"). That gets into surface syntax, and we don't want to go there. Ron This affects notes in: obligation statement prohibitive statement restricted permissive statement necessity business rule statement impossibility business rule statement restricted possibility business rule statement -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 31 Oct 2006 14:22:09 -0800 Subject: Re: [SBVR] issue 9475 -- On the Distinction of "Proposition of Possibility/Permissibility" from Business Rules From: John and Keri To: SBVR-FTF , Mark H Linehan , "Ronald G. Ross" Thread-Topic: [SBVR] issue 9475 -- On the Distinction of "Proposition of Possibility/Permissibility" from Business Rules Thread-Index: Acb9OwEZP3ZekGkuEdungQARJM+Cgg== On 10/31/06 1:20 PM, "Ronald G. Ross" wrote: ...I believe [Terry] is out of the country at the moment, but perhaps he will jump in.) I had forgotten that Terry would be out of the country when I first directed this to Ron & Terry. I directed the question to Terry & Ron (but, of course, anyone is invited to contribute their perspective!) specifically because each had, most recently, expressed a position counter to Mark.s proposal. Here is what Terry had to say to me (in the context of another Issue that I.m working, in the ORM examples annex). ~ Keri ------ Message From: Terry Halpin Date: Wed, 25 Oct 2006 16:24:37 -0600 To: keri Hi Keri That example in the ORM annex (not one of mine) is not a rule in my view (it.s merely the absence of a rule). The ORM verbalizations that start with .It is possible that. or .It is permitted that. are not rules, but merely useful statements designed to check with the domain expert whether or not something is possible or permitted. I call these default-verbalizations, as they state what is possible/permitted in the absence of rules saying otherwise. They are not rules in my book. Please go ahead and correct whatever needs to be corrected in the annex. Cheers Terry User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 31 Oct 2006 14:25:20 -0800 Subject: Re: [SBVR] issue 9475 -- On use of Negation in "Proposition of Possibility/Permission" From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] issue 9475 -- On use of Negation in "Proposition of Possibility/Permission" Thread-Index: Acb9O3LysZCW3GkuEdungQARJM+Cgg== Unless I hear objections/counter positions, I will incorporate this suggestion. ~ Keri On 10/31/06 9:17 AM, "Mark H Linehan" wrote: On use of Negation in "Proposition of Possibility/Permission" For clarity, I suggest adding a note to the entries for "proposition of possibility" and "proposition of permissibility" to say that the propositions may incorporate negation. Something like: Note: The proposition may be formulated using negation. X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 31 Oct 2006 16:31:16 -0600 To: Mark H Linehan , sbvr-ftf@omg.org From: "Ronald G. Ross" Subject: Re: [SBVR] issue 9475 -- content and context (initial draft) At 10:04 AM 10/31/2006, Mark H Linehan wrote: Keri, My suggestion is that you should add a glossary entry (in clause 10) for "impossibility" because that concept is referenced by the definition of "impossibility business rule statement". The entry should explicitly define "impossibility" as the negation of "possibility" and include the modal equivalence of "necessary that not". This additional entry will eliminate the need to hunt through the text of clause 10 when one really wants to understand "impossibility business rule statement". Seems very reasonable. I suggest that you extend the clause 10 glossary entry for "prohibition" to: * Include a synonym caption for "forbidden" Seems reasonable. * Extend the definition to make clear that "prohibition" is the negative of obligation, I'm not the logician, but would everyone be clear on "negative" here (vs. "negation" above)? Makes my head swim. and include the modal equivalence of "obligatory that not". The existing definition of "prohibition" as "nonpermissability" is not helpful since there is no glossary entry for "nonpermissability" and it is not a standard English term. Seems reasonable. I don't think SBVR needs entries for "non-necessity", "non-obligation" since these terms are not used in clause 12. Ditto. I would prefer to delete the reference to "nonpermissability" in the existing definition of "prohibition", rather than add a glossary entry for "nonpermission". This would make the definition of "prohibition" parallel (in structure) to those of "permission" and "obligation", neither of which give alternate terms. I think I agree with that. Alternatively, "nonpermission" or "nonpermissability" should be given via a "Synonym:" caption of "prohibition" rather than be embedded in the definition in a manner not consistent with SBVR style. Are they used in clause 12 or elsewhere? If not, I'd prefer them *not* to be synonyms since they seem awkward (unnatural) constructions to me. Ron P.S. Where are we on the table(s) of negations that was being discussed for clause 10 under the entries for "alethic modality" and "deontic modality". I really want to have those made explicit. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John and Keri 10/30/2006 07:44 PM To SBVR-FTF cc Subject Re: [SBVR] issue 9475 -- content and context (initial draft) I would like to hear the preference of the Team on the approach for one of the items under this Issue. The Table below reflects, in Col. 4, terms that SBVR uses in discussions of the various modalities. Five of the terms (shown in purple TimesNewRoman) are not defined as SBVR glossary entries. Should we: 1) Add entries for them (in Clause 10)? - or - 2) Consider them as termed concepts that are .defined by adoption