Issue 13835: Use of the Signifier "Fact Model" (sbvr-rtf) Source: Business Rule Solutions, LLC (Mr. Ron Ross, rross(at)brsolutions.com) Nature: Revision Severity: Significant Summary: The signifier "fact model" should never be used in SBVR to include behavioral (deontic) elements of guidance. That usage makes no sense to business people, who would not expect anything labeled "fact[s]" to include rules. The origin of the idea meant by "fact model" and "conceptual model" predates any handling of deontic elements of guidance. In other words, deontic elements of guidances were not anticipated or treated by earlier approaches. We are just now catching up to the problem. The current definition of "fact model" (and "conceptual model") is: "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema)". The resolution of this issue must involve at least the following: 1. Selection of a new signifier for the meaning expressed by the above definition. As a strawman, I would propose "Possible World Model". That sounds like something of concern to (only) tool engineers, which is appropriate, since the notion would not interest business people. 2. To suit the signifiers "fact model" and "conceptual model" the current definition must be modified to exclude facts pertaining to deontic elements of guidance. 3. All appearances of these signifiers in SBVR must be reviewed to determine which concept was actually meant. The meaning then given for the signifiers "fact model" and "conceptual model" is one that would be important to business people. If not significant for clause 8 (or 9 or 10), it can be moved to clause 11. Resolution: Revised Text: Actions taken: March 25, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 25 Mar 2009 18:29:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ronald G. Ross Company: Business Rule Solutions, LLC mailFrom: rross@BRSolutions.com Notification: Yes Specification: Use of the Signifier "Fact Model" Section: Clause 8.5 FormalNumber: SBVR Version: 1.0 RevisionDate: 08-01-02 Page: 50 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Comcast Install 1.0; .NET CLR 1.1.4322) Description The signifier "fact model" should never be used in SBVR to include behavioral (deontic) elements of guidance. That usage makes no sense to business people, who would not expect anything labeled "fact[s]" to include rules. The origin of the idea meant by "fact model" and "conceptual model" predates any handling of deontic elements of guidance. In other words, deontic elements of guidances were not anticipated or treated by earlier approaches. We are just now catching up to the problem. The current definition of "fact model" (and "conceptual model") is: "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema)". The resolution of this issue must involve at least the following: 1. Selection of a new signifier for the meaning expressed by the above definition. As a strawman, I would propose "Possible World Model". That sounds like something of concern to (only) tool engineers, which is appropriate, since the notion would not interest business people. 2. To suit the signifiers "fact model" and "conceptual model" the current definition must be modified to exclude facts pertaining to deontic elements of guidance. 3. All appearances of these signifiers in SBVR must be reviewed to determine which concept was actually meant. The meaning then given for the signifiers "fact model" and "conceptual model" is one that would be important to business people. If not significant for clause 8 (or 9 or 10), it can be moved to clause 11. To: sbvr-rtf@omg.org Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments X-KeepSent: DFA10F00:E1E98E39-85257750:004B3D65; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Mon, 28 Jun 2010 09:48:31 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/28/2010 09:48:32, Serialize complete at 06/28/2010 09:48:32 Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron To: sbvr-rtf@omg.org Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments X-KeepSent: B417494D:33F922CB-85257751:0069F2F6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Tue, 29 Jun 2010 15:28:48 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/29/2010 15:28:50, Serialize complete at 06/29/2010 15:28:50 Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron X-Spam-Checker-Version: SpamAssassin 3.3.1-wspice_748 (2010-03-16) on hiltoncluster2.hiltonsmtp.worldspice.net X-Spam-Level: ***** X-Spam-Status: No, score=5.1 Bayes=0.5 required=6.5 autolearn=disabled version=3.3.1-wspice_748 report= * 1.4 TW_SB BODY: Odd Letter Triples with SB * 0.2 HTML_MESSAGE BODY: HTML included in message * 2.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.4 MISSING_MID Missing Message-Id: header X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Jun 2010 15:48:20 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 08:48 AM 6/28/2010, Mark H Linehan wrote: Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Holy cow. I reviewed the SBVR definitions of "vocabulary" and "terminological dictionary". I have a major problem with the former if I understand correctly. However, to keep things focused for this issue, I will raise that as a new issue separately. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". How about: ABC: a set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner, including but not limited to business rules Note: An ABC does not include behavioral elements of guidance. This approach sidesteps the issues of (a) "pre-specification" (prior to 'day one of operation'), (b) inclusion ground facts from actual business operation, and (c) elementary vs. non-elementary fact types. Seems wise to do that. Ron (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron X-Spam-Checker-Version: SpamAssassin 3.2.5-wspice_748 (2008-06-10) on hiltoncluster1.hiltonsmtp.worldspice.net X-Spam-Level: ***** X-Spam-Status: No, score=5.1 Bayes=0.5 required=6.5 autolearn=disabled version=3.2.5-wspice_748 report= * 1.4 MISSING_MID Missing Message-Id: header * 1.4 TW_SB BODY: Odd Letter Triples with SB * 0.2 HTML_MESSAGE BODY: HTML included in message * 2.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Jun 2010 16:21:15 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron To: sbvr-rtf@omg.org Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments X-KeepSent: 36FFB718:59E74F0D-85257752:0060A5CB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Wed, 30 Jun 2010 13:39:41 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/30/2010 13:40:19, Serialize complete at 06/30/2010 13:40:19 Regarding the definition of ABC, I would prefer "ABC: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner." A definition should be complete. It should not rely on a note for part of the meeting -- in this case to exclude operative business rules. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 04:48 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 08:48 AM 6/28/2010, Mark H Linehan wrote: Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Holy cow. I reviewed the SBVR definitions of "vocabulary" and "terminological dictionary". I have a major problem with the former if I understand correctly. However, to keep things focused for this issue, I will raise that as a new issue separately. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". How about: ABC: a set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner, including but not limited to business rules Note: An ABC does not include behavioral elements of guidance. This approach sidesteps the issues of (a) "pre-specification" (prior to 'day one of operation'), (b) inclusion ground facts from actual business operation, and (c) elementary vs. non-elementary fact types. Seems wise to do that. Ron (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron X-Spam-Checker-Version: SpamAssassin 3.2.5-wspice_748 (2008-06-10) on hiltoncluster1.hiltonsmtp.worldspice.net X-Spam-Level: ***** X-Spam-Status: No, score=5.1 Bayes=0.5 required=6.5 autolearn=disabled version=3.2.5-wspice_748 report= * 1.4 MISSING_MID Missing Message-Id: header * 1.4 TW_SB BODY: Odd Letter Triples with SB * 0.2 HTML_MESSAGE BODY: HTML included in message * 2.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Jun 2010 12:48:45 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 12:39 PM 6/30/2010, Mark H Linehan wrote: Regarding the definition of ABC, I would prefer "ABC: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner." A definition should be complete. It should not rely on a note for part of the meeting -- in this case to exclude operative business rules. Yes of course. I could live with that. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 04:48 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 08:48 AM 6/28/2010, Mark H Linehan wrote: Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Holy cow. I reviewed the SBVR definitions of "vocabulary" and "terminological dictionary". I have a major problem with the former if I understand correctly. However, to keep things focused for this issue, I will raise that as a new issue separately. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". How about: ABC: a set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner, including but not limited to business rules Note: An ABC does not include behavioral elements of guidance. This approach sidesteps the issues of (a) "pre-specification" (prior to 'day one of operation'), (b) inclusion ground facts from actual business operation, and (c) elementary vs. non-elementary fact types. Seems wise to do that. Ron (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron To: sbvr-rtf@omg.org Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments X-KeepSent: F962AA6D:085715FC-85257752:00610891; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Wed, 30 Jun 2010 14:05:00 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/30/2010 14:05:00, Serialize complete at 06/30/2010 14:05:00 Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron X-Spam-Checker-Version: SpamAssassin 3.2.5-wspice_748 (2008-06-10) on hiltoncluster1.hiltonsmtp.worldspice.net X-Spam-Level: ***** X-Spam-Status: No, score=5.1 Bayes=0.5 required=6.5 autolearn=disabled version=3.2.5-wspice_748 report= * 1.4 MISSING_MID Missing Message-Id: header * 1.4 TW_SB BODY: Odd Letter Triples with SB * 0.2 HTML_MESSAGE BODY: HTML included in message * 2.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Jun 2010 14:13:32 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments X-KeepSent: 16CBC09A:BD9051DE-85257752:006C56D2; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Wed, 30 Jun 2010 15:51:50 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/30/2010 15:51:56 Ron, I had not realized that you want to use "articulate" as part of the definition of "ABC". If you use "articulate" then I think you are talking about representations, not meanings. In which case, we already have "terminological dictionary". I suggest we add "individual verb concept" to SBVR. Then any concept defined along the lines of "set of concepts ..." should include "individual verb concepts". That completely avoids the issue of whether they are "predefined". And who cares whether another individual verb concept is added to an ABC after the ABC is defined. If the District of Columbia ever becomes a state and thus we add "United States includes District of Columbia" then that concept is now part of the concept system. (If a business cares about when states are included in the United States then it should have a verb concept with 3 roles such as "United States includes Hawaii after August 21 1959".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---06/30/2010 03:17:34 PM---At 01:05 PM 6/30/2010, Mark H Linehan wrote: "Ronald G. Ross" 06/30/2010 03:13 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. >From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron pic51130.gif Subject: RE: [issue 13835 - "Fact Model"] Re: issue 13139 comments Date: Thu, 1 Jul 2010 08:11:12 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [issue 13835 - "Fact Model"] Re: issue 13139 comments Thread-Index: AcsYfvJPzinkPtaaSae3IuwA9t/dAwAWJ5wA From: "Markus Schacher" To: "Mark H Linehan" , X-OriginalArrivalTime: 01 Jul 2010 06:11:33.0987 (UTC) FILETIME=[41733330:01CB18E4] Mark, Regarding .ground facts. I have a reservation: As far as I know, SBVR doesn.t really define the concept denoted by this term. But as far as I understand, the term .ground. is usually used in formal logic to denote terms, literals, and clauses that have no free variables (see e.g. http://plato.stanford.edu/entries/reasoning-automated/). SBVR uses the term .ground fact. in a slightly different, and I think slippery way: here a .ground fact. seems to denote an assertion of an .individual verb concept. (a fact type without variables, i.e. instantiated arguments?) to an .ABC., i.e. a part of the initial population of an .ABC.. However, .being without free variables. and .being asserted. is not the same thing. To illustrate my concern, I.ll use your own example: If .United States includes New York. is part of the initial population of an .ABC., then I agree that this is a .ground fact., but I would be more precise and say that it is an .asserted ground fact.. In the same .ABC. we could also have rules stating .New York is a US city if United States includes New York. and .Zurich is a US city if United States includes Zurich.. By applying simple logical transformations, we get an .ABC. with the following .true. contents: (New York is a US city or not United States includes New York) and (Zurich is a US city or not United States includes Zurich). Although all involved .is a US city. and .includes. facts are ground, none of them is asserted by this .ABC., i.e. none is member of its initial population. Vice versa, one could imagine another .ABC. with the following .true. contents: For all City and Country is true (City is a US city or not Country includes City) and United States includes New York and Switzerland includes Zurich. This corresponds to the rule .City is a US city if Country includes City. and the two asserted ground facts .United States includes New York. and .Switzerland includes Zurich. (this initial population of this .ABC.). Furthermore, even .For all City and Country is true (City is a US city or not Country includes City). could also be considered as a (higher order) ground fact (due to its quantifier making its variables non-free) representing the rule that is also part of the initial population of this .ABC.. But this is a slightly different topic. As a (simple) conclusion, I think SBVR should define the concept denoted by the term .ground fact. (how ever it wishes . compatible or incompatible with other definitions) and then use this concept in a consistent way. Best regards, Markus P.S.: Actually, I.m aware that in the real world, the asserted ground fact .United States includes Zurich. is true as well. From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Mittwoch, 30. Juni 2010 20:05 To: sbvr-rtf@omg.org Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 0EpIm68VM1k1TDS9aenopk1QrTgBTLse6cpMCL4F.Kz9b6daY9BE8Mx_IIiKm_AqSCbJwourd6ALjzClTJ_g9UchfyfSRvo9AfXFsbnJSLBCkBLlGtbYve9eBzaT9ZXa6rFB6CRvhIzWKECCdLps1Jes4NMGHf4_0tKI65IGvlyZjFVoaIwQiJIYAlQj8fiswYO9TNkybuftqhr1i6hX4vJPPny8K8FfynYaBNTghvUCmwerAWFGBxVmtdWjCoFnHrzzbtCa4W3DaxDtfoK6LKQ9Nvm2dpkUVCb2Djd1mA-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Jul 2010 21:48:50 -0500 To: "Markus Schacher" , "Mark H Linehan" , From: "Ronald G. Ross" Subject: [ground facts] RE: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, Just for the record, discussion of "ground facts" is not what this issue is all about. Ron At 01:11 AM 7/1/2010, Markus Schacher wrote: Mark, Regarding .ground facts. I have a reservation: As far as I know, SBVR doesn.t really define the concept denoted by this term. But as far as I understand, the term .ground. is usually used in formal logic to denote terms, literals, and clauses that have no free variables (see e.g. http://plato.stanford.edu/entries/reasoning-automated/). SBVR uses the term .ground fact. in a slightly different, and I think slippery way: here a .ground fact. seems to denote an assertion of an .individual verb concept. (a fact type without variables, i.e. instantiated arguments?) to an .ABC., i.e. a part of the initial population of an .ABC.. However, .being without free variables. and .being asserted. is not the same thing. To illustrate my concern, I.ll use your own example: If .United States includes New York. is part of the initial population of an .ABC., then I agree that this is a .ground fact., but I would be more precise and say that it is an .asserted ground fact.. In the same .ABC. we could also have rules stating .New York is a US city if United States includes New York. and .Zurich is a US city if United States includes Zurich.. By applying simple logical transformations, we get an .ABC. with the following .true. contents: (New York is a US city or not United States includes New York) and (Zurich is a US city or not United States includes Zurich). Although all involved .is a US city. and .includes. facts are ground, none of them is asserted by this .ABC., i.e. none is member of its initial population. Vice versa, one could imagine another .ABC. with the following .true. contents: For all City and Country is true (City is a US city or not Country includes City) and United States includes New York and Switzerland includes Zurich. This corresponds to the rule .City is a US city if Country includes City. and the two asserted ground facts .United States includes New York. and .Switzerland includes Zurich. (this initial population of this .ABC.). Furthermore, even .For all City and Country is true (City is a US city or not Country includes City). could also be considered as a (higher order) ground fact (due to its quantifier making its variables non-free) representing the rule that is also part of the initial population of this .ABC.. But this is a slightly different topic. As a (simple) conclusion, I think SBVR should define the concept denoted by the term .ground fact. (how ever it wishes . compatible or incompatible with other definitions) and then use this concept in a consistent way. Best regards, Markus P.S.: Actually, I.m aware that in the real world, the asserted ground fact .United States includes Zurich. is true as well. From: Mark H Linehan [ mailto:mlinehan@us.ibm.com] Sent: Mittwoch, 30. Juni 2010 20:05 To: sbvr-rtf@omg.org Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 9hC0tvoVM1kxpwdb1UPoHdIVQ7e2MbJ1n_Me701WLGBPln8m8kBTjpxVeMHZgz8eXChcpGuGxuZjJV2DESXLwfiD4xV5DHymfcIdFk_3GUVkambU9FjABJd1g2dlmjB7sOBOB49Ey7lIFEKLdNXs7cB2RVh30ESfOh_eEmPQO6kl2H.ozCjzUR0cF0zkIDjgdWEWSdlsE_cKh9WEqOD8Nn_IwywJitFbTe9j2g-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jun 2010 18:54:57 -0500 To: sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: n1f471QVM1lEVZEdASmoAoHSQbaXK8dCZTl4SlADSkmHApy zUkff6hOcI0OJlfdQ6AQk3UduGOB0gxyq6o53r5sj_7t1wuoOHbqdwofMLyF .kxFzGZ.bY9D2GlnvShe36mJmyVGiavewX5NCAk7L3Kg1Zj2CAZCHo5CP92i Is_h0x4rc.pdcah7lHchELQEvnLzWp8UR3bLkJOPJZTgns3v9z1HWVb7lIfI raMn4FjR1IfVh95Alv4rRapIBplXzWaWYfWFtPCpz8jIW.eudI1n5XDavzWz xmADPGnJugA-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Aug 2010 12:21:48 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments X-SpamInfo: FortiGuard - AntiSpam ip, connection black ip 68.142.198.206 All, We've made good progress on this important issue (too). I would like to get the discussion re-kindled, and move toward a resolution. Here is a quick summary of recent discussion. * I think it's clear we are missing an crucial concept and signifier in Clause 11. I called it ABC in the post-Minneapolis discussion. It's clear to me that ABC is *not* "fact model" as used in the ORM community and elsewhere. This conflation has been causing significant difficulty. * From a Clause 11, business-facing perspective, the concept and signifier "body of shared concepts" is not exactly on-target. * "Concept system" and its definition should be adopted from ISO for ABC. * I proposed the following additional Clause-11-centric definition for ABC: "set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner". (Note: An ABC does not include behavioral elements of guidance.) * I said, "Let's not be coy about the important thing we're getting at here." As soon as you recognize "(a basis for) articulating" in the definition of ABC, it puts a whole new light on the matter. Therefore I proposed "verbal model" and/or "verbalization model" as synonyms. (These are what I use.) Ron P.S. Important parts of the post-Minneapolis discussion can be found in the e-mails below. At 05:14 PM 6/30/2010, Ronald G. Ross wrote: At 02:51 PM 6/30/2010, Mark H Linehan wrote: Ron, I had not realized that you want to use "articulate" as part of the definition of "ABC". If you use "articulate" then I think you are talking about representations, not meanings. In which case, we already have "terminological dictionary". Here's what the latest version of the definition says: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner It says "... as a basis for ...". A concept system *does* provide a 'basis for' articulating in a consistent manner ... a very fundamental basis ... even across multiple languages. (And what other purpose does it serve??) I suggest we add "individual verb concept" to SBVR. Then any concept defined along the lines of "set of concepts ..." should include "individual verb concepts". That completely avoids the issue of whether they are "predefined". I don't have an opinion about that. And who cares whether another individual verb concept is added to an ABC after the ABC is defined. If the District of Columbia ever becomes a state and thus we add "United States includes District of Columbia" then that concept is now part of the concept system. (If a business cares about when states are included in the United States then it should have a verb concept with 3 roles such as "United States includes Hawaii after August 21 1959".) This is not really an engineering question. Businesses must be aware that they generally need to develop or adopt some concept system(s) in order to start in business. It doesn't just suddenly 'happen'. And it's the special part of the they must coordinate and administer going forth as a matter of continuing governance. It's not just your everyday mountain of ground facts. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---06/30/2010 03:17:34 PM---At 01:05 PM 6/30/2010, Mark H Linehan wrote: "Ronald G. Ross" 06/30/2010 03:13 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize noR .).cte ,selur ssenisub fo noitazilabrev rof sledom troppus ot evres ot ,.e.i( RVBS fo citsiretcarahc gnihsiugnitsid ,lartnec a si taht tey ,yralubacov a ni gnieb smrof epyt tcaf fo kniht yllamron t'nod elpoep taht si ssenlufesu s'tI ."yralubacov" fo mynonys a sa denifed eb ylbaborp nac "yralubacov ssenisub derutcurtS" sgninaem derahs fo ydob a nihtiw stpecnoc sserpxe ot egaugnal elgnis a morf nward yliramirp smrof epyt tcaf dna snoitangised fo tes :noitinifeD yralubacov :si RVBS ni "yralubacov" fo noitinifed tnerruc ehT .)drager taht ni "metsys tpecnoc" htiw ngila ton seod ti ,.e.i( es rep sgninaem tsuj ton ,sgninaem fo noitatneserper sessapmocne "yralubacov ssenisub derutcurtS" :etoN .).cte ,stpecnoc brev sah ,.e.i( *derutcurts* si taht eno ,yralubacov fo dnik laiceps a gnitaerc tuoba si 11 esualC taht To: sbvr-rtf@omg.org Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments X-KeepSent: 93DD6FD3:D3AC19D3-85257789:004C2422; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Tue, 24 Aug 2010 10:05:23 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 08/24/2010 10:05:24, Serialize complete at 08/24/2010 10:05:24 What bothers me about this is this is the addition of another "organizing concept" when I think clauses 11 & 12 already have too many: vocabulary, business vocabulary, terminological dictionary, body of shared concepts, body of shared meanings, body of shared guidance, rulebook. Plus we have "conceptual schema" and "fact model". I think we shouldn't add more such concepts without rationalizing the ones we already have. I think the word "articulating" is wrong in an additional definition for "concept system". I could agree with ".... structured as a basis for conceptualizing business communications ...". Concept systems are about concepts, not about articulating or verbalizing the concepts. For this reason, I think the synonyms "verbal model" and/or "verbalization model" are inappropriate for "concept system". I think "concept system" could replace (or become the primary term for) the existing "body of shared meanings" because I think the latter is only intended to include definitional (not behavioral) guidance. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com From: "Ronald G. Ross" To: Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org Date: 08/20/2010 01:21 PM Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments -------------------------------------------------------------------------------- All, We've made good progress on this important issue (too). I would like to get the discussion re-kindled, and move toward a resolution. Here is a quick summary of recent discussion. * I think it's clear we are missing an crucial concept and signifier in Clause 11. I called it ABC in the post-Minneapolis discussion. It's clear to me that ABC is *not* "fact model" as used in the ORM community and elsewhere. This conflation has been causing significant difficulty. * From a Clause 11, business-facing perspective, the concept and signifier "body of shared concepts" is not exactly on-target. * "Concept system" and its definition should be adopted from ISO for ABC. * I proposed the following additional Clause-11-centric definition for ABC: "set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner". (Note: An ABC does not include behavioral elements of guidance.) * I said, "Let's not be coy about the important thing we're getting at here." As soon as you recognize "(a basis for) articulating" in the definition of ABC, it puts a whole new light on the matter. Therefore I proposed "verbal model" and/or "verbalization model" as synonyms. (These are what I use.) Ron P.S. Important parts of the post-Minneapolis discussion can be found in the e-mails below. At 05:14 PM 6/30/2010, Ronald G. Ross wrote: At 02:51 PM 6/30/2010, Mark H Linehan wrote: Ron, I had not realized that you want to use "articulate" as part of the definition of "ABC". If you use "articulate" then I think you are talking about representations, not meanings. In which case, we already have "terminological dictionary". Here's what the latest version of the definition says: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner It says "... as a basis for ...". A concept system *does* provide a 'basis for' articulating in a consistent manner ... a very fundamental basis ... even across multiple languages. (And what other purpose does it serve??) I suggest we add "individual verb concept" to SBVR. Then any concept defined along the lines of "set of concepts ..." should include "individual verb concepts". That completely avoids the issue of whether they are "predefined". I don't have an opinion about that. And who cares whether another individual verb concept is added to an ABC after the ABC is defined. If the District of Columbia ever becomes a state and thus we add "United States includes District of Columbia" then that concept is now part of the concept system. (If a business cares about when states are included in the United States then it should have a verb concept with 3 roles such as "United States includes Hawaii after August 21 1959".) This is not really an engineering question. Businesses must be aware that they generally need to develop or adopt some concept system(s) in order to start in business. It doesn't just suddenly 'happen'. And it's the special part of the they must coordinate and administer going forth as a matter of continuing governance. It's not just your everyday mountain of ground facts. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---06/30/2010 03:17:34 PM---At 01:05 PM 6/30/2010, Mark H Linehan wrote: "Ronald G. Ross" 06/30/2010 03:13 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize noR .).cte ,selur ssenisub fo noitazilabrev rof sledom troppus ot evres ot ,.e.i( RVBS fo citsiretcarahc gnihsiugnitsid ,lartnec a si taht tey ,yralubacov a ni gnieb smrof epyt tcaf fo kniht yllamron t'nod elpoep taht si ssenlufesu s'tI ."yralubacov" fo mynonys a sa denifed eb ylbaborp nac "yralubacov ssenisub derutcurtS" sgninaem derahs fo ydob a nihtiw stpecnoc sserpxe ot egaugnal elgnis a morf nward yliramirp smrof epyt tcaf dna snoitangised fo tes :noitinifeD yralubacov :si RVBS ni "yralubacov" fo noitinifed tnerruc ehT .)drager taht ni "metsys tpecnoc" htiw ngila ton seod ti ,.e.i( es rep sgninaem tsuj ton ,sgninaem fo noitatneserper sessapmocne "yralubacov ssenisub derutcurtS" :etoN .).cte ,stpecnoc brev sah ,.e.i( *derutcurts* si taht eno ,yralubacov fo dnik laiceps a gnitaerc tuoba si 11 esualC taht X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 7i1Pyx8VM1nTZTrkNBV6AI_OjMxrv0eoOMSobzjrJ0DcYod f0x_VEb5SJ2kooF2abK28hTCyvNzob0leu_lwIfRkZltVya6M4dMKc9jVnUh vZKUdGJQy.GPXe_1XhJFVhX4PEfQffFIajcAeu4SOEuXYsC7PpfwNtYs_Hoy bP9Y9yx8CeC6Sag3uNXB9R4G467OmpzsZaZiR.W3omJ04a3c2xjn9NcchuvC h5N8eupE8Yi5eI0SioKPQOoD4kkz3NO1oQLoCdM.kpm5FrL1bkVNFDOiZYJ. ub4x0c8P6EIc- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Aug 2010 12:28:17 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 09:05 AM 8/24/2010, Mark H Linehan wrote: What bothers me about this is this is the addition of another "organizing concept" when I think clauses 11 & 12 already have too many: vocabulary, business vocabulary, terminological dictionary, body of shared concepts, body of shared meanings, body of shared guidance, rulebook. Plus we have "conceptual schema" and "fact model". I think we shouldn't add more such concepts without rationalizing the ones we already have. Mark, It's a good point. I don't disagree. But how do we do that? New issue? (Read on.) I think the word "articulating" is wrong in an additional definition for "concept system". I could agree with ".... structured as a basis for conceptualizing business communications ...". "Conceptualize business communications" doesn't sound right. A business communication isn't really 'conceptualized' ... it's ... well ... articulated. Otherwise, there's no way to get your concepts across. Aside from the definition, do you disagree with the statement that a concept system serves as a basis for articulating business communications? Does it (can it) serve any other purpose? As an alternative suggestion, how about "verbal model" or "verbalization model" as a synonym(s) for "business vocabulary"? (That's articulation.) I feel very strongly that we are not projecting the full purpose and power of SBVR. What we mean by "business vocabulary" is far more than what it sounds like. Concept systems are about concepts, not about articulating or verbalizing the concepts. For this reason, I think the synonyms "verbal model" and/or "verbalization model" are inappropriate for "concept system". I think "concept system" could replace (or become the primary term for) the existing "body of shared meanings" because I think the latter is only intended to include definitional (not behavioral) guidance. I don't disagree. For Clause 11 and 12 purposes (only), I don't really see a need for a term that covers *all* meanings in a semantic community. For *business-facing* purposes, there are concepts and there are elements of guidance. Business people don't abstract elements of guidances into 'meanings'. That seems wonky to me. Over-abstraction for business people. As far as they would go would be to recognize (or not be perturbed by) definitional elements of guidance being part of a concept system. It's a very good point, actually. Clause 11 really needs to stay focused on its purpose and perspective. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com From: "Ronald G. Ross" To: Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org Date: 08/20/2010 01:21 PM Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, We've made good progress on this important issue (too). I would like to get the discussion re-kindled, and move toward a resolution. Here is a quick summary of recent discussion. * I think it's clear we are missing an crucial concept and signifier in Clause 11. I called it ABC in the post-Minneapolis discussion. It's clear to me that ABC is *not* "fact model" as used in the ORM community and elsewhere. This conflation has been causing significant difficulty. * From a Clause 11, business-facing perspective, the concept and signifier "body of shared concepts" is not exactly on-target. * "Concept system" and its definition should be adopted from ISO for ABC. * I proposed the following additional Clause-11-centric definition for ABC: "set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner". (Note: An ABC does not include behavioral elements of guidance.) * I said, "Let's not be coy about the important thing we're getting at here." As soon as you recognize "(a basis for) articulating" in the definition of ABC, it puts a whole new light on the matter. Therefore I proposed "verbal model" and/or "verbalization model" as synonyms. (These are what I use.) Ron P.S. Important parts of the post-Minneapolis discussion can be found in the e-mails below. At 05:14 PM 6/30/2010, Ronald G. Ross wrote: At 02:51 PM 6/30/2010, Mark H Linehan wrote: Ron, I had not realized that you want to use "articulate" as part of the definition of "ABC". If you use "articulate" then I think you are talking about representations, not meanings. In which case, we already have "terminological dictionary". Here's what the latest version of the definition says: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner It says "... as a basis for ...". A concept system *does* provide a 'basis for' articulating in a consistent manner ... a very fundamental basis ... even across multiple languages. (And what other purpose does it serve??) I suggest we add "individual verb concept" to SBVR. Then any concept defined along the lines of "set of concepts ..." should include "individual verb concepts". That completely avoids the issue of whether they are "predefined". I don't have an opinion about that. And who cares whether another individual verb concept is added to an ABC after the ABC is defined. If the District of Columbia ever becomes a state and thus we add "United States includes District of Columbia" then that concept is now part of the concept system. (If a business cares about when states are included in the United States then it should have a verb concept with 3 roles such as "United States includes Hawaii after August 21 1959".) This is not really an engineering question. Businesses must be aware that they generally need to develop or adopt some concept system(s) in order to start in business. It doesn't just suddenly 'happen'. And it's the special part of the they must coordinate and administer going forth as a matter of continuing governance. It's not just your everyday mountain of ground facts. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---06/30/2010 03:17:34 PM---At 01:05 PM 6/30/2010, Mark H Linehan wrote: "Ronald G. Ross" 06/30/2010 03:13 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize noR .).cte ,selur ssenisub fo noitazilabrev rof sledom troppus ot evres ot ,.e.i( RVBS fo citsiretcarahc gnihsiugnitsid ,lartnec a si taht tey ,yralubacov a ni gnieb smrof epyt tcaf fo kniht yllamron t'nod elpoep taht si ssenlufesu s'tI ."yralubacov" fo mynonys a sa denifed eb ylbaborp nac "yralubacov ssenisub derutcurtS" sgninaem derahs fo ydob a nihtiw stpecnoc sserpxe ot egaugnal elgnis a morf nward yliramirp smrof epyt tcaf dna snoitangised fo tes :noitinifeD yralubacov :si RVBS ni "yralubacov" fo noitinifed tnerruc ehT .)drager taht ni "metsys tpecnoc" htiw ngila ton seod ti ,.e.i( es rep sgninaem tsuj ton ,sgninaem fo noitatneserper sessapmocne "yralubacov ssenisub derutcurtS" :etoN .).cte ,stpecnoc brev sah ,.e.i( *derutcurts* si taht eno ,yralubacov fo dnik laiceps a gnitaerc tuoba si 11 esualC taht Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments X-KeepSent: 5261DACA:6E9AC510-85257789:0062D7A8; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Tue, 24 Aug 2010 14:20:41 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 08/24/2010 14:20:45 Ron, Regarding rationalizing the various clause 11 & 12 "organizing concepts" -- issues 12540-12542 bring up several of the problems here. These issues are about 2 years old ... Regarding "do you disagree with the statement that a concept system serves as a basis for articulating business communications? Does it (can it) serve any other purpose?" I think the main purpose of a concept system is to *think about* ("model") the concepts. I have often had the experience of having a concept that I struggle to articulate. Within this group, we've also had that experience. We often grope for the concept, and then debate what the designation should be. I think the same thing happens in businesses. For example, a marketing person might recognize various patterns in sales statistics. Each pattern is a concept and the set of patterns is a concept system. Then the marketing person thinks up names for the concepts, like "soccer moms" or something. Then the marketing person articulates the concepts (i.e. the sales pattern) and the names to other marketers. My point is that concepts can exist without any articulation, or even without names. Regarding "how about "verbal model" or "verbalization model" as a synonym(s) for "business vocabulary"" -- I think these terms would work better for "vocabulary". "Business vocabulary" is just a "vocabulary" with the distinguishing characteristic that it is "under business jurisdiction". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---08/24/2010 01:28:52 PM---At 09:05 AM 8/24/2010, Mark H Linehan wrote: What bothers me about this is this is the addition of a From: "Ronald G. Ross" To: Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org Date: 08/24/2010 01:28 PM Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments -------------------------------------------------------------------------------- At 09:05 AM 8/24/2010, Mark H Linehan wrote: What bothers me about this is this is the addition of another "organizing concept" when I think clauses 11 & 12 already have too many: vocabulary, business vocabulary, terminological dictionary, body of shared concepts, body of shared meanings, body of shared guidance, rulebook. Plus we have "conceptual schema" and "fact model". I think we shouldn't add more such concepts without rationalizing the ones we already have. Mark, It's a good point. I don't disagree. But how do we do that? New issue? (Read on.) I think the word "articulating" is wrong in an additional definition for "concept system". I could agree with ".... structured as a basis for conceptualizing business communications ...". "Conceptualize business communications" doesn't sound right. A business communication isn't really 'conceptualized' ... it's ... well ... articulated. Otherwise, there's no way to get your concepts across. Aside from the definition, do you disagree with the statement that a concept system serves as a basis for articulating business communications? Does it (can it) serve any other purpose? As an alternative suggestion, how about "verbal model" or "verbalization model" as a synonym(s) for "business vocabulary"? (That's articulation.) I feel very strongly that we are not projecting the full purpose and power of SBVR. What we mean by "business vocabulary" is far more than what it sounds like. Concept systems are about concepts, not about articulating or verbalizing the concepts. For this reason, I think the synonyms "verbal model" and/or "verbalization model" are inappropriate for "concept system". I think "concept system" could replace (or become the primary term for) the existing "body of shared meanings" because I think the latter is only intended to include definitional (not behavioral) guidance. I don't disagree. For Clause 11 and 12 purposes (only), I don't really see a need for a term that covers *all* meanings in a semantic community. For *business-facing* purposes, there are concepts and there are elements of guidance. Business people don't abstract elements of guidances into 'meanings'. That seems wonky to me. Over-abstraction for business people. As far as they would go would be to recognize (or not be perturbed by) definitional elements of guidance being part of a concept system. It's a very good point, actually. Clause 11 really needs to stay focused on its purpose and perspective. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com From: "Ronald G. Ross" To: Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org Date: 08/20/2010 01:21 PM Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, We've made good progress on this important issue (too). I would like to get the discussion re-kindled, and move toward a resolution. Here is a quick summary of recent discussion. * I think it's clear we are missing an crucial concept and signifier in Clause 11. I called it ABC in the post-Minneapolis discussion. It's clear to me that ABC is *not* "fact model" as used in the ORM community and elsewhere. This conflation has been causing significant difficulty. * From a Clause 11, business-facing perspective, the concept and signifier "body of shared concepts" is not exactly on-target. * "Concept system" and its definition should be adopted from ISO for ABC. * I proposed the following additional Clause-11-centric definition for ABC: "set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner". (Note: An ABC does not include behavioral elements of guidance.) * I said, "Let's not be coy about the important thing we're getting at here." As soon as you recognize "(a basis for) articulating" in the definition of ABC, it puts a whole new light on the matter. Therefore I proposed "verbal model" and/or "verbalization model" as synonyms. (These are what I use.) Ron P.S. Important parts of the post-Minneapolis discussion can be found in the e-mails below. At 05:14 PM 6/30/2010, Ronald G. Ross wrote: At 02:51 PM 6/30/2010, Mark H Linehan wrote: Ron, I had not realized that you want to use "articulate" as part of the definition of "ABC". If you use "articulate" then I think you are talking about representations, not meanings. In which case, we already have "terminological dictionary". Here's what the latest version of the definition says: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner It says "... as a basis for ...". A concept system *does* provide a 'basis for' articulating in a consistent manner ... a very fundamental basis ... even across multiple languages. (And what other purpose does it serve??) I suggest we add "individual verb concept" to SBVR. Then any concept defined along the lines of "set of concepts ..." should include "individual verb concepts". That completely avoids the issue of whether they are "predefined". I don't have an opinion about that. And who cares whether another individual verb concept is added to an ABC after the ABC is defined. If the District of Columbia ever becomes a state and thus we add "United States includes District of Columbia" then that concept is now part of the concept system. (If a business cares about when states are included in the United States then it should have a verb concept with 3 roles such as "United States includes Hawaii after August 21 1959".) This is not really an engineering question. Businesses must be aware that they generally need to develop or adopt some concept system(s) in order to start in business. It doesn't just suddenly 'happen'. And it's the special part of the they must coordinate and administer going forth as a matter of continuing governance. It's not just your everyday mountain of ground facts. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---06/30/2010 03:17:34 PM---At 01:05 PM 6/30/2010, Mark H Linehan wrote: "Ronald G. Ross" 06/30/2010 03:13 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize noR .).cte ,selur ssenisub fo noitazilabrev rof sledom troppus ot evres ot ,.e.i( RVBS fo citsiretcarahc gnihsiugnitsid ,lartnec a si taht tey ,yralubacov a ni gnieb smrof epyt tcaf fo kniht yllamron t'nod elpoep taht si ssenlufesu s'tI ."yralubacov" fo mynonys a sa denifed eb ylbaborp nac "yralubacov ssenisub derutcurtS" sgninaem derahs fo ydob a nihtiw stpecnoc sserpxe ot egaugnal elgnis a morf nward yliramirp smrof epyt tcaf dna snoitangised fo tes :noitinifeD yralubacov :si RVBS ni "yralubacov" fo noitinifed tnerruc ehT .)drager taht ni "metsys tpecnoc" htiw ngila ton seod ti ,.e.i( es rep sgninaem tsuj ton ,sgninaem fo noitatneserper sessapmocne "yralubacov ssenisub derutcurtS" :etoN .).cte ,stpecnoc brev sah ,.e.i( *derutcurts* si taht eno ,yralubacov fo dnik laiceps a gnitaerc tuoba si 11 esualC taht X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: EWEYXswVM1nsQeXWSXgwgib_pCz1bVNZh4xUW_3YD1RdMY. 4xrf9fl2mPtH3NCtlEY_ZRpU23W3JkIRCk8LH5lVYQveO78SJK1yfjWrNeSE VJmZfCmiFHlG9Xq6X.GsWFJNJxMadSJonyEo735ZPZUOad7HW0kdxynvhqgL NORSGssG4D13uE2Oys0_jwXL9AK4Ou06UN79thsZG88lvFlmU82PUNAVSTbN 0UA3ooaW.S68S6ml9q6j68.ORNkWelOnaR26KDuTQgTc- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Aug 2010 13:34:00 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:20 PM 8/24/2010, Mark H Linehan wrote: Ron, Regarding rationalizing the various clause 11 & 12 "organizing concepts" -- issues 12540-12542 bring up several of the problems here. These issues are about 2 years old ... Regarding "do you disagree with the statement that a concept system serves as a basis for articulating business communications? Does it (can it) serve any other purpose?" I think the main purpose of a concept system is to *think about* ("model") the concepts. I have often had the experience of having a concept that I struggle to articulate. Within this group, we've also had that experience. We often grope for the concept, and then debate what the designation should be. I think the same thing happens in businesses. For example, a marketing person might recognize various patterns in sales statistics. Each pattern is a concept and the set of patterns is a concept system. Then the marketing person thinks up names for the concepts, like "soccer moms" or something. Then the marketing person articulates the concepts (i.e. the sales pattern) and the names to other marketers. My point is that concepts can exist without any articulation, or even without names. Sure. I think (hope) we all agree that. But I'd say if we didn't have to articulate them (in a business), we wouldn't have to think so hard about them in the first place. But I think we're probably all on the same page. Regarding "how about "verbal model" or "verbalization model" as a synonym(s) for "business vocabulary"" -- I think these terms would work better for "vocabulary". "Business vocabulary" is just a "vocabulary" with the distinguishing characteristic that it is "under business jurisdiction". Sounds right. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---08/24/2010 01:28:52 PM---At 09:05 AM 8/24/2010, Mark H Linehan wrote: What bothers me about this is this is the addition of a From:"Ronald G. Ross" To:Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org Date:08/24/2010 01:28 PM Subject:Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 09:05 AM 8/24/2010, Mark H Linehan wrote: What bothers me about this is this is the addition of another "organizing concept" when I think clauses 11 & 12 already have too many: vocabulary, business vocabulary, terminological dictionary, body of shared concepts, body of shared meanings, body of shared guidance, rulebook. Plus we have "conceptual schema" and "fact model". I think we shouldn't add more such concepts without rationalizing the ones we already have. Mark, It's a good point. I don't disagree. But how do we do that? New issue? (Read on.) I think the word "articulating" is wrong in an additional definition for "concept system". I could agree with ".... structured as a basis for conceptualizing business communications ...". "Conceptualize business communications" doesn't sound right. A business communication isn't really 'conceptualized' ... it's ... well ... articulated. Otherwise, there's no way to get your concepts across. Aside from the definition, do you disagree with the statement that a concept system serves as a basis for articulating business communications? Does it (can it) serve any other purpose? As an alternative suggestion, how about "verbal model" or "verbalization model" as a synonym(s) for "business vocabulary"? (That's articulation.) I feel very strongly that we are not projecting the full purpose and power of SBVR. What we mean by "business vocabulary" is far more than what it sounds like. Concept systems are about concepts, not about articulating or verbalizing the concepts. For this reason, I think the synonyms "verbal model" and/or "verbalization model" are inappropriate for "concept system". I think "concept system" could replace (or become the primary term for) the existing "body of shared meanings" because I think the latter is only intended to include definitional (not behavioral) guidance. I don't disagree. For Clause 11 and 12 purposes (only), I don't really see a need for a term that covers *all* meanings in a semantic community. For *business-facing* purposes, there are concepts and there are elements of guidance. Business people don't abstract elements of guidances into 'meanings'. That seems wonky to me. Over-abstraction for business people. As far as they would go would be to recognize (or not be perturbed by) definitional elements of guidance being part of a concept system. It's a very good point, actually. Clause 11 really needs to stay focused on its purpose and perspective. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com From: "Ronald G. Ross" To: Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org Date: 08/20/2010 01:21 PM Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, We've made good progress on this important issue (too). I would like to get the discussion re-kindled, and move toward a resolution. Here is a quick summary of recent discussion. * I think it's clear we are missing an crucial concept and signifier in Clause 11. I called it ABC in the post-Minneapolis discussion. It's clear to me that ABC is *not* "fact model" as used in the ORM community and elsewhere. This conflation has been causing significant difficulty. * From a Clause 11, business-facing perspective, the concept and signifier "body of shared concepts" is not exactly on-target. * "Concept system" and its definition should be adopted from ISO for ABC. * I proposed the following additional Clause-11-centric definition for ABC: "set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner". (Note: An ABC does not include behavioral elements of guidance.) * I said, "Let's not be coy about the important thing we're getting at here." As soon as you recognize "(a basis for) articulating" in the definition of ABC, it puts a whole new light on the matter. Therefore I proposed "verbal model" and/or "verbalization model" as synonyms. (These are what I use.) Ron P.S. Important parts of the post-Minneapolis discussion can be found in the e-mails below. At 05:14 PM 6/30/2010, Ronald G. Ross wrote: At 02:51 PM 6/30/2010, Mark H Linehan wrote: Ron, I had not realized that you want to use "articulate" as part of the definition of "ABC". If you use "articulate" then I think you are talking about representations, not meanings. In which case, we already have "terminological dictionary". Here's what the latest version of the definition says: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner It says "... as a basis for ...". A concept system *does* provide a 'basis for' articulating in a consistent manner ... a very fundamental basis ... even across multiple languages. (And what other purpose does it serve??) I suggest we add "individual verb concept" to SBVR. Then any concept defined along the lines of "set of concepts ..." should include "individual verb concepts". That completely avoids the issue of whether they are "predefined". I don't have an opinion about that. And who cares whether another individual verb concept is added to an ABC after the ABC is defined. If the District of Columbia ever becomes a state and thus we add "United States includes District of Columbia" then that concept is now part of the concept system. (If a business cares about when states are included in the United States then it should have a verb concept with 3 roles such as "United States includes Hawaii after August 21 1959".) This is not really an engineering question. Businesses must be aware that they generally need to develop or adopt some concept system(s) in order to start in business. It doesn't just suddenly 'happen'. And it's the special part of the they must coordinate and administer going forth as a matter of continuing governance. It's not just your everyday mountain of ground facts. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---06/30/2010 03:17:34 PM---At 01:05 PM 6/30/2010, Mark H Linehan wrote: "Ronald G. Ross" 06/30/2010 03:13 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address groundnoR .suoivbo ebyaM .yas ot gniyrt m'I lla s'tahT .tey deneppah t'nsah tI .321 redro secalp ZYX remotsuc taht wonk t'nac uoY .meht wonk *t'nac* uoy os ,tey noitarepo ni t'nsi ssenisub ehT .tey wonk t'nod uoy stcaf (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM To sbvr-rtf@omg.org cc Subject [issue 13835 - "Fact Model"] Re: issue 13139 comments All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in busine noR .).cte ,selur ssenisub fo noitazilabrev rof sledom troppus ot evres ot ,.e.i( RVBS fo citsiretcarahc gnihsiugnitsid ,lartnec a si taht tey ,yralubacov a ni gnieb smrof epyt tcaf fo kniht yllamron t'nod elpoep taht si ssenlufesu s'tI ."yralubacov" fo mynonys a sa denifed eb ylbaborp nac "yralubacov ssenisub derutcurtS" sgninaem derahs fo ydob a nihtiw stpecnoc sserpxe ot egaugnal elgnis a morf nward yliramirp smrof epyt tcaf dna snoitangised fo tes :noitinifeD yralubacov :si RVBS ni "yralubacov" fo noitinifed tnerruc ehT .)drager taht ni "metsys tpecnoc" htiw ngila ton seod ti ,.e.i( es rep sgninaem tsuj ton ,sgninaem fo noitatneserper sessapmocne "yralubacov ssenisub derutcurtS" :etoN .).cte ,stpecnoc brev sah ,.e.i( *derutcurts* si taht eno ,yralubacov fo dnik laiceps a gnitaerc tuoba si 11 esualC taht ezisahpme ot deen ew ,)"metsys tpecnoc" fo noitinifed eht ot refer( OSI ekiL .seiralubacov gnipoleved rof yralubacov a sa debircsed neeb sah RVBS -- si flesti RVBS tahw s'taht ,ylraelC - "yralubacov ssenisub derutcurts" .smynonys eb dluohs "ledom noitazilabrev" ro/dna "ledom labrev" ,OSI morf detpoda si "metsys tpecnoc" fI :etoN tnemetats labrev a ekam : sdrow ni gnihtemos etats ot : 2 :]"ezilabrev"[ sdrow htiw od ot gnivah ro ni gnitsisnoc : sdrow ot gnitaler ro fo : a 2 :]"labrev"[ DUWM .esoprup taht rof llew krow yehT .esoprup taht rof snoitatneserp ym ni "ledom noitazilabrev" ro "ledom labrev" gnisu neeb evah I ,os ro raey tsap eht roF .)sledom atad dna smargaid ssalc sa hcus selbareviled 'larutcurts' rehto dna( "ledom tcaf" morf CBA sehsiugnitsid yllatnedicni taht eno ,reifingis etairporppa na gnitceles yb drager taht ni tnemeveihca euqinu s'RVBS ezisahpme dluohs eW .detanidrooc dna derutpac eb nac scitnames lluf rieht taht rennam hcus si noitacinummoc ssenisub fo smrof rehto dna stnemetats elur ssenisub fo noisserpxe eht elbane ot si RVBS fo laog ,evitcnitsid deedni ,rojam A - "ledom noitazilabrev" ro "ledom labrev" ?CBA fo ecnesse eht )a(erutpac tseb )s(reifingis tahW ?ta mia yllaer 11 esualc RVBS seod tahW .01 ).os si siht rehtehw em ot raelc ton si s'tI( .)?(stcaf yratnemele-non lla dna yna sa llew sa ,"snoitarepo ssenisub fo eno yad" retfa detaerc stcaf dnuorg ssapmocne dluow noitinifed OSI eht taht deugra eb thgim tI * .)"meht gnoma snoitaler ... "( sepyt tcaf yranu ot yldneirf mees t'nseod noitinifed OSI ehT * :snoitcejbo elbissoP .noitinifed eht yb derevoc eb dluow selur lanoitinifed taht niatniam ot eerf leef nac ew kniht I ,selur redisnoc ton did OSI ecniS .CBA ot esolc eb ot smees "metsys tpecnoC" meht gnoma snoitaler eht ot gnidrocca derutcurts )1.2.3( stpecnoc fo tes stpecnoc fo metsys metsys tpecnoc 11.2.3 ."metsys tpecnoc" mret eht sah OSI ?dellac eb CBA nac tahW .9 ).stcaf yratnemele-non lla dna yna sa llew sa ,"snoitarepo ssenisub fo eno yad" retfa detaerc stcaf dnuorg ssapmocne dluow ti ,noitidda nI( .CBA elbaiv a gnihsilbatse ni devlovni ylniatrec tsom era selur lanoitinifed tuB .seno cihtela gnidulcni ,snoitinifed morf yletarapes denifed ecnadiug fo stnemele lla sedulcxe "stpecnoc derahs fo ydoB" sgninaem derahs fo ydob a nihtiw stpecnoc eht fo lla :noitinifeD stpecnoc derahs fo ydob ).stcaf yratnemele-non lla dna yna sa llew sa ,"snoitarepo ssenisub fo eno yad" retfa detaerc stcaf dnuorg ssapmocne dluow ti ,noitidda nI( .ecnadiug fo stnemele citnoed sedulcni "sgninaem derahs fo ydoB" ytinummoc citnames nevig a ni gnidnatsrednu derahs a si ereht hcihw rof ecnadiug fo stnemele dna stpecnoc fo tes :noitinifeD sgninaem derahs fo ydob :gniwollof eht era 11 esualC ni CBA rof krow t'nod "gninaem derahs fo ydob" dna "gninaem derahs fo ydob" taht snosaer ehT .8 ).stcaf yratnemele-non lla dna yna sa llew sa ,"snoitarepo ssenisub fo eno yad" retfa detaerc stcaf dnuorg ssapmocne dluow ti ,noitidda nI( ."stcaf" sa "selur" llac dluow elpoep ssenisub tahw staert niaga tI .ecnadiug fo stnemele citnoed sedulcni osla "ledom tcaF" )amehcs lautpecnoc eht fo stpecnoc eht ylno gnisu snoitalumrof citnames yb denifed( stcaf fo tes a ,dlrow elbissop eno rof ,dna amehcs lautpecnoc a fo noitanibmoc :noitinifeD LF ledom tcaf :gniwollof eht si 11 esualC ni CBA rof krow t'nseod "ledom tcaf" taht nosaer ehT .7 ."... taht elur a s'ereht tcaf a s'tI" ,ekil sgniht yas t'nod ylpmis elpoep ssenisuB .saedi gnicaf-ssenisub fo noitalfnoc elbatpeccanu yletelpmoc a secudorp tahT ."stcaf" sa "selur" llac dluow elpoep ssenisub tahw staert osla tI .ecnadiug fo stnemele citnoed sedulcni "amehcs lautpecnoC" dlrow elbissop hcae ni yrotagilbo dna ,elbissimrep ,yrassecen ,elbissop si tahw fo )meht enifed taht snoitalumrof citnames htiw( stcaf dna stpecnoc fo noitanibmoc :noitinifeD LF amehcs lautpecnoc :gniwollof eht si 11 esualC ni CBA rof krow t'nseod "amehcs lautpecnoc" taht nosaer ehT .6 ."snoitarepo ssenisub fo eno yad" fo ecnavda ni yficeps t'ndluoc uoy stcaf dnuorg yna * .reveostahw ecnadiug fo stnemele citnoed yna * ... edulcni *ton* dluow CBA nA .sepyt tcaf yratnemele edulcni yliramirp * .sdeen ssenisub gnivlove desab stpecnoc fo tes yrassecen taht ot snoisnetxe yna edulcni ,retfaereht * .)"snoitarepo ssenisub fo eno yad"( worromot ss X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: I9hHoLAVM1ltHbyAW.AuuxTJs3SQAFGPDrRqn9A5qzFN0QX igPDRDBX8ZMH2Zjn6k3rXtB75NtX2TXrnYWFvz38U9lFglUPaXLL8i8AZLbn kxSZJhbfJM0SN7ZycBD.rA1s1hY2TA1zpEBdTHEeA7HavTnoLfUJr_A2RE63 3zj3TYAVpZlSl8V2cexfLjR4dZsTgBfLmllV7uyE4vxmckhqv99YK9q.FqE8 XeTP3D9EA2FwfJl1alQ5n84_DcZdiNRwHFkFlnWzTLXVuRe8GyiQhh1Ruv2v 61vaujYfWaw-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Oct 2010 11:16:02 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, In preparation for Friday's discussion, I am recirculating my summary write-up from Tuesday Aug 24 along with comments since that time inserted like this. Earlier discussion including the original post-Minneapolis write-up can be found after that. Ron ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All, We've made good progress on this important issue (too). I would like to get the discussion re-kindled, and move toward a resolution. Here is a quick summary of recent discussion. * I think it's clear we are missing an crucial concept and signifier in Clause 11. I called it ABC in the post-Minneapolis discussion. It's clear to me that ABC is *not* "fact model" as used in the ORM community and elsewhere. This conflation has been causing significant difficulty. * From a Clause 11, business-facing perspective, the concept and signifier "body of shared concepts" is not exactly on-target. Note: This is primarily because alethic elements of guidance can be recognized as separate from concepts in Clause 11. * "Concept system" and its definition should be adopted from ISO for ABC. At 09:05 AM 8/24/2010, Mark H Linehan wrote: What bothers me about this is this is the addition of another "organizing concept" when I think clauses 11 & 12 already have too many: vocabulary, business vocabulary, terminological dictionary, body of shared concepts, body of shared meanings, body of shared guidance, rulebook. Plus we have "conceptual schema" and "fact model". I think we shouldn't add more such concepts without rationalizing the ones we already have. ME: Mark, It's a good point. I don't disagree. But how do we do that? New issue? At 09:05 AM 8/24/2010, Mark H Linehan wrote: I think "concept system" could replace (or become the primary term for) the existing "body of shared meanings" because I think the latter is only intended to include definitional (not behavioral) guidance. ME: I don't disagree. For Clause 11 and 12 purposes (only), I don't really see a need for a term that covers *all* meanings in a semantic community. For *business-facing* purposes, there are concepts and there are elements of guidance. Business people don't abstract elements of guidances into 'meanings'. That seems wonky to me. Over-abstraction for business people. As far as they would go would be to recognize (or not be perturbed by) definitional elements of guidance being part of a concept system. It's a very good point, actually. Clause 11 really needs to stay focused on its purpose and perspective. * I proposed the following additional Clause-11-centric definition for ABC: "set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner". (Note: An ABC does not include behavioral elements of guidance.) At 09:05 AM 8/24/2010, Mark H Linehan wrote I think the word "articulating" is wrong in an additional definition for "concept system". I could agree with ".... structured as a basis for conceptualizing business communications ...". ME: "Conceptualize business communications" doesn't sound right. A business communication isn't really 'conceptualized' ... it's ... well ... articulated. Otherwise, there's no way to get your concepts across. How about [NEW]: "set of concepts along with definitional elements of guidance created and structured to organize understanding of the business and to serve as a basis for consistent communication" * I said, "Let's not be coy about the important thing we're getting at here." As soon as you recognize "(a basis for) articulating" in the definition of ABC, it puts a whole new light on the matter. Therefore I proposed "verbal model" and/or "verbalization model" as synonyms. (These are what I use.) MARK LINEHAN [At 01:20 PM 8/24/2010]: Regarding "how about "verbal model" or "verbalization model" as a synonym(s) for "business vocabulary" -- I think these terms would work better for "vocabulary". "Business vocabulary" is just a "vocabulary" with the distinguishing characteristic that it is "under business jurisdiction". ME: I agree. Ron P.S. Important parts of the post-Minneapolis discussion can be found in the e-mails below. At 05:14 PM 6/30/2010, Ronald G. Ross wrote: At 02:51 PM 6/30/2010, Mark H Linehan wrote: Ron, I had not realized that you want to use "articulate" as part of the definition of "ABC". If you use "articulate" then I think you are talking about representations, not meanings. In which case, we already have "terminological dictionary". Here's what the latest version of the definition says: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner It says "... as a basis for ...". A concept system *does* provide a 'basis for' articulating in a consistent manner ... a very fundamental basis ... even across multiple languages. (And what other purpose does it serve??) I suggest we add "individual verb concept" to SBVR. Then any concept defined along the lines of "set of concepts ..." should include "individual verb concepts". That completely avoids the issue of whether they are "predefined". I don't have an opinion about that. And who cares whether another individual verb concept is added to an ABC after the ABC is defined. If the District of Columbia ever becomes a state and thus we add "United States includes District of Columbia" then that concept is now part of the concept system. (If a business cares about when states are included in the United States then it should have a verb concept with 3 roles such as "United States includes Hawaii after August 21 1959".) This is not really an engineering question. Businesses must be aware that they generally need to develop or adopt some concept system(s) in order to start in business. It doesn't just suddenly 'happen'. And it's the special part of the they must coordinate and administer going forth as a matter of continuing governance. It's not just your everyday mountain of ground facts. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---06/30/2010 03:17:34 PM---At 01:05 PM 6/30/2010, Mark H Linehan wrote: "Ronald G. Ross" 06/30/2010 03:13 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address ground facts you don't know yet. The business isn't in operation yet, so you *can't* know them. You can't know that customer XYZ places order 123. It hasn't happened yet. That's all I'm trying to say. Maybe obvious. Ron (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM Here is the original message (in easier to read form) from 6/25/2010. All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-09-26_04:2011-09-26,2011-09-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1109260133 From: keri Subject: SBVR Issue 13835 -- Draft Resolution Date: Mon, 26 Sep 2011 06:59:16 -0700 To: sbvr-rtf@omg.org, Donald Chapin X-Mailer: Apple Mail (2.1084) All, Attached is the Resolution write-up, as discussed at last week's meeting. Issue 13835-Resolution v2.doc Keri Disposition: Resolved OMG Issue No: 13835 Title: Use of Signifier.Fact Model. Source: Ronald G. Ross, Business Rule Solutions, LLC (Resolution write-up by Keri Anderson Healy) Summary: The signifier "fact model" should never be used in SBVR to include behavioral (deontic) elements of guidance. That usage makes no sense to business people, who would not expect anything labeled "fact[s]" to include rules. The origin of the idea meant by "fact model" and "conceptual model" predates any handling of deontic elements of guidance. In other words, deontic elements of guidances were not anticipated or treated by earlier approaches. We are just now catching up to the problem. The current definition of "fact model" (and "conceptual model") is: "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema)". The resolution of this issue must involve at least the following: 1. Selection of a new signifier for the meaning expressed by the above definition. As a strawman, I would propose "Possible World Model". That sounds like something of concern to (only) tool engineers, which is appropriate, since the notion would not interest business people. 2. To suit the signifiers "fact model" and "conceptual model" the current definition must be modified to exclude facts pertaining to deontic elements of guidance. 3. All appearances of these signifiers in SBVR must be reviewed to determine which concept was actually meant. The meaning then given for the signifiers "fact model" and "conceptual model" is one that would be important to business people. If not significant for clause 8 (or 9 or 10), it can be moved to clause 11 Resolution: With .fact model. (and .conceptual model.) moved to Clause 10 (Issue 13138), the confusion from the use of .fact model. is removed. (The definition and uses of .fact model. and .conceptual model. are now more closely associated with the Clause 10 material, which is where these terms are used.) This issue adopts the ISO concept .concept system. for the business-facing concept that was confused with .fact model. (and .conceptual model.). The synonym .concept model. is provided for those whose practice employs that terminology. Revised Text: REMOVE from Clause 11.1.1 (Figure 11.1): and REPLACE with: ADD to Clause 11.1.1.2 (immediately before the entry for "body of shared concepts") this new content: concept system Source: ISO 1087-1 (English) (3.2.11) ['concept system'] Definition: set of concepts structured according to the relations among them Synonym: concept model Note: Subclause 11.1.5 (.Concept System Structure.) and subclause 8.1.1.1 (.About Concepts.) provide detail for what is meant by .the relations among [concepts]. in this Definition. concept system includes concept Definition: the concept fits within the structural relationships of the concept system Synonymous Form: concept is included in concept system For the existing entry .body of shared concepts. (Clause 11.1.1.2) add to the end of the definition ., structured according to the relations among them. so that it reads: Definition: all of the concepts within a body of shared meanings, structured according to the relations among them To the existing entry .body of shared concepts. (Clause 11.1.1.2) add this: General Concept: concept system REMOVE the existing entry for .body of shared concepts includes concept. (Clause 11.1.1.2) and all of its detail. Disposition: Resolved To: sbvr-rtf@omg.org Subject: Re: SBVR Issue 13835 -- Draft Resolution X-KeepSent: 14284807:3D849A77-8525791A:003FD119; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 29 Sep 2011 07:45:44 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 09/29/2011 07:45:44, Serialize complete at 09/29/2011 07:45:44 Some questions: With the addition of "concept system", it seems like a semantic community should share understanding of a concept system, not just individual concepts. The distinction between a "concept system" and a "body of shared concepts" is unclear. The only difference that I can see is that the concepts in "body of shared concepts" come from a "body of shared meanings". Apparently the concepts in "concept system" don't come from any particular source (??) If that's the distinction we mean, we should say so. But is it a useful distinction. Following on #2, we appear to have 3 closely-related containers ("concept system", "body of shared meanings", and "body of shared concepts"). These are in addition to "vocabulary", "terminological dictionary", "business vocabulary", and "vocabulary namespace". Plus the containers on the behavioral guidance side. Taken as a whole, this is confusing and apparently redundant. Why make it worse? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: keri To: sbvr-rtf@omg.org, Donald Chapin Date: 09/26/2011 10:06 AM Subject: SBVR Issue 13835 -- Draft Resolution -------------------------------------------------------------------------------- All, Attached is the Resolution write-up, as discussed at last week's meeting. [attachment "Issue 13835-Resolution v2.doc" deleted by Mark H Linehan/Watson/IBM] Keri Date: Thu, 29 Sep 2011 11:04:51 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: SBVR Issue 13835 -- Draft Resolution X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p8TF4uFZ013419 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1317913498.7025@iIsX3GIVDsujO/esDlXLAA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark H Linehan wrote: 3. Following on #2, we appear to have 3 closely-related containers ("concept system", "body of shared meanings", and "body of shared concepts"). These are in addition to "vocabulary", "terminological dictionary", "business vocabulary", and "vocabulary namespace". Plus the containers on the behavioral guidance side. Taken as a whole, this is confusing and apparently redundant. Why make it worse? For the record, this is why SBVR is useless for the exchange of 'vocabularies'. There is no agreement on which of these collections a business vocabulary management tool should exchange. Compare with SKOS, which has one structure with some (not many) content options. The consequence of supporting every special nuance is defeating interoperability. We would suggest that SBVR needs terminological dictionary, rulebook and fact model, and the rest are academic. I think the deeper problem in this area is that SBVR does not clearly distinguish between - terms for things that might be exchanged among vocabulary management tools and rules management tools - terms that are only used in defining the concepts in the first category, and are not part of exchanges per se We had similar discussions in Date/Time about the 'foundational concepts' and the 'business usage concepts'. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: keri To: sbvr-rtf@omg.org, Donald Chapin Date: 09/26/2011 10:06 AM Subject: SBVR Issue 13835 -- Draft Resolution ------------------------------------------------------------------------ All, Attached is the Resolution write-up, as discussed at last week's meeting. [attachment "Issue 13835-Resolution v2.doc" deleted by Mark H Linehan/Watson/IBM] Keri -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-09-30_05:2011-09-30,2011-09-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1109300177 From: keri Subject: SBVR Issue 13835 -- Draft Resolution v3 Date: Fri, 30 Sep 2011 10:06:13 -0700 To: sbvr-rtf@omg.org, Donald Chapin X-Mailer: Apple Mail (2.1084) All, Attached is the updated Resolution write-up, as discussed in today's meeting. Keri All, Attached is the updated Resolution write-up, as discussed in today's meeting. Issue 13835-Resolution v3.doc Keri Disposition: Resolved OMG Issue No: 13835 Title: Use of Signifier.Fact Model. Source: Ronald G. Ross, Business Rule Solutions, LLC (Resolution write-up by Keri Anderson Healy) Summary: The signifier "fact model" should never be used in SBVR to include behavioral (deontic) elements of guidance. That usage makes no sense to business people, who would not expect anything labeled "fact[s]" to include rules. The origin of the idea meant by "fact model" and "conceptual model" predates any handling of deontic elements of guidance. In other words, deontic elements of guidances were not anticipated or treated by earlier approaches. We are just now catching up to the problem. The current definition of "fact model" (and "conceptual model") is: "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema)". The resolution of this issue must involve at least the following: 1. Selection of a new signifier for the meaning expressed by the above definition. As a strawman, I would propose "Possible World Model". That sounds like something of concern to (only) tool engineers, which is appropriate, since the notion would not interest business people. 2. To suit the signifiers "fact model" and "conceptual model" the current definition must be modified to exclude facts pertaining to deontic elements of guidance. 3. All appearances of these signifiers in SBVR must be reviewed to determine which concept was actually meant. The meaning then given for the signifiers "fact model" and "conceptual model" is one that would be important to business people. If not significant for clause 8 (or 9 or 10), it can be moved to clause 11 Resolution: With .fact model. (and .conceptual model.) moved to Clause 10 (Issue 13138), the confusion that came from the use of .fact model. is removed. (The definition and uses of .fact model. and .conceptual model. are now all contained within the Clause 10 material, which is where these terms are used.) This Resolution adds the synonym .concept model. to the existing concept 'body of shared concepts" to provide a business-friendly term. Revised Text: REMOVE from Clause 11.1.1 (Figure 11.1): and REPLACE with: For the existing entry .body of shared concepts. (Clause 11.1.1.2) add ., structured according to the relations among them. to the end of the definition so that it reads: Definition: all of the concepts within a body of shared meanings, structured according to the relations among them To the existing entry .body of shared concepts. (Clause 11.1.1.2) add these two items: Synonym: concept model Note: Subclause 11.1.5 (.Concept System Structure.) and subclause 8.1.1.1 (.About Concepts.) provide detail for what is meant by .the relations among [concepts]. in this Definition. Disposition: Resolved Ron