Issue 9613: Chapters 8,9,11,12 (sbvr-ftf) Source: Business Semantics Ltd. (Mr. Donald R. Chapin, donald.chapin@btinternet.com donald.chapin@businesssemantics.com) Nature: Clarification Severity: Significant Summary: "Explicitly Stated SBVR Architectural Principles for Relationships among 'Definitions' 'Rules' and 'Semantic Formulations'" Issue Statement: The lack of an explicitly stated, concise set of SBVR architectural principles regarding the relationship of 'definitions' 'rules' and 'semantic formulations' is causing much needless SBVR-FTF discussion around related topics. If this lack is causing a problem for the creators of SBVR, then it's going to be even harder for people in the rest of the world to understand and agree on this critical aspect of SBVR. A (strawman) set of SBVR architectural principles needs to be explicitly stated in SBVR as follows: 1. 'Definitions' and 'rules' are not the same thing as 'semantic formulations'. 2. 'Semantic formulations' structure the meaning of 'definitions' and of 'rules'. 3. The meaning of an 'operative business rule' is structured by a 'semantic formulation' that introduces an 'obligation'. 4. The meaning of a 'structural rule / definitional rule / definitional criterion' is structured by a 'semantic formulation' that introduces a 'necessity' which itself means 'true by definition'. 5. 'Intensional definitions' are made up of definitional components of two types: a. a 'more general concept' b. one or more 'delimiting' components 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. 9. For a given discrete meaning there is a set of 'semantic formulations' that give form to its meaning. 10. There is a one-to-one relationship between an 'operative business rule' and the set of 'semantic formulations' of its discrete meaning. 11. There is a one-to-one relationship between a 'delimiting' component of an 'intensional definition' and the set of 'semantic formulations' of its discrete meaning. Resolution: This Issue is too big to resolve in one piece. It has been broken into manageable pieces as, and replaced by, Issues 10571, 10572,, 10573, 10574, 10575, 10576 Revised Text: None - replaced by Issues 10571, 10572,, 10573, 10574, 10575, 10576 which together are a duplicate of it. Actions taken: May 10, 2006: received issue January 15, 2008: closed issue Discussion: More basic Issues had to be resolved first, and we ran out of time End of Annotations:===== X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 10 May 2006 15:37:06 -0500 To: sbvr-ftf@omg.org From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue At 12:32 PM 5/10/2006, Juergen Boldt wrote: Donald, A couple of quick clarifications please ... Description Issue Name: "Explicitly Stated SBVR Architectural Principles for Relationships among 'Definitions' 'Rules' and 'Semantic Formulations'" Issue Statement: The lack of an explicitly stated, concise set of SBVR architectural principles regarding the relationship of 'definitions' 'rules' and 'semantic formulations' is causing much needless SBVR-FTF discussion around related topics. If this lack is causing a problem for the creators of SBVR, then it's going to be even harder for people in the rest of the world to understand and agree on this critical aspect of SBVR. A (strawman) set of SBVR architectural principles needs to be explicitly stated in SBVR as follows: 1. 'Definitions' and 'rules' are not the same thing as 'semantic formulations'. 2. 'Semantic formulations' structure the meaning of 'definitions' and of 'rules'. 3. The meaning of an 'operative business rule' is structured by a 'semantic formulation' that introduces an 'obligation'. 4. The meaning of a 'structural rule / definitional rule / definitional criterion' is structured by a 'semantic formulation' that introduces a 'necessity' which itself means 'true by definition'. Is an essential part of your proposal to say "true by definition", or could it say "taken as true" (or something)? (There are already a lot of uses of "definition" floating around.) 5. 'Intensional definitions' are made up of definitional components of two types: a. a 'more general concept' Can this "more general concept" be given as an expression, or does it simply have to be designated? If an expression is permitted, isn't that a definition? In any event, here is an example what I must be able to do cleanly and directly: Blacklisted Customer (Definition): some party the company prefers not to do business with because of a history of slow and/or non-payment Structural Rule: A Customer is considered Blacklisted if all the following are true: * The customer has placed at least 5 orders in the past 2 years. * Each order was not paid within 60 days of the date placed. * The order amount of each order is over $100. Does your proposal support that? b. one or more 'delimiting' components What status are you giving "'delimiting' component" in your proposal? I don't find that it currently exists in SBVR(?). Are you proposing giving it some official status? 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' What status are you giving "definitional criterion" in your proposal? I don't find that it currently exists in SBVR(?). Are you proposing giving it some official status? 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). Does an explicit, visible example of these three alternative approaches exist? If not, how would it be illustrated/presented? 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. 9. For a given discrete meaning there is a set of 'semantic formulations' that give form to its meaning. 10. There is a one-to-one relationship between an 'operative business rule' and the set of 'semantic formulations' of its discrete meaning. 11. There is a one-to-one relationship between a 'delimiting' component of an 'intensional definition' and the set of 'semantic formulations' of its discrete meaning. Thanks, Ron Juergen Boldt Director, Member Services 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 10 May 2006 16:18:12 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0WBrINNzKFxTDQXmm/OkIFt6qMwAKbxXQ From: "Baisley, Donald E" To: X-OriginalArrivalTime: 10 May 2006 23:18:12.0635 (UTC) FILETIME=[021B36B0:01C67488] Some comments on Donald.s architectural principles. > 1. 'Definitions' and 'rules' are not the same thing as 'semantic formulations'. Correct. > 2. 'Semantic formulations' structure the meaning of 'definitions' and of 'rules'. Semantic formulations formulate the meanings of definitions and rule statements. In SBVR, a rule does not have a meaning. Rather, a rule is a meaning. Semantic formulations also formalize definitions and rule statements. > 3. The meaning of an 'operative business rule' is structured by a 'semantic formulation' that introduces an 'obligation'. An operative business rule is formulated by a semantic formulation. The rule introduces an obligation. > 4. The meaning of a 'structural rule / definitional rule / definitional criterion' is structured by a 'semantic formulation' that introduces a 'necessity' which itself means 'true by definition'. A structural business rule is formulated by a semantic formulation. The rule introduces a necessity. I don.t know what is meant by .definitional criterion.. > 5. 'Intensional definitions' are made up of definitional components of two types: a. a 'more general concept' b. one or more 'delimiting' components An intensional definition represents a concept by describing the intension of a concept through stating a more general concept and one or more delimiting characteristics. > 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' This is not clear to me. I have not found structural rules to be part of definitions. > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). Is this saying that structural rule statements exist as parts of definitions rather than as first class rules? I understood that putting a structural rule statement next to a definition was simply a matter of combining material based on its subject. I had no idea that such a rule was being considered part of the definition. > 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. This makes no sense to me. A structural rule can be true .by definition. through logical inference based on several definitions. E.g. Every number is always a sum. > 9. For a given discrete meaning there is a set of 'semantic formulations' that give form to its meaning. This set can have an infinite number of formulations in it. There are typically many ways to formulate a single meaning. > 10. There is a one-to-one relationship between an 'operative business rule' and the set of 'semantic formulations' of its discrete meaning. There is a one-to-one relationship between a proposition and the set of semantic formulations that formulate it. > 11. There is a one-to-one relationship between a 'delimiting' component of an 'intensional definition' and the set of 'semantic formulations' of its discrete meaning. There is a one-to-one relationship between a definition, whether intensional or otherwise, and the set of semantic formulations that formulate its meaning. Regards, Don User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 10 May 2006 17:27:36 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+Cgg== > Donald wrote: > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using > three combinations of these two forms: > ... > c. Definitions composed of a 'more general concept' plus some 'structural > rules / definitional rules / definitional criteria' and some > 'characteristics' -- (the way many of the SBVR concepts are defined). Donald, This characterization you give for "7c" ("the way many of the SBVR concepts are defined") is not correct, is it? Indeed, I thought that the (formal, intensional) definitions of SBVR concepts were of your form "b": > b. All definitions composed only of a 'more general concept' (plus one or > more 'characteristics'. Can you provide a couple of examples from SBVR that are in form "7c" so we can better understand what you are talking about? thanks, Keri X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 10 May 2006 20:29:46 -0500 To: "Baisley, Donald E" , From: "Ronald G. Ross" Subject: RE: issue 9613 -- SBVR FTF issue At 06:18 PM 5/10/2006, Baisley, Donald E wrote: Some comments on Donald.s architectural principles. > 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' This is not clear to me. I have not found structural rules to be part of definitions. > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). Is this saying that structural rule statements exist as parts of definitions rather than as first class rules? I understood that putting a structural rule statement next to a definition was simply a matter of combining material based on its subject. I had no idea that such a rule was being considered part of the definition. > 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. This makes no sense to me. Don, I did not read that Donald was saying that structural rules are not first-class. (If he is, then that's obviously a serious problem.) I thought he was saying that in case 7b (and 7c) "Intensional Definition" becomes a whole in a part-whole relation. So which is more 'first-class', the part or the whole? (That might be a chicken-and-egg problem.) In other words, I was sensing some structure *missing* in SBVR at present to "make-up/compose" type-b and type-c definitions. But I guess Donald would need to speak to all that. Some good worked-out example of each case (I offered one for b in my original response) would *really* help. The other (related) point is that structural rules (like all rules) are generally multi-term, and often multi-fact(type). So the general case would have to be that the relation of structural rules to "intensional definitions" in the way Donald describes would, it seems, be m:n. Since that's the case, it again speaks to their first-classness, I would think. But again, for Donald to clarify. Now that I think about it, there is also the issue of "necessary and sufficient" (which I don't think Donald mentioned). There will typically be many more structural rules pertaining to a concept than one would want in any reasonable definition (based on "necessary and sufficient"). Are the "others" also considered part of the "intensional definition"? If so, I think that might be a problem ... after all, we do want to encourage good practice for definition, I think (under *each* of his a, b and c above). Ron P.S. The current SBVR-SE caption "Definition" is highly intuitive. I am unclear how case b (and c) in Donald's approach could be captioned (or whatever) to accurately reflect the situation. Yet is something weren't done, won't we be forever explaining that although the caption *says* Definition, it doesn't mean the *whole* definition?! X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 10 May 2006 20:38:04 -0500 To: "Baisley, Donald E" , From: "Ronald G. Ross" Subject: RE: issue 9613 -- SBVR FTF issue At 06:18 PM 5/10/2006, Baisley, Donald E wrote: Some comments on Donald.s architectural principles. [Please ignore my first send of this message. I got Donald's 7a and 7b backwards. Sorry. **This version is correct.**]] > 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' This is not clear to me. I have not found structural rules to be part of definitions. > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). Is this saying that structural rule statements exist as parts of definitions rather than as first class rules? I understood that putting a structural rule statement next to a definition was simply a matter of combining material based on its subject. I had no idea that such a rule was being considered part of the definition. > 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. This makes no sense to me. Don, I did not read that Donald was saying that structural rules are not first-class. (If he is, then that's obviously a serious problem.) I thought he was saying that in case 7a (and 7c) "Intensional Definition" becomes a whole in a part-whole relation. So which is more 'first-class', the part or the whole? (That might be a chicken-and-egg problem.) In other words, I was sensing some structure *missing* in SBVR at present to "make-up/compose" type-a (and type-c) definitions. But I guess Donald would need to speak to all that. Some good worked-out example of each case (I offered one for type a in my original response) would *really* help. The other (related) point is that structural rules (like all rules) are generally multi-term, and often multi-fact(type). So the general case would have to be that the relation of structural rules to "intensional definitions" in the way Donald describes would, it seems, be m:n. Since that's the case, it again speaks to their first-classness, I would think. But again, for Donald to clarify. Now that I think about it, there is also the issue of "necessary and sufficient" (which I don't think Donald mentioned). There will typically be many more structural rules pertaining to a concept than one would want in any reasonable definition (based on "necessary and sufficient"). Are the "others" also considered part of the "intensional definition"? If so, I think that might be a problem ... after all, we do want to encourage good practice for definition, I think (under *each* of his a, b and c above). Ron P.S. The current SBVR-SE caption "Definition" is highly intuitive. I am unclear how typea (and c) in Donald's approach could be captioned (or whatever) to accurately reflect the situation. Yet is something weren't done, won't we be forever explaining that although the caption *says* Definition, it doesn't mean the *whole* definition?! Subject: RE: issue 9613 -- SBVR FTF issue Date: Thu, 11 May 2006 10:10:46 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0WBrINNzKFxTDQXmm/OkIFt6qMwAKbxXQACSEIjA= From: "Baisley, Donald E" To: X-OriginalArrivalTime: 11 May 2006 17:10:46.0924 (UTC) FILETIME=[D8406CC0:01C6751D] Some comments regarding this issue: There are multiple ways to represent the intension of a concept. The most common way is to write a definition. Another way is to show a set of characteristics that make up the concept such that the set includes characteristics that are necessary and sufficient to distinguish the concept from other concepts. Given a definition, there are structural rules that can be written based on it. But the inverse is not true. In general it is not possible to derive a definition of a concept from structural rules. It is perhaps possible to derive a definition of a concept from a specific set of structural rules that are said to be sufficient for that concept. But I don.t see that being done. On the other hand, given a definition of a concept, it is possible to derive a list of characteristics that make up the concept. And conversely, given a set of necessary and sufficient characteristics making up a concept, it would be possible to derive a definition. These are transformations that tools based on SBVR should be able to provide. Regards, Don -------------------------------------------------------------------------------- From: Baisley, Donald E Sent: Wednesday, May 10, 2006 4:18 PM To: sbvr-ftf@omg.org Subject: RE: issue 9613 -- SBVR FTF issue Some comments on Donald.s architectural principles. > 1. 'Definitions' and 'rules' are not the same thing as 'semantic formulations'. Correct. > 2. 'Semantic formulations' structure the meaning of 'definitions' and of 'rules'. Semantic formulations formulate the meanings of definitions and rule statements. In SBVR, a rule does not have a meaning. Rather, a rule is a meaning. Semantic formulations also formalize definitions and rule statements. > 3. The meaning of an 'operative business rule' is structured by a 'semantic formulation' that introduces an 'obligation'. An operative business rule is formulated by a semantic formulation. The rule introduces an obligation. > 4. The meaning of a 'structural rule / definitional rule / definitional criterion' is structured by a 'semantic formulation' that introduces a 'necessity' which itself means 'true by definition'. A structural business rule is formulated by a semantic formulation. The rule introduces a necessity. I don.t know what is meant by .definitional criterion.. > 5. 'Intensional definitions' are made up of definitional components of two types: a. a 'more general concept' b. one or more 'delimiting' components An intensional definition represents a concept by describing the intension of a concept through stating a more general concept and one or more delimiting characteristics. > 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' This is not clear to me. I have not found structural rules to be part of definitions. > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). Is this saying that structural rule statements exist as parts of definitions rather than as first class rules? I understood that putting a structural rule statement next to a definition was simply a matter of combining material based on its subject. I had no idea that such a rule was being considered part of the definition. > 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. This makes no sense to me. A structural rule can be true .by definition. through logical inference based on several definitions. E.g. Every number is always a sum. > 9. For a given discrete meaning there is a set of 'semantic formulations' that give form to its meaning. This set can have an infinite number of formulations in it. There are typically many ways to formulate a single meaning. > 10. There is a one-to-one relationship between an 'operative business rule' and the set of 'semantic formulations' of its discrete meaning. There is a one-to-one relationship between a proposition and the set of semantic formulations that formulate it. > 11. There is a one-to-one relationship between a 'delimiting' component of an 'intensional definition' and the set of 'semantic formulations' of its discrete meaning. There is a one-to-one relationship between a definition, whether intensional or otherwise, and the set of semantic formulations that formulate its meaning. Regards, Don X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 11 May 2006 12:32:32 -0500 To: sbvr-ftf@omg.org, Donald Chapin From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Donald, I found your statement in today's meeting, "definitions can't be fuzzy", to be astounding. Perhaps I heard wrong? Please tell me so. I need clarification, please. I can see how that might be true in a pure, highly academic sense. (Is that what you mean?) But I think most people would agree that they see 'fuzzy' business definitions all the time(!). I know I do. By 'fuzzy' I mean they don't tell you enough to communicate with other people effectively. They don't permit you to participate as productively as desired in the value-adding activity of the business. They don't allow you to construct knowledge adequate to purpose. They don't allow consistency in the use of knowledge. They don't permit effective retention of knowledge. I did not originally sense that your 'architectural principles' might be taking us in that direction. If so, I have to say I think that's a problem, both for pragmatic and logical reasons. A major theme of the business rules approach is to bring as much clarity (unfuzziness) as possible to 'meaning'. That should be true whether or not the meaning is in the form of definitions or rules. Ron At 12:32 PM 5/10/2006, Juergen Boldt wrote: From: webmaster@omg.org Date: 10 May 2006 11:33:04 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Donald Chapin Company: Business Semantics Ltd mailFrom: Donald.Chapin@btinternet.com Notification: No Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: Chapters 8,9,11,12 FormalNumber: dtc/06-03-02 Version: Interim Specification RevisionDate: March 2, 2006 Page: Affects the interpretation of many SBVR metamodel constructs Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727) Description Issue Name: "Explicitly Stated SBVR Architectural Principles for Relationships among 'Definitions' 'Rules' and 'Semantic Formulations'" Issue Statement: The lack of an explicitly stated, concise set of SBVR architectural principles regarding the relationship of 'definitions' 'rules' and 'semantic formulations' is causing much needless SBVR-FTF discussion around related topics. If this lack is causing a problem for the creators of SBVR, then it's going to be even harder for people in the rest of the world to understand and agree on this critical aspect of SBVR. A (strawman) set of SBVR architectural principles needs to be explicitly stated in SBVR as follows: 1. 'Definitions' and 'rules' are not the same thing as 'semantic formulations'. 2. 'Semantic formulations' structure the meaning of 'definitions' and of 'rules'. 3. The meaning of an 'operative business rule' is structured by a 'semantic formulation' that introduces an 'obligation'. 4. The meaning of a 'structural rule / definitional rule / definitional criterion' is structured by a 'semantic formulation' that introduces a 'necessity' which itself means 'true by definition'. 5. 'Intensional definitions' are made up of definitional components of two types: a. a 'more general concept' b. one or more 'delimiting' components 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'chara .gninaem etercsid sti fo 'snoitalumrof citnames' fo tes eht dna 'noitinifed lanoisnetni' na fo tnenopmoc 'gnitimiled' a neewteb pihsnoitaler eno-ot-eno a si erehT .11 .gninaem etercsid sti fo 'snoitalumrof citnames' fo tes eht dna 'elur ssenisub evitarepo' na neewteb pihsnoitaler eno-ot-eno a si erehT .01 .gninaem sti ot mrof evig taht 'snoitalumrof citnames' fo tes a si ereht gninaem etercsid nevig a roF .9 ..'noitinifed yb eurt' fo yralloroc a si sihT .'noitinifed lanoisnetni' na fo stnenopmoc sa ylno tsixe 'airetirc lanoitinifed / selur lanoitinifed / selur larutcurtS' .8 .)denifed era stpecnoc RVBS eht fo ynam yaw eht( -- 'scitsiretcarahc' emos dna 'airetirc lanoitinifed / selur lanoitinifed / selur larutcurts' emos sulp 'tpecnoc lareneg erom' a fo desopmoc snoitinifeD .c .'scitsiretc Juergen Boldt Director, Member Services 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 11 May 2006 11:25:25 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ1KEVkhBAWNeEbEdqu8AARJM+Cgg== On 5/11/06 10:32 AM, "Ronald G. Ross" wrote: I found your statement in today's meeting, "definitions can't be fuzzy", to be astounding. Perhaps I heard wrong? Please tell me so. Furthermore, my use of .fuzzy. was misinterpreted. I was talking about business policy being .fuzzy. -- but not that the definition of some business policy is fuzzy. My reference was to Gladys. original (1998) article, .Policy Charter as a Deliverable.. I hope that makes it crystal clear that a business policy can be defined. In SBVR, we don.t have anything to say about .fuzzy. definitions . we have fully formal, partly formal, or informal. But .fuzzy. ... nope. ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 11 May 2006 16:31:19 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: Don Baisley , SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0WBrINNzKFxTDQXmm/OkIFt6qMwAKbxXQADRKh8w= Donald, A clarification, please. In today.s meeting, you frequently used a phrasing that spoke of .composition. -- e.g., the .composition of a definition.. That idea is also reflected in the point below. When this issue talks about .definition. in this compositional way is it (a) exploring a change to the current notion in SBVR that is termed .definition.? ... or (b) suggesting the addition of another notion . one that is .composed of. various kinds of things, possibly in the kinds of ways you list below? If (a), I am having a hard time getting my head around how we could go from the atomic notion of a .substitutable expression. (i.e., the concept that is defined on p. 23 and explained on pp. 201-203) to something .composed of parts. without huge impact. If (b), then this sounds like what we used to differentiate (informally) as .little-D definition. and .big-D definition. -- and we might want to have some way to make it clear when we are talking about one versus the other, especially while we have these preliminary exchanges (each bringing our own mental model into the discussion). thanks, ~ Keri On 5/10/06 4:18 PM, "Baisley, Donald E" wrote: > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). Is this saying that structural rule statements exist as parts of definitions rather than as first class rules? I understood that putting a structural rule statement next to a definition was simply a matter of combining material based on its subject. I had no idea that such a rule was being considered part of the definition. Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 16:53:32 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ0WBrINNzKFxTDQXmm/OkIFt6qMwAKbxXQADRKh8wBHJ/XsA== Keri, My language was not quite precise enough. In the most basic sense, I was talking about the .composition. of the .intension. of a .concept., but also the corresponding .composition. of three ways to represent the intension of a concept (see Don Baisley.s email May 11 at 10:11 PDT which I will respond to separately): 1. a definition (wording) 2. a more general concept plus a set of characteristics 3. a more general concept plus a set of structural rules Don says that automated two-way translation between 1 & 2 is possible. What I.m saying in addition to that is that automated two-way translation between 1 & 3 and 2 & 3 will also be possible. See also answers in-line below. Donald -------------------------------------------------------------------------------- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: 12 May 2006 00:31 To: Don Baisley; SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue Donald, A clarification, please. In today.s meeting, you frequently used a phrasing that spoke of .composition. -- e.g., the .composition of a definition.. That idea is also reflected in the point below. When this issue talks about .definition. in this compositional way is it (a) exploring a change to the current notion in SBVR that is termed .definition.? ... or (b) suggesting the addition of another notion . one that is .composed of. various kinds of things, possibly in the kinds of ways you list below? I was not talking about changing the notion of definition, only acknowledging that the definition (wording) includes reference to the .more general concept. and words to state each of the delimiting characteristics. This is classic definition practice. I guess that (as mentioned above) I was drawing out the implicit .composition. of all forms for representing the .intension. of a .concept.. .More general concept. plus .delimiting characteristics. have been a part of SBVR from the beginning as they come from ISO 1087. This is the primary way meanings (concepts) are known and distinguished. If (a), I am having a hard time getting my head around how we could go from the atomic notion of a .substitutable expression. (i.e., the concept that is defined on p. 23 and explained on pp. 201-203) to something .composed of parts. without huge impact. The notion of a series of words that are a substitutable expression does not change. It is the grammar of that substitutable expression to be able to be automatically transformed between 1 & 2 above. Nothing new here. If (b), then this sounds like what we used to differentiate (informally) as .little-D definition. and .big-D definition. -- and we might want to have some way to make it clear when we are talking about one versus the other, especially while we have these preliminary exchanges (each bringing our own mental model into the discussion). I don.t know that .little-D definition. and .big-D definition. means. Sorry. thanks, ~ Keri On 5/10/06 4:18 PM, "Baisley, Donald E" wrote: > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). Is this saying that structural rule statements exist as parts of definitions rather than as first class rules? I understood that putting a structural rule statement next to a definition was simply a matter of combining material based on its subject. I had no idea that such a rule was being considered part of the definition. Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: FW: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 17:01:23 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ1KEVkhBAWNeEbEdqu8AARJM+CggEnDFZQAAF6p0A= -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: 17 May 2006 16:16 To: 'John and Keri' Subject: RE: issue 9613 -- SBVR FTF issue Keri, I agree with you about .fuzzy. business policy and .fuzzy. definitions. I remember Gladys. .fuzzy. business policy well. To the best of my knowledge there is no such thing as a .definition. of a policy . only policy statements. Donald -------------------------------------------------------------------------------- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: 11 May 2006 19:25 To: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue On 5/11/06 10:32 AM, "Ronald G. Ross" wrote: I found your statement in today's meeting, "definitions can't be fuzzy", to be astounding. Perhaps I heard wrong? Please tell me so. Furthermore, my use of .fuzzy. was misinterpreted. I was talking about business policy being .fuzzy. -- but not that the definition of some business policy is fuzzy. My reference was to Gladys. original (1998) article, .Policy Charter as a Deliverable.. I hope that makes it crystal clear that a business policy can be defined. In SBVR, we don.t have anything to say about .fuzzy. definitions . we have fully formal, partly formal, or informal. But .fuzzy. ... nope. ~ Keri Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 17:14:29 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjw Keri, First of all, my wording is not precise enough. It should have read, "(7.)c. Representations of 'intensions' of 'concepts' composed of a partial definitions ('more general concept' reference plus and some delimiting 'characteristics' wording) plus some 'structural rules / definitional rules / definitional criteria'-- (the way many of the SBVR concepts have their intensions represented)." Every SBVR concept that has a 'Definition' and one or more 'Necessities' is an example of this. I believe that this is bad practice. The 'intension' of a concept should be represented entirely in one of the following ways (or completely in more than one of the ways, but not partially from multiple ways): 1. a definition (wording) 2. a more general concept plus a set/list of characteristics 3. a more general concept plus a set/list of structural rules This situation in SBVR has been a great concern since it began, but we simply ran out of time and team will to deal with some of these things so I let them pass. Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 11 May 2006 01:28 > To: SBVR-FTF > Subject: Re: issue 9613 -- SBVR FTF issue > > > Donald wrote: > > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed > using > > three combinations of these two forms: > > ... > > c. Definitions composed of a 'more general concept' plus some > 'structural > > rules / definitional rules / definitional criteria' and some > > 'characteristics' -- (the way many of the SBVR concepts are defined). > > Donald, > > This characterization you give for "7c" ("the way many of the SBVR > concepts > are defined") is not correct, is it? > > Indeed, I thought that the (formal, intensional) definitions of SBVR > concepts were of your form "b": > > b. All definitions composed only of a 'more general concept' (plus one > or > > more 'characteristics'. > > Can you provide a couple of examples from SBVR that are in form "7c" so we > can better understand what you are talking about? > > thanks, > Keri > User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 17 May 2006 09:17:57 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0WBrINNzKFxTDQXmm/OkIFt6qMwAKbxXQADRKh8wBHJ/XsAAB/S6Y On 5/17/06 8:53 AM, "Donald Chapin" wrote: In the most basic sense, I was talking about the .composition. of the .intension. of a .concept., but also the corresponding .composition. of three ways to represent the intension of a concept (see Don Baisley.s email May 11 at 10:11 PDT which I will respond to separately): 1. a definition (wording) 2. a more general concept plus a set of characteristics 3. a more general concept plus a set of structural rules ... I don.t know that .little-D definition. and .big-D definition. means. Sorry. Thanks, Donald. This is a helpful clarification. When we.ve had this conversation in the past, .big-D definition. meant your (1) above . the captioned wording. And .little-D definition. was the term applied to what you are calling (above) .the .composition. of the .intension. of a .concept... It is very confusing when the simple, unqualified term .definition. is used to mean both notions. So my suggestion is that when we say .definition. understand that we mean (1) - above . and (hopefully) we can come up with some other term when we mean .the .composition. of the .intension. of a .concept... In any case, we would not be using .definition. for that latter notion or we will all become hopelessly entangled in word soup. cheers, Keri Reply-To: From: "Donald Chapin" To: Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 17:36:02 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ1IOusCCYL2QE5RcKC+i+qKaFa4wErF/EQ Ron, Definitions are different from statements that govern business actions in this way. Definitions, plus the other forms of representing the .intension. of a .concept., are all that we have in SBVR to connect/synchronize/document the image/meaning/concept in mind of each member of the semantic community in whose SBVR-based body of shared meanings the definition is being recorded so the concept can be shared. Definitions can be wrong (i.e. they can be a mismatch to what is in the minds of the members of the semantic community), but they cannot be .fussy.. The (naked) .concept. is what the definition (or other form of representing the intension of a concept) says it is. The concept can be too general, too specific or not best suited to purpose; but the definition cannot be fuzzy. See addition comments in-line below. Donald -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: 11 May 2006 18:33 To: sbvr-ftf@omg.org; Donald Chapin Subject: Re: issue 9613 -- SBVR FTF issue Donald, I found your statement in today's meeting, "definitions can't be fuzzy", to be astounding. Perhaps I heard wrong? Please tell me so. I need clarification, please. I can see how that might be true in a pure, highly academic sense. (Is that what you mean?) But I think most people would agree that they see 'fuzzy' business definitions all the time(!). I know I do. By 'fuzzy' I mean they don't tell you enough to communicate with other people effectively. They don't permit you to participate as productively as desired in the value-adding activity of the business. They don't allow you to construct knowledge adequate to purpose. They don't allow consistency in the use of knowledge. They don't permit effective retention of knowledge. Then the concepts represented by the definitions are too general, too specific or mismatched for their purpose, but the definitions can.t be .fuzzy. . by definition! I did not originally sense that your 'architectural principles' might be taking us in that direction. If so, I have to say I think that's a problem, both for pragmatic and logical reasons. A major theme of the business rules approach is to bring as much clarity (unfuzziness) as possible to 'meaning'. That should be true whether or not the meaning is in the form of definitions or rules. Of course conceptualizing the work or discipline of the semantic community well is a critical success factor. If that is not done well, it is a problem with the quality of conceptualization and its resulting concepts, as represented by their definitions. It is not that the .definitions. are .fuzzy.. Ron X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 17 May 2006 12:35:02 -0500 To: , "'SBVR-FTF'" From: "Ronald G. Ross" Subject: RE: issue 9613 -- SBVR FTF issue At 11:14 AM 5/17/2006, Donald Chapin wrote: Keri, First of all, my wording is not precise enough. It should have read, "(7.)c. Representations of 'intensions' of 'concepts' composed of a partial definitions ('more general concept' reference plus and some delimiting 'characteristics' wording) plus some 'structural rules / definitional rules / definitional criteria'-- (the way many of the SBVR concepts have their intensions represented)." Donald, I am trying to understand your several replies just now, but confess I am having trouble. I think a source of my confusion is that you are providing clarifications on individual points, and it's hard to see how they add up. I think it would be helpful to me, at least, if you re-issued your architectural principles with the clarifications integrated in. For example, as Don B. noted, there was some juxtaposition of things on the representation side (definition), with things on the n*ked meaning side. (And you've had a lot of feedback now.) Also, I really would like to know (to be very direct about one concern) if you are implicitly suggesting that we *change* use of the caption "definition" in SBVR-SE all through document. That would be a potential outcome of one interpretation (hopefully wrong!) of your principles. Just a thought. Ron Every SBVR concept that has a 'Definition' and one or more 'Necessities' is an example of this. I believe that this is bad practice. The 'intension' of a concept should be represented entirely in one of the following ways (or completely in more than one of the ways, but not partially from multiple ways): 1. a definition (wording) 2. a more general concept plus a set/list of characteristics 3. a more general concept plus a set/list of structural rules This situation in SBVR has been a great concern since it began, but we simply ran out of time and team will to deal with some of these things so I let them pass. Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 11 May 2006 01:28 > To: SBVR-FTF > Subject: Re: issue 9613 -- SBVR FTF issue > > > Donald wrote: > > 7. The 'intensional definitions' in an SBVR Vocabulary can be composed > using > > three combinations of these two forms: > > ... > > c. Definitions composed of a 'more general concept' plus some > 'structural > > rules / definitional rules / definitional criteria' and some > > 'characteristics' -- (the way many of the SBVR concepts are defined). > > Donald, > > This characterization you give for "7c" ("the way many of the SBVR > concepts > are defined") is not correct, is it? > > Indeed, I thought that the (formal, intensional) definitions of SBVR > concepts were of your form "b": > > b. All definitions composed only of a 'more general concept' (plus one > or > > more 'characteristics'. > > Can you provide a couple of examples from SBVR that are in form "7c" so we > can better understand what you are talking about? > > thanks, > Keri > Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 19:02:02 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZ52E97IvQm+6jZQd+7X8B5/1EVEgAAo6cQ Ron, > -----Original Message----- > From: Ronald G. Ross [mailto:rross@brsolutions.com] > Sent: 17 May 2006 18:35 > To: Donald.Chapin@btinternet.com; 'SBVR-FTF' > Subject: RE: issue 9613 -- SBVR FTF issue > ... > > Also, I really would like to know (to be very direct about one > concern) if you are implicitly suggesting that we *change* use of the > caption "definition" in SBVR-SE all through document. That would be a > potential outcome of one interpretation (hopefully wrong!) of your > principles. The caption 'Definition' in Clauses 8, 9, 11 & 12 (which is Structured English by the way) is for a 'definition', which is a substitutable expression. There is nothing in what I have written that suggests a change to the meaning of either the SBVR concept, 'definition', or the SBVR SE caption, 'Definition'. I'm just saying that whatever form of representation is used for the 'intension' of a 'concept' that ALL the delimiting components are included in that form of representation. Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 17 May 2006 11:11:16 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgc= On 5/17/06 9:14 AM, "Donald Chapin" wrote: > ... The 'intension' of a concept should be > represented entirely in one of the following ways (or completely in more > than one of the ways, but not partially from multiple ways): > > 1. a definition (wording) > > 2. a more general concept plus a set/list of characteristics > > 3. a more general concept plus a set/list of structural rules Donald, A clarification, please, on what you mean by 'characteristic' in this discussion, using the following example as a frame of reference. Which is the 'characteristic' - the unary fact type, or the use of the unary fact type (along with key words and/or quantification) to represent the intension a particular concept? For example, Unary fact type/characteristic: [directive] is actionable Definition of 'business policy': "directive that is not actionable ..." In other words, if I understand your list (above), you would say that, for 'business policy', we are giving its more general concept (i.e., 'directive') plus its characteristics (that it is not actionable -- i.e., adding in 'not' to the unary fact type. But I thought that the 'characteristic' was simply the raw (without quantification or key words) unary fact type. So I am confused. Which of these is a 'characteristic' in the sense that we are meaning in this Issue? Or are they both considered to be a 'characteristic'? thanks, Keri X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 17 May 2006 13:23:53 -0500 To: , "'SBVR-FTF'" From: "Ronald G. Ross" Subject: RE: issue 9613 -- SBVR FTF issue At 01:02 PM 5/17/2006, Donald Chapin wrote: Ron, > -----Original Message----- > From: Ronald G. Ross [mailto:rross@brsolutions.com] > Sent: 17 May 2006 18:35 > To: Donald.Chapin@btinternet.com; 'SBVR-FTF' > Subject: RE: issue 9613 -- SBVR FTF issue > ... > > Also, I really would like to know (to be very direct about one > concern) if you are implicitly suggesting that we *change* use of the > caption "definition" in SBVR-SE all through document. That would be a > potential outcome of one interpretation (hopefully wrong!) of your > principles. The caption 'Definition' in Clauses 8, 9, 11 & 12 (which is Structured English by the way) is for a 'definition', which is a substitutable expression. There is nothing in what I have written that suggests a change to the meaning of either the SBVR concept, 'definition', or the SBVR SE caption, 'Definition'. The latter point is a BIG relief! I'm just saying that whatever form of representation is used for the 'intension' of a 'concept' that ALL the delimiting components are included in that form of representation. Does SBVR require a new term to get at this? Or are you saying the problem is perhaps merely insufficient explication in the SBVR document on this point? Or are you saying there really is *no* problem at present?? (Just trying to get a handle on this ...) Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 17 May 2006 11:28:03 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAAJYOGQ== Donald, For another variation on this question, what about the use of a non-unary fact type in a definition. Is that considered to be a 'characteristic'? For example, the (fully formal) definition of 'binary fact type' is: fact type that has exactly 2 roles I would interpret this (applying your scheme below) to be case 2, in that it gives (a) the more general concept (i.e., fact type) and (b) the 'characteristic' (i.e., having exactly 2 roles). But this 'characteristic' is based on the binary fact type 'fact type has role' -- which is a binary fact type, not a unary fact type (characteristic). Can you please clarify this case? thanks, Keri On 5/17/06 11:11 AM, "John and Keri" wrote: > On 5/17/06 9:14 AM, "Donald Chapin" wrote: > >> ... The 'intension' of a concept should be >> represented entirely in one of the following ways (or completely in more >> than one of the ways, but not partially from multiple ways): >> >> 1. a definition (wording) >> >> 2. a more general concept plus a set/list of characteristics >> >> 3. a more general concept plus a set/list of structural rules > > Donald, > > A clarification, please, on what you mean by 'characteristic' in this > discussion, using the following example as a frame of reference. > > Which is the 'characteristic' - the unary fact type, or the use of the unary > fact type (along with key words and/or quantification) to represent the > intension a particular concept? > > For example, > > Unary fact type/characteristic: > [directive] is actionable > > Definition of 'business policy': > "directive that is not actionable ..." > > In other words, if I understand your list (above), you would say that, for > 'business policy', we are giving its more general concept (i.e., > 'directive') plus its characteristics (that it is not actionable -- i.e., > adding in 'not' to the unary fact type. But I thought that the > 'characteristic' was simply the raw (without quantification or key words) > unary fact type. So I am confused. > > Which of these is a 'characteristic' in the sense that we are meaning in > this Issue? Or are they both considered to be a 'characteristic'? > > thanks, > Keri > > Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 11:48:23 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAACj04A== From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 17 May 2006 18:48:41.0604 (UTC) FILETIME=[844FF440:01C679E2] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k4HIbLRS028521 SBVR's concept 'characteristic' (A.K.A. 'unary fact type') has exactly the meaning given by ISO. A characteristic does not need to have a defined form of expression. It is not an element of a vocabulary (a representation), but a meaning. It might be represented in various ways, such as using an expression that could serve as a definition of the characteristic. Suppose I have this (rather poor) definition of 'business policy': directive that is not actionable The concept 'business policy' is defined in terms of a pair of necessary and sufficient characteristics. Each business policy: 1. is a directive 2. is not actionable According to the definition, these two characteristics are sufficient to distinguish a business policy from other things. E.g. If something is a directive and is not actionable, then it is a business policy. If something is not a directive or is actionable, then it is not a business policy. Note that neither of the two characteristics is directly represented by a form of expression in the SBVR vocabulary. But each one can be easily expressed in terms of the SBVR vocabulary. Making semantic formulations defining these two characteristics is a simple matter (e.g. using an instantiation formulation with the concept 'directive' and using a negation with the characteristic '[directive] is actionable'). I hope the explanation above helps clear some things up. If a term is given without a definition, then the SBVR Structured English does not provide any other way to fully define the concept meant by the term short of describing a semantic formulation of a definition. Specifying a more general concept indicates one characteristic that makes up the concept meant by the term. Necessity statements can further indicate characteristics that either make up the concept or that are inferred from those characteristics. But there is no current way to derive a set of necessary and sufficient characteristics from a set of necessities combined with a set of more general concepts. I see no problem here because if I want to express necessary and sufficient characteristics that make up a concept, I can simply write a definition. Best regards, Don -----Original Message----- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Wednesday, May 17, 2006 11:11 AM To: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue On 5/17/06 9:14 AM, "Donald Chapin" wrote: > ... The 'intension' of a concept should be > represented entirely in one of the following ways (or completely in more > than one of the ways, but not partially from multiple ways): > > 1. a definition (wording) > > 2. a more general concept plus a set/list of characteristics > > 3. a more general concept plus a set/list of structural rules Donald, A clarification, please, on what you mean by 'characteristic' in this discussion, using the following example as a frame of reference. Which is the 'characteristic' - the unary fact type, or the use of the unary fact type (along with key words and/or quantification) to represent the intension a particular concept? For example, Unary fact type/characteristic: [directive] is actionable Definition of 'business policy': "directive that is not actionable ..." In other words, if I understand your list (above), you would say that, for 'business policy', we are giving its more general concept (i.e., 'directive') plus its characteristics (that it is not actionable -- i.e., adding in 'not' to the unary fact type. But I thought that the 'characteristic' was simply the raw (without quantification or key words) unary fact type. So I am confused. Which of these is a 'characteristic' in the sense that we are meaning in this Issue? Or are they both considered to be a 'characteristic'? thanks, Keri Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 11:59:09 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAAJYOGQABBpcA From: "Baisley, Donald E" To: "John and Keri" , "SBVR-FTF" X-OriginalArrivalTime: 17 May 2006 18:59:52.0219 (UTC) FILETIME=[1407AEB0:01C679E4] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k4HImSXj001949 Keri, Please read my previous email and then answer your own question. What are the two necessary and sufficient characteristics that make up the concept 'binary fact type' as given by its definition? Enjoy, Don -----Original Message----- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Wednesday, May 17, 2006 11:28 AM To: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue Donald, For another variation on this question, what about the use of a non-unary fact type in a definition. Is that considered to be a 'characteristic'? For example, the (fully formal) definition of 'binary fact type' is: fact type that has exactly 2 roles I would interpret this (applying your scheme below) to be case 2, in that it gives (a) the more general concept (i.e., fact type) and (b) the 'characteristic' (i.e., having exactly 2 roles). But this 'characteristic' is based on the binary fact type 'fact type has role' -- which is a binary fact type, not a unary fact type (characteristic). Can you please clarify this case? thanks, Keri On 5/17/06 11:11 AM, "John and Keri" wrote: > On 5/17/06 9:14 AM, "Donald Chapin" wrote: > >> ... The 'intension' of a concept should be >> represented entirely in one of the following ways (or completely in more >> than one of the ways, but not partially from multiple ways): >> >> 1. a definition (wording) >> >> 2. a more general concept plus a set/list of characteristics >> >> 3. a more general concept plus a set/list of structural rules > > Donald, > > A clarification, please, on what you mean by 'characteristic' in this > discussion, using the following example as a frame of reference. > > Which is the 'characteristic' - the unary fact type, or the use of the unary > fact type (along with key words and/or quantification) to represent the > intension a particular concept? > > For example, > > Unary fact type/characteristic: > [directive] is actionable > > Definition of 'business policy': > "directive that is not actionable ..." > > In other words, if I understand your list (above), you would say that, for > 'business policy', we are giving its more general concept (i.e., > 'directive') plus its characteristics (that it is not actionable -- i.e., > adding in 'not' to the unary fact type. But I thought that the > 'characteristic' was simply the raw (without quantification or key words) > unary fact type. So I am confused. > > Which of these is a 'characteristic' in the sense that we are meaning in > this Issue? Or are they both considered to be a 'characteristic'? > > thanks, > Keri > > User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 17 May 2006 12:35:11 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: Don Baisley , SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAAJYOGQABBpcAAAFRoRw= On 5/17/06 11:59 AM, "Baisley, Donald E" wrote: > Please read my previous email and then answer your own question. What > are the two necessary and sufficient characteristics that make up the > concept 'binary fact type' as given by its definition? Don, While I'm working on this, perhaps you can answer another question (or give me yet another 'quiz' to ponder). We have covered the way to represent a characteristic of a concept that is part of its 'necessary and sufficient' set -- but how about a characteristic of a concept that is not part of that set? How would we represent that kind of element of meaning in a vocabulary? thanks, Keri Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 15:00:52 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAACj04AADmnMg Priority: Non-Urgent From: "Vincent, Paul D" To: "Baisley, Donald E" , "SBVR-FTF" X-OriginalArrivalTime: 17 May 2006 20:00:56.0523 (UTC) FILETIME=[9C2019B0:01C679EC] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k4HJp4Rs016310 FYI this is also the use of "characteristic" (at the CIM level) for analytical models. Good to see a conformance with SBVR! Paul Vincent for Fair Isaac Blaze Advisor -- Business Rule Management System @ OMG and W3C standards for rules > -----Original Message----- > From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] > Sent: Wednesday, May 17, 2006 7:48 PM > To: SBVR-FTF > Subject: RE: issue 9613 -- SBVR FTF issue > > SBVR's concept 'characteristic' (A.K.A. 'unary fact type') has exactly > the meaning given by ISO. A characteristic does not need to have a > defined form of expression. It is not an element of a vocabulary (a > representation), but a meaning. It might be represented in various > ways, such as using an expression that could serve as a definition of > the characteristic. ... This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 13:53:57 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAAJYOGQABBpcAAAFRoRwAAeVW4A== From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 17 May 2006 20:54:35.0644 (UTC) FILETIME=[1ADEFBC0:01C679F4] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k4HKhC1B025928 Keri wrote: > We have covered the way to represent a characteristic of a concept that is part of its 'necessary and sufficient' set -- but how about a characteristic of a concept that is not part of that set? How would we represent that kind of element of meaning in a vocabulary? Characteristics that go beyond what is sufficient have been stated using the "Necessity" caption. Consider the second necessity listed under 'form of expression': "Each form of expression has at least one placeholder." So a characteristic of forms of expression is that they have at least one placeholder. Other characteristics are given in some of the other necessities listed under 'form of expression'. But not all of the necessities can be interpreted in that way. But the ones that start out "Each form of expression ..." seem to all be giving characteristics. In some cases, such as the first necessity under 'form of expression', a characteristic is given that is also seen in or directly understood from a definition. But the definition is not stated in the formal style, so the necessity formalizes part of what is given informally in the definition. Regards, Don -----Original Message----- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Wednesday, May 17, 2006 12:35 PM To: Baisley, Donald E; SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue On 5/17/06 11:59 AM, "Baisley, Donald E" wrote: > Please read my previous email and then answer your own question. What > are the two necessary and sufficient characteristics that make up the > concept 'binary fact type' as given by its definition? Don, While I'm working on this, perhaps you can answer another question (or give me yet another 'quiz' to ponder). We have covered the way to represent a characteristic of a concept that is part of its 'necessary and sufficient' set -- but how about a characteristic of a concept that is not part of that set? How would we represent that kind of element of meaning in a vocabulary? thanks, Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 17 May 2006 14:20:19 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: Don Baisley , SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAAJYOGQABBpcAAAT9mHU= On 5/17/06 11:59 AM, "Baisley, Donald E" wrote: > Please read my previous email and then answer your own question. What > are the two necessary and sufficient characteristics that make up the > concept 'binary fact type' as given by its definition? I suppose it would look like this: Suppose I have this (high quality) definition of 'binary fact type': fact type that has exactly 2 roles The concept 'binary fact type' is defined in terms of a pair of necessary and sufficient characteristics. Each binary fact type: 1. is a fact type 2. has exactly 2 roles According to the definition, these two characteristics are sufficient to distinguish a binary fact type from other things. E.g. If something is a fact type and has exactly 2 roles, then it is a binary fact type. If something is not a fact type or has other than 2 roles, then it is not a binary fact type. Another musing... Why do we talk/write in terms of .necessary and sufficient. characteristics when the ISO (& SBVR) terminology is .essential and delimiting. characteristics? ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 17 May 2006 15:12:33 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: Don Baisley , SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAAJYOGQABBpcAAAFRoRwAAeVW4AADmaL7 On 5/17/06 1:53 PM, "Baisley, Donald E" wrote: > Characteristics that go beyond what is sufficient have been stated using > the "Necessity" caption. Consider the second necessity listed under > 'form of expression': "Each form of expression has at least one > placeholder." So a characteristic of forms of expression is that they > have at least one placeholder. > > Other characteristics are given in some of the other necessities listed > under 'form of expression'. But not all of the necessities can be > interpreted in that way. But the ones that start out "Each form of > expression ..." seem to all be giving characteristics. In some cases, > such as the first necessity under 'form of expression', a characteristic > is given that is also seen in or directly understood from a definition. > But the definition is not stated in the formal style, so the necessity > formalizes part of what is given informally in the definition. Interesting... Feeding back what I understand you to say: 'form of expression' has six Necessity-captioned items. Three begin with "Each form of expression" so I understand you to say that these three of the six are characteristics. One of them (the first) would be considered part of the 'necessary and sufficient' set, in that it is expressing formally what is seen in the not fully formal definition text. The other two would be cases of characteristics that are necessary and beyond-the-sufficient. Is there such a thing as a characteristic of a concept that is beyond what is sufficient and also is not necessary? Let me guess ... that kind of characteristic uses the 'Possibility:" caption, right? And also simply by having a (binary) fact type? For example, the fact type "concept is commented on in note" would appear to mean that having a note is an optional (i.e., possible) characteristic of 'concept'. Then, turning to the remaining 3 necessities listed under 'form of expression' (the 3rd, 4th, and 6th necessities), if these are not 'characteristics' of 'form of expression', what are they to 'form of expression'? ~ Keri Subject: RE: issue 9613 -- SBVR FTF issue Date: Wed, 17 May 2006 17:06:14 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAAJYOGQABBpcAAAFRoRwAAeVW4AADmaL7AANI8kA= From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 18 May 2006 00:06:55.0101 (UTC) FILETIME=[F8EC62D0:01C67A0E] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k4HNtQ5n031335 Keri wrote: > ... these three of the six are characteristics. No. The necessity statements are not characteristics and the meanings of the necessity statements are not characteristics. But from three of the six statements we understand that three respective characteristics are incorporated into the concept 'form of expression'. > Is there such a thing as a characteristic of a concept that > is beyond what is sufficient and also is not necessary? We have been talking about characteristics that are incorporated by a concept. These are the characteristics that make up the concept's intension. If I talk about "a characteristic of a concept", I mean something else altogether. > Then, turning to the remaining 3 necessities listed under 'form > of expression' (the 3rd, 4th, and 6th necessities), if these are > not 'characteristics' of 'form of expression', what are they to > 'form of expression'? The statements are all grouped under 'form of expression' because they are all about forms of expression. It's just a matter of organizational preference. The statements mean the same thing no matter where they appear in the organization of the SBVR document. Regards, Don User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 17 May 2006 17:28:10 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ6EfDSL3hiieYFEdqDSQARJM+Cgg== At 01:02 PM 5/17/2006, Donald Chapin wrote: >> I'm just saying that whatever form of representation is used for the >> 'intension' of a 'concept' that ALL the delimiting components are included >> in that form of representation. On 5/17/06 11:23 AM, "Ronald G. Ross" wrote: > Does SBVR require a new term to get at this? On 5/17/06 5:06 PM, "Baisley, Donald E" wrote: > We have been talking about characteristics that are incorporated by a > concept. These are the characteristics that make up the concept's > intension. So it seems that the SBVR notions for this are in place: i.e., the concept 'characteristic' and the fact type 'concept incorporates characteristic'. And we would use this, rather than the earlier terminology that was being used -- e.g., that of a 'definition' having 'parts', or 'components'. Is this close, Don? - Keri X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 17 May 2006 23:03:11 -0500 To: John and Keri , SBVR-FTF From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue At 07:28 PM 5/17/2006, John and Keri wrote: At 01:02 PM 5/17/2006, Donald Chapin wrote: >> I'm just saying that whatever form of representation is used for the >> 'intension' of a 'concept' that ALL the delimiting components are included >> in that form of representation. On 5/17/06 11:23 AM, "Ronald G. Ross" wrote: > Does SBVR require a new term to get at this? On 5/17/06 5:06 PM, "Baisley, Donald E" wrote: > We have been talking about characteristics that are incorporated by a > concept. These are the characteristics that make up the concept's > intension. So it seems that the SBVR notions for this are in place: i.e., the concept 'characteristic' and the fact type 'concept incorporates characteristic'. And we would use this, rather than the earlier terminology that was being used -- e.g., that of a 'definition' having 'parts', or 'components'. Is this close, Don? Note that Donald said 'delimiting *components*', but the fact type is 'concept incorporates *characteristic*' (which would seem to exclude necessities). If we accept there is actually a problem, does the SBVR fact type need fixing, or a new one need to be added? Ron - Keri Date: Thu, 18 May 2006 06:35:27 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en Cc: sbvr-ftf@omg.org Subject: Re: issue 9613 -- SBVR FTF issue Hello all, Ronald G. Ross wrote: ... here is an example what I must be able to do cleanly and directly: Blacklisted Customer (Definition): some party the company prefers not to do business with because of a history of slow and/or non-payment Structural Rule: A Customer is considered Blacklisted if all the following are true: * The customer has placed at least 5 orders in the past 2 years. * Each order was not paid within 60 days of the date placed. * The order amount of each order is over $100. Does your proposal support that? I have difficulty in recognizing .some party the company prefers not to do business with because of a history of slow and/or non-payment. as a definition. It seems to me to be a way of stating a business policy .The company prefers not to do business with customers who have a history of slow and/or non-payment., in which "prefers" indicates an obligation that is not enforced 100%. Then, .blacklisted customer. needs to be defined, separately from the policy. Ron's structural rule looks very like an ISO intensional definition: Blacklisted customer more general concept: customer ... delimiting characteristics: ... who placed at least 5 orders in the past 2 years ... and who did not pay any order within 60 days of the date placed ... and who placed only orders with order amount over $100 It also seems to me that "customer who has a history of slow and/or non-payment" is not a satisfactory definition of "blacklisted customer". Just from the perspective of understanding everyday language, it also describes customers who placed fewer than 5 large orders and did not pay, or who placed lots of small orders and did not pay , or paid for some orders within 60 days but not others, etc. But it seems OK as a description. Once we have "blacklisted customer" defined, we can tighten up the definition of the business policy: .The company prefers not to do business with blacklisted customers. [Aside: the business might also want to define other policies for customers who have a history of slow and/or non-payment but don't have all the characteristics of a blacklisted customer, This might lead to an extensional definition of "customer with a history of slow and/or non-payment" - but that's outside the scope of this discussion.] One point that Ron has made in earlier discussions is that businesses want,over time, to change the criteria for categorization. For example, next year the company might define "blacklisted customer" as one who had placed 6 orders over $200 in three years and not paid any of them with 45 days. But at any given time there would be a unique value for each of: volume of orders, assessment period, order late payment deadline and significant order value. This sounds to me like the behavior of individual concepts over time. We have habitually used noun concepts to illustrate this: for example, "the president of the USA", which currently references George W Bush, but a few years ago would have referenced Bill Clinton, and in a few of years time might reference Condoleeza Rice or Hillary Clinton. We agreed a few weeks ago that individual concepts could also be verb concepts. I suggest that this is where changeable criteria fit. The delimiting characteristics of "blackisted customer" are individual verb concepts, that reference just one actuality at any given time:: Customer has placed high volume of orders within the assessment period Customer did not pay any order within the late payment deadline after the date placed Customer has placed only orders with order amount greater than significant order value The actualities that they currently reference are those in Ron's structural rule. Next year they might be different. Just as next year "the prime minister of the UK" may be someone other than Tony Blair. This approach - using SBVR built-in concepts to ensure "only one at any given time" - seems to me preferable to introducing explicit "only one a time" rules. It then seems to me that the following are four ways of saying the same thing: Blacklisted customer: customer who has placed high volume of orders within the assessment period and who did not pay any order within the late payment deadline after the date placed and who has placed only orders with order amount greater than significant order value. Blacklisted customer: customer who is high-value and who is slow to pay and who is high-item. Customer is high-value: the customer has placed high volume of orders within the assessment period Customer is slow to pay: the customer did not pay any order within the late payment deadline after the date placed Customer is high-item: the customer has placed only orders with order amount greater than significant order value Blacklisted customer: category of customer Necessity: Each blacklisted customer has placed high volume of orders within the assessment period. Necessity: Each blacklisted customer did not pay any order within the late payment deadline after the date placed. Necessity: Each blacklisted customer has placed only orders with order amount over the blacklist order value. Blacklisted customer: category of customer Structural rule: Each blacklisted customer has placed at least the blacklist minimum of orders within the assessment period and did not pay any order within the late payment deadline after the date placed and placed only orders with order amount over the blacklist order value. Note: I recognize that there are tidier ways to do this (e.g by defining categories of "order"), but I have tried to stay close to Ron's structural rule. Regards, John User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 18 May 2006 06:31:09 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ6f1J9kTcLLuZyEdqDSQARJM+Cgg== On 5/17/06 9:03 PM, "Ronald G. Ross" wrote: > > Note that Donald said 'delimiting *components*', but the fact type is > 'concept incorporates *characteristic*' (which would seem to exclude > necessities). ... >From yesterday's exchanges, I understood that things stated using the 'Necessity' caption were covered. Here is part of one of the notes: >> Characteristics that go beyond what is sufficient have been stated using >> the "Necessity" caption. Consider the second necessity listed under >> 'form of expression': "Each form of expression has at least one >> placeholder." So a characteristic of forms of expression is that they >> have at least one placeholder. >> Other characteristics are given in some of the other necessities listed >> under 'form of expression'. ... What does this miss? ~ Keri Subject: RE: issue 9613 -- SBVR FTF issue Date: Thu, 18 May 2006 10:13:05 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ6EfDSL3hiieYFEdqDSQARJM+CggAjDDeA From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 18 May 2006 17:13:25.0098 (UTC) FILETIME=[5F6C1CA0:01C67A9E] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k4IH1vbJ015653 Keri, Yes, you are getting close. Enjoy, Don -----Original Message----- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Wednesday, May 17, 2006 5:28 PM To: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue At 01:02 PM 5/17/2006, Donald Chapin wrote: >> I'm just saying that whatever form of representation is used for the >> 'intension' of a 'concept' that ALL the delimiting components are included >> in that form of representation. On 5/17/06 11:23 AM, "Ronald G. Ross" wrote: > Does SBVR require a new term to get at this? On 5/17/06 5:06 PM, "Baisley, Donald E" wrote: > We have been talking about characteristics that are incorporated by a > concept. These are the characteristics that make up the concept's > intension. So it seems that the SBVR notions for this are in place: i.e., the concept 'characteristic' and the fact type 'concept incorporates characteristic'. And we would use this, rather than the earlier terminology that was being used -- e.g., that of a 'definition' having 'parts', or 'components'. Is this close, Don? - Keri X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 18 May 2006 12:34:53 -0500 To: john.hall@modelsys.com From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: sbvr-ftf@omg.org At 12:35 AM 5/18/2006, John Hall wrote: Hello all, Ronald G. Ross wrote: ... here is an example what I must be able to do cleanly and directly: Blacklisted Customer (Definition): some party the company prefers not to do business with because of a history of slow and/or non-payment Structural Rule: A Customer is considered Blacklisted if all the following are true: * The customer has placed at least 5 orders in the past 2 years. * Each order was not paid within 60 days of the date placed. * The order amount of each order is over $100. Does your proposal support that? I have difficulty in recognizing .some party the company prefers not to do business with because of a history of slow and/or non-payment. as a definition. It seems to me to be a way of stating a business policy .The company prefers not to do business with customers who have a history of slow and/or non-payment., in which "prefers" indicates an obligation that is not enforced 100%. Then, .blacklisted customer. needs to be defined, separately from the policy. Ron's structural rule looks very like an ISO intensional definition: Blacklisted customer more general concept: customer ... delimiting characteristics: ... who placed at least 5 orders in the past 2 years ... and who did not pay any order within 60 days of the date placed ... and who placed only orders with order amount over $100 John, If that is to be the definition, why did the business chose "blacklisted" as the name of the concept? To me, the definition has lost the essence of the meaning suggested by "blacklisted". In other words, it doesn't really communicate. If you're suggesting that business people access the relevant business policy to understand the full essence of the concept "blacklisted", I suggest that might be impractical or unworkable for a whole variety of reasons. In any case (and perhaps I have not fully grasped your treatment of the example), you clearly have a preferred way of organizing full representation of the intension of a concept. (Note I purposely did not say just "definition".) At this stage of the FTF, I think the focus should be on specific limitations in SBVR, if any, that would prevent you from organizing intensions the way you prefer. Could you be more specific about what specific aspects of SBVR, if any, are giving you problems in that regard? I doubt that any of us at this late date will succeed in changing anybody's else's practice, but fortunately, SBVR is flexible enough to support a variety of powerful practices. Ron It also seems to me that "customer who has a history of slow and/or non-payment" is not a satisfactory definition of "blacklisted customer". Just from the perspective of understanding everyday language, it also describes customers who placed fewer than 5 large orders and did not pay, or who placed lots of small orders and did not pay , or paid for some orders within 60 days but not others, etc. But it seems OK as a description. Once we have "blacklisted customer" defined, we can tighten up the definition of the business policy: .The company prefers not to do business with blacklisted customers. [Aside: the business might also want to define other policies for customers who have a history of slow and/or non-payment but don't have all the characteristics of a blacklisted customer, This might lead to an extensional definition of "customer with a history of slow and/or non-payment" - but that's outside the scope of this discussion.] One point that Ron has made in earlier discussions is that businesses want,over time, to change the criteria for categorization. For example, next year the company might define "blacklisted customer" as one who had placed 6 orders over $200 in three years and not paid any of them with 45 days. But at any given time there would be a unique value for each of: volume of orders, assessment period, order late payment deadline and significant order value. This sounds to me like the behavior of individual concepts over time. We have habitually used noun concepts to illustrate this: for example, "the president of the USA", which currently references George W Bush, but a few years ago would have referenced Bill Clinton, and in a few of years time might reference Condoleeza Rice or Hillary Clinton. We agreed a few weeks ago that individual concepts could also be verb concepts. I suggest that this is where changeable criteria fit. The delimiting characteristics of "blackisted customer" are individual verb concepts, that reference just one actuality at any given time:: Customer has placed high volume of orders within the assessment period Customer did not pay any order within the late payment deadline after the date placed Customer has placed only orders with order amount greater than significant order value The actualities that they currently reference are those in Ron's structural rule. Next year they might be different. Just as next year "the prime minister of the UK" may be someone other than Tony Blair. This approach - using SBVR built-in concepts to ensure "only one at any given time" - seems to me preferable to introducing explicit "only one a time" rules. It then seems to me that the following are four ways of saying the same thing: Blacklisted customer: customer who has placed high volume of orders within the assessment period and who did not pay any order within the late payment deadline after the date placed and who has placed only orders with order amount greater than significant order value. Blacklisted customer: customer who is high-value and who is slow to pay and who is high-item. Customer is high-value: the customer has placed high volume of orders within the assessment period Customer is slow to pay: the customer did not pay any order within the late payment deadline after the date placed Customer is high-item: the customer has placed only orders with order amount greater than significant order value Blacklisted customer: category of customer Necessity: Each blacklisted customer has placed high volume of orders within the assessment period. Necessity: Each blacklisted customer did not pay any order within the late payment deadline after the date placed. Necessity: Each blacklisted customer has placed only orders with order amount over the blacklist order value. Blacklisted customer: category of customer Structural rule: Each blacklisted customer has placed at least the blacklist minimum of orders within the assessment period and did not pay any order within the late payment deadline after the date placed and placed only orders with order amount over the blacklist order value. Note: I recognize that there are tidier ways to do this (e.g by defining categories of "order"), but I have tried to stay close to Ron's structural rule. Regards, John User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 18 May 2006 10:41:54 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: Don Baisley , SBVR-FTF Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ6EfDSL3hiieYFEdqDSQARJM+CggAjDDeAAAEOFNo= And, Don, what would I have to do/understand to get not simply 'close' but to be right on the mark? TIA ~ Keri On 5/18/06 10:13 AM, "Baisley, Donald E" wrote: > Keri, > > Yes, you are getting close. > > Enjoy, > Don > > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: Wednesday, May 17, 2006 5:28 PM > To: SBVR-FTF > Subject: Re: issue 9613 -- SBVR FTF issue > > At 01:02 PM 5/17/2006, Donald Chapin wrote: >>> I'm just saying that whatever form of representation is used for the >>> 'intension' of a 'concept' that ALL the delimiting components are included >>> in that form of representation. > > On 5/17/06 11:23 AM, "Ronald G. Ross" wrote: >> Does SBVR require a new term to get at this? > > On 5/17/06 5:06 PM, "Baisley, Donald E" > wrote: >> We have been talking about characteristics that are incorporated by a >> concept. These are the characteristics that make up the concept's >> intension. > > > So it seems that the SBVR notions for this are in place: i.e., the concept > 'characteristic' and the fact type 'concept incorporates characteristic'. > > And we would use this, rather than the earlier terminology that was being used > -- e.g., that of a 'definition' having 'parts', or 'components'. > > Is this close, Don? > > - Keri > m: webmaster@omg.org Date: 10 May 2006 11:33:04 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Donald Chapin Company: Business Semantics Ltd mailFrom: Donald.Chapin@btinternet.com Notification: No Specification: Semantics of Business Vocabulary and Business Rules (SBVR) Section: Chapters 8,9,11,12 FormalNumber: dtc/06-03-02 Version: Interim Specification RevisionDate: March 2, 2006 Page: Affects the interpretation of many SBVR metamodel constructs Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727) Description Issue Name: "Explicitly Stated SBVR Architectural Principles for Relationships among 'Definitions' 'Rules' and 'Semantic Formulations'" Issue Statement: The lack of an explicitly stated, concise set of SBVR architectural principles regarding the relationship of 'definitions' 'rules' and 'semantic formulations' is causing much needless SBVR-FTF discussion around related topics. If this lack is causing a problem for the creators of SBVR, then it's going to be even harder for people in the rest of the world to understand and agree on this critical aspect of SBVR. A (strawman) set of SBVR architectural principles needs to be explicitly stated in SBVR as follows: 1. 'Definitions' and 'rules' are not the same thing as 'semantic formulations'. 2. 'Semantic formulations' structure the meaning of 'definitions' and of 'rules'. 3. The meaning of an 'operative business rule' is structured by a 'semantic formulation' that introduces an 'obligation'. 4. The meaning of a 'structural rule / definitional rule / definitional criterion' is structured by a 'semantic formulation' that introduces a 'necessity' which itself means 'true by definition'. 5. 'Intensional definitions' are made up of definitional components of two types: a. a 'more general concept' b. one or more 'delimiting' components 6. These 'delimiting' components may take either of two forms which are equivalent in meaning and can be converted to the other form at will without loss of meaning: a. the form of a 'characteristic' b. the form of a 'structural rule / definitional rule / definitional criterion' 7. The 'intensional definitions' in an SBVR Vocabulary can be composed using three combinations of these two forms: a. All definitions composed only of a 'more general concept' plus one or more 'structural rules / definitional rules / definitional criteria' b. All definitions composed only of a 'more general concept' (plus one or more 'characteristics'. c. Definitions composed of a 'more general concept' plus some 'structural rules / definitional rules / definitional criteria' and some 'characteristics' -- (the way many of the SBVR concepts are defined). 8. 'Structural rules / definitional rules / definitional criteria' exist only as components of an 'intensional definition'. This is a corollary of 'true by definition'.. 9. For a given discrete meaning there is a set of 'semantic formulations' that give form to its meaning. 10. There is a one-to-one relationship between an 'operative business rule' and the set of 'semantic formulations' of its discrete meaning. 11. There is a one-to-one relationship between a 'delimiting' component of an 'intensional definition' and the set of 'semantic formulations' of its discrete meaning. Subject: RE: issue 9613 -- SBVR FTF issue Date: Fri, 19 May 2006 10:36:26 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ0kbOq8krEoOCEEdqk1wARJM+CggFORUjwAASgQgcAAJYOGQABBpcAAAT9mHUAXLeVYA== From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 19 May 2006 17:36:52.0422 (UTC) FILETIME=[D0AA7660:01C67B6A] Keri, Good job. You pass the test with an A. Don -------------------------------------------------------------------------------- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Wednesday, May 17, 2006 2:20 PM To: Baisley, Donald E; SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue On 5/17/06 11:59 AM, "Baisley, Donald E" wrote: > Please read my previous email and then answer your own question. What > are the two necessary and sufficient characteristics that make up the > concept 'binary fact type' as given by its definition? I suppose it would look like this: Suppose I have this (high quality) definition of 'binary fact type': fact type that has exactly 2 roles The concept 'binary fact type' is defined in terms of a pair of necessary and sufficient characteristics. Each binary fact type: 1. is a fact type 2. has exactly 2 roles According to the definition, these two characteristics are sufficient to distinguish a binary fact type from other things. E.g. If something is a fact type and has exactly 2 roles, then it is a binary fact type. If something is not a fact type or has other than 2 roles, then it is not a binary fact type. Another musing... Why do we talk/write in terms of .necessary and sufficient. characteristics when the ISO (& SBVR) terminology is .essential and delimiting. characteristics? ~ Keri Date: Fri, 19 May 2006 17:40:13 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Baisley, Donald E" CC: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Baisley, Donald E wrote: Keri wrote: ... these three of the six are characteristics. No. The necessity statements are not characteristics and the meanings of the necessity statements are not characteristics. But from three of the six statements we understand that three respective characteristics are incorporated into the concept 'form of expression'. This last is a key idea. Donald explained to me that all fact-types designated Necessity either formalize elements of the definition of a concept or follow from the definition of the concept. That is why they are called "necessity". If for a given thing, any "necessity" does not hold, it cannot be that the thing is a referent of the concept. Is there such a thing as a characteristic of a concept that is beyond what is sufficient and also is not necessary? We have been talking about characteristics that are incorporated by a concept. These are the characteristics that make up the concept's intension. If I talk about "a characteristic of a concept", I mean something else altogether. This is semantic hairsplitting. What Keri meant was: Can a concept incorporate a characteristic that is not a necessary property? And the answer to that is: NO! The nature of a characteristic is to be a necessary property. Some sets of characteristics are "sufficient". While SBVR carefully chooses one sufficient set to characterize each concept, it is entirely possible that another dictionary would use a different set. This is possible when the one set of characteristics logically implies all the characteristics in the other set and vice versa. (Mathematics is replete with cases like this.) And that is part of what gives rise to necessary properties that aren't identified by SBVR as characteristics. Then, turning to the remaining 3 necessities listed under 'form of expression' (the 3rd, 4th, and 6th necessities), if these are not 'characteristics' of 'form of expression', what are they to 'form of expression'? The statements are all grouped under 'form of expression' because they are all about forms of expression. It's just a matter of organizational preference. The statements mean the same thing no matter where they appear in the organization of the SBVR document. I disagree. If they don't follow from the definition of 'form of expression', they are additional "structural rules" that SBVR imposes on well-formedness of vocabularies. And several of the "necessities" under 'form of expression' do NOT follow from the definition given. They follow from a particular form of template that is being specified by SBVR. In particular, there are mutual dependencies between the necessities for 'form of expression' and those for 'placeholder', and they are captured by the definition of 'placeholder' but not by the definition of 'form of expression' (which never mentions placeholders or designations, although both are required elements of the intended "template or pattern"). Note also that the Necessity: "Each form of expression has at least one placeholder" refers to a binary fact-type which somehow is not a characteristic of 'form of expression'. And that is because having placeholders is a characteristic of (the SBVR specialization of the NODE-defined term) 'template', which appears in the definition. There is a semantic trick here: 'having placeholders' is a "unary" characteristic, in that it doesn't refer to any placeholder in particular, but 'template has placeholder' is a (binary!) fact-type. In the same way, "having children" is a characteristic of 'parent', but 'parent has child' is a binary fact type. Now the interpretation of "having children", as it turns out, is *equivalent to* 'Each parent has at least 1 child'. That is why I say it is a semantic trick. In short, Keri, the reason why you are confused is that - 'form of expression' has a fuzzy definition, - 'form of expression' has a collection of rules that are called Necessity but don't obviously follow from the fuzzy definition. - a semantic trick is used to turn a necessity expressed via a binary fact-type into a unary characteristic. I don't see a need to be particularly concerned about this, because none of it is core content. The authors of OMG specifications are entitled to their sandboxes, just as OMG exploders provide soapboxes/pulpits for some others of us. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: RE: issue 9613 -- SBVR FTF issue Date: Fri, 19 May 2006 15:44:50 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ7jNN994Z8gcw1RDynGOq6eIFoLQABhAvg From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 19 May 2006 22:45:13.0901 (UTC) FILETIME=[E4681DD0:01C67B95] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k4JMXg0U004444 Ed wrote: > Donald explained to me that all fact-types > designated Necessity either formalize elements > of the definition of a concept or follow from > the definition of the concept.... all fact-types designated Necessity ... I don't understand what is meant by "all fact-types designated Necessity. I don't know of any fact type being designated as 'Necessity'. Ed, please clarify. Thanks, Don User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sun, 21 May 2006 06:11:59 -0700 Subject: Re: issue 9613 -- SBVR FTF issue From: John and Keri To: SBVR-FTF CC: Ed Barkmeyer , Don Baisley Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcZ82CRGYtAfXujLEdqnqAARJM+Cgg== >>> Keri wrote: >>> ... these three of the six are characteristics. >> Baisley, Donald E wrote: >> No. The necessity statements are not characteristics and the meanings >> of the necessity statements are not characteristics. But from three of >> the six statements we understand that three respective characteristics >> are incorporated into the concept 'form of expression'. > On 5/19/06 2:40 PM, "Ed Barkmeyer" wrote: > This last is a key idea. ... I decided to attack this from a different angle. I needed to stop looking at this through 'vocabulary' eyes (and in terms of the various kinds of entries we are reading and making) -- i.e., from the result/representation -- and start looking at the problem from the raw meaning/concept -- before it moves into a vocabulary (or other) presentation. >From this new perspective, I developed the following small example. ~~~~~~~~~~~~~~~~~~~~~ Let's say I have a concept that I want to understand/specify the meaning of -- I'll term it "myConcept". I ponder what it means to be a "myConcept" and discover that it incorporates six characteristics, as follows: Each myConcept: 1. is a derkle 2. has two bobbles 3. is not slonkable 4. has at least one glimpie 5. includes a frimble that is Red 6. owns trizone Next, I want to come up with a 'definition' (ISO/SBVR-style) for it, so I ponder this set of six and decide which of the six are the "necessary and sufficient" (essential and delimiting) subset. I decide that the "necessary and sufficient" subset is characteristics #1 and #4, so those are reflected in the SBVR-style "Dictionary-captioned" expression/representation in some vocabulary, as an entry under the primary designation, 'myConcept'. And since #1 happens to mean the more general concept, I can word the Definition (from characteristics #1 and #4) as: myConcept Definition: derkle that has at least one glimpie Next, I ponder the remaining 4 characteristics. I determine that three of them (#2, #3, and #5) are simply "necessary" (essential to the meaning of 'myConcept' but beyond what is "sufficient"). So, in my SBVR-style vocabulary, I state characteristics #2, #3, and #5 of myConcept using the "Necessity" caption: Necessity: Each myConcept has exactly two bobbles. Necessity: Each myConcept is not slonkable. Necessity: Each myConcept includes a frimble that is Red. That leaves characteristic #6. Since it is not "necessary" but it is on the initial candidate list as a characteristic of myConcept, how is this to be handled? I hear Ed and Don say that it (probably) is not a characteristic of myConcept. (I admit I was applying some 'row-3' thinking -- wanting to treat this as the analog of an 'optional attribute' of the entity/class.) > Ed wrote: > This is semantic hairsplitting. What Keri meant was: Can a concept > incorporate a characteristic that is not a necessary property? > > And the answer to that is: NO! The nature of a characteristic is to be a > necessary property. So It appears that I can do one of three things: (a) I could specify a specialization of myConcept -- one that does incorporate #6 as a characteristic. #6 would then be part of the intension of that concept. Or (b) I could simply have a binary fact type that involves 'myConcept', as follows: myConcept owns trizone Synonymous form: trizone is owned by myConcept Or (c) We do have the "Possibility" caption, which I understand we could use if the original characteristic #6 (above) was modified a bit, as follows: Each myConcept: ... 6. can own trizone Then, the following 'Possibility' captioned statement could be written as: Possibility: Each myConcept can own trizone. But 'can own trizone' is incorporated into 'myConcept' as a characteristic only if owning trizone is possible for every instance of 'myConcept'. ~~~~~~~~~~~~~~~~~~~~~ ~ Keri Donald explained to me that all fact-types > designated Necessity either formalize elements of the definition of a concept > or follow from the definition of the concept. That is why they are called > "necessity". If for a given thing, any "necessity" does not hold, it cannot > be that the thing is a referent of the concept. > >>> Is there such a thing as a characteristic of a concept that >>> is beyond what is sufficient and also is not necessary? >> >> We have been talking about characteristics that are incorporated by a >> concept. These are the characteristics that make up the concept's >> intension. If I talk about "a characteristic of a concept", I mean >> something else altogether. > > Some sets of characteristics are "sufficient". While SBVR carefully chooses > one sufficient set to characterize each concept, it is entirely possible that > another dictionary would use a different set. This is possible when the one > set of characteristics logically implies all the characteristics in the other > set and vice versa. (Mathematics is replete with cases like this.) And that > is part of what gives rise to necessary properties that aren't identified by > SBVR as characteristics. > >>> Then, turning to the remaining 3 necessities listed under 'form >>> of expression' (the 3rd, 4th, and 6th necessities), if these are >>> not 'characteristics' of 'form of expression', what are they to >>> 'form of expression'? >> >> The statements are all grouped under 'form of expression' because they >> are all about forms of expression. It's just a matter of organizational >> preference. The statements mean the same thing no matter where they >> appear in the organization of the SBVR document. > > I disagree. If they don't follow from the definition of 'form of expression', > they are additional "structural rules" that SBVR imposes on well-formedness of > vocabularies. And several of the "necessities" under 'form of expression' do > NOT follow from the definition given. They follow from a particular form of > template that is being specified by SBVR. In particular, there are mutual > dependencies between the necessities for 'form of expression' and those for > 'placeholder', and they are captured by the definition of 'placeholder' but > not by the definition of 'form of expression' (which never mentions > placeholders or designations, although both are required elements of the > intended "template or pattern"). > > Note also that the Necessity: "Each form of expression has at least one > placeholder" refers to a binary fact-type which somehow is not a > characteristic of 'form of expression'. And that is because having > placeholders is a characteristic of (the SBVR specialization of the > NODE-defined term) 'template', which appears in the definition. > > There is a semantic trick here: 'having placeholders' is a "unary" > characteristic, in that it doesn't refer to any placeholder in particular, but > 'template has placeholder' is a (binary!) fact-type. In the same way, "having > children" is a characteristic of 'parent', but 'parent has child' is a binary > fact type. Now the interpretation of "having children", as it turns out, is > *equivalent to* 'Each parent has at least 1 child'. That is why I say it is a > semantic trick. > > In short, Keri, the reason why you are confused is that > - 'form of expression' has a fuzzy definition, > - 'form of expression' has a collection of rules that are called Necessity but > don't obviously follow from the fuzzy definition. > - a semantic trick is used to turn a necessity expressed via a binary > fact-type into a unary characteristic. > > I don't see a need to be particularly concerned about this, because none of it > is core content. The authors of OMG specifications are entitled to their > sandboxes, just as OMG exploders provide soapboxes/pulpits for some others of > us. > Date: Fri, 26 May 2006 15:25:54 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Baisley, Donald E" CC: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No I wrote: Donald explained to me that all fact-types designated Necessity either formalize elements of the definition of a concept or follow from the definition of the concept.... all fact-types designated Necessity Don wrote: I don't understand what is meant by "all fact-types designated Necessity. I don't know of any fact type being designated as 'Necessity'. I meant: Donald explained to me that all SBVR statements (assertions) designated Necessity either formalize elements of the definition of a concept or follow from the definition of the concept. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 26 May 2006 21:28:45 -0500 To: edbark@nist.gov, "Baisley, Donald E" From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF , Donald Chapin At 02:25 PM 5/26/2006, Ed Barkmeyer wrote: I wrote: Donald explained to me that all fact-types designated Necessity either formalize elements of the definition of a concept or follow from the definition of the concept.... all fact-types designated Necessity Don wrote: I don't understand what is meant by "all fact-types designated Necessity. I don't know of any fact type being designated as 'Necessity'. I meant: Donald explained to me that all SBVR statements (assertions) designated Necessity either formalize elements of the definition of a concept or follow from the definition of the concept. Donald has promised to address some outstanding questions about his 'Architectural Principles'. One of these questions, as Don B. pointed out, had to do with Definition being on the expression side, whereas meaning, intension, etc., of course, is not. I think that's a key distinction. While awaiting Donald's clarifications, I can certainly see Necessities refining (enlarging) the intension of a concept and thereby, reducing the extension. A Definition (Intensional) on the other hand, gives a more general concept and delimiting characteristics. According to ISO (1087), a definition "serves to differentiate the concept from related concepts". That would seem to give a lot of latitude, especially if people are doing the reading and differentiating. Be that as it may, here are some questions/thought for Donald (I guess): * I can certainly see Necessities formalizing elements of the *intension*. That's probably always true. * I can see some Necessities included in an intension implying other Necessities in that intension. (This could either be through subsumption or mutual implication, for example). * What I can't see is that all Necessities *follow from* the *definition* of the concept, if we mean by "follow from" that they are *implied by* (inevitable from) the definition. On the other hand, if "follow from" means "must be consistent with", well, sure. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Tue, 30 May 2006 15:57:40 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Ronald G. Ross" CC: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No I wrote: Donald explained to me that all SBVR statements (assertions) designated Necessity either formalize elements of the definition of a concept or follow from the definition of the concept. Ron wrote: Donald has promised to address some outstanding questions about his 'Architectural Principles'. One of these questions, as Don B. pointed out, had to do with Definition being on the expression side, whereas meaning, intension, etc., of course, is not. I think that's a key distinction. OK. While awaiting Donald's clarifications, I can certainly see Necessities refining (enlarging) the intension of a concept and thereby, reducing the extension. A Definition (Intensional) on the other hand, gives a more general concept and delimiting characteristics. According to ISO (1087), a definition "serves to differentiate the concept from related concepts". That would seem to give a lot of latitude, especially if people are doing the reading and differentiating. Be that as it may, here are some questions/thought for Donald (I guess): * I can certainly see Necessities formalizing elements of the *intension*. That's probably always true. * I can see some Necessities included in an intension implying other Necessities in that intension. (This could either be through subsumption or mutual implication, for example). * What I can't see is that all Necessities *follow from* the *definition* of the concept, if we mean by "follow from" that they are *implied by* (inevitable from) the definition. On the other hand, if "follow from" means "must be consistent with", well, sure. And this last is precisely the issue on which we *need* an "architectural principle". If we state a "Necessity" that is not implied by the definition, in the context of other definitions in the vocabulary, then one of two things must be the case: (a) the would-be "definition" does not characterize the concept well enough that some individuals not intended to be in the extension might (without the additional Necessity) be taken to be in the extension. (b) the would-be "Necessity" is actually a *rule* that makes some individuals in the actual extension "unacceptable" for use in the speech community and situation to which the vocabulary is to be applied. We don't want to exclude those individuals/states by definition, but we do want to exclude them for this use. (b) is a subtle point, but it happens all the time: The vocabulary term is taken from a larger speech community, and we don't want to explicitly qualify it in every use in our domain. But we do want to constrain the admissible individuals (typically states of affairs) for our domain. IMO, if we have a "Necessity" that is not part of or implied by the definition, we need to determine which of (a) and (b) is the case. And if it is (a), we need to fix the definition, and if it is (b), we need to put a red flag in the text to the effect that we are stating a requirement for valid individuals for formal SBVR (and probably in every case for SBVR Structured English only). -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.594,BAYES_00: -1.665 X-Spam-Level: X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 31 May 2006 15:17:42 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 02:57 PM 5/30/2006, Ed Barkmeyer wrote: I wrote: Donald explained to me that all SBVR statements (assertions) designated Necessity either formalize elements of the definition of a concept or follow from the definition of the concept. Ron wrote: Donald has promised to address some outstanding questions about his 'Architectural Principles'. One of these questions, as Don B. pointed out, had to do with Definition being on the expression side, whereas meaning, intension, etc., of course, is not. I think that's a key distinction. OK. While awaiting Donald's clarifications, I can certainly see Necessities refining (enlarging) the intension of a concept and thereby, reducing the extension. A Definition (Intensional) on the other hand, gives a more general concept and delimiting characteristics. According to ISO (1087), a definition "serves to differentiate the concept from related concepts". That would seem to give a lot of latitude, especially if people are doing the reading and differentiating. Be that as it may, here are some questions/thought for Donald (I guess): * I can certainly see Necessities formalizing elements of the *intension*. That's probably always true. * I can see some Necessities included in an intension implying other Necessities in that intension. (This could either be through subsumption or mutual implication, for example). * What I can't see is that all Necessities *follow from* the *definition* of the concept, if we mean by "follow from" that they are *implied by* (inevitable from) the definition. On the other hand, if "follow from" means "must be consistent with", well, sure. And this last is precisely the issue on which we *need* an "architectural principle". If we state a "Necessity" that is not implied by the definition, in the context of other definitions in the vocabulary, then one of two things must be the case: (a) the would-be "definition" does not characterize the concept well enough that some individuals not intended to be in the extension might (without the additional Necessity) be taken to be in the extension. (b) the would-be "Necessity" is actually a *rule* that makes some individuals in the actual extension "unacceptable" for use in the speech community and situation to which the vocabulary is to be applied. We don't want to exclude those individuals/states by definition, but we do want to exclude them for this use. (b) is a subtle point, but it happens all the time: The vocabulary term is taken from a larger speech community, and we don't want to explicitly qualify it in every use in our domain. But we do want to constrain the admissible individuals (typically states of affairs) for our domain. IMO, if we have a "Necessity" that is not part of or implied by the definition, we need to determine which of (a) and (b) is the case. And if it is (a), we need to fix the definition, and if it is (b), we need to put a red flag in the text to the effect that we are stating a requirement for valid individuals for formal SBVR (and probably in every case for SBVR Structured English only). Ed, The last part of your answer seems to be worded such that it applies to the SBVR vocabulary itself, not to definitions in general. But is that what you intended?! Sorry, I got a little lost there. With respect to 'a', ISO says a definition "serves to differentiate the concept from related concepts". I don't find anywhere that it says there is a problem with a *definition* not *exactly* defining (implying) the extension (at a point in time). Are you saying differently? For example, I would like a good definition of "planet" to be the same today as tomorrow, even if new discoveries necessitate new Necessities to say what individuals qualify, and which don't. Disagree? Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Wed, 31 May 2006 18:18:38 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Ronald G. Ross" CC: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No I wrote: IMO, if we have a "Necessity" that is not part of or implied by the definition, we need to determine which of (a) and (b) is the case. And if it is (a), we need to fix the definition, and if it is (b), we need to put a red flag in the text to the effect that we are stating a requirement for valid individuals for formal SBVR (and probably in every case for SBVR Structured English only). Ron wrote: The last part of your answer seems to be worded such that it applies to the SBVR vocabulary itself, not to definitions in general. But is that what you intended?! Sorry, I got a little lost there. All of this applies to Definitions in SBVR-defined Vocabularies. At best it serves as guidance for business vocabularies. What I meant is that in SBVR we may define a term with a "complete" Definition, but further restrict it with a Necessity that is not implied by the definition, where that Necessity in effect applies to a particular form of expression, e.g. SBVR Structured English, or perhaps to its use in SBVR itself, but possibly not to its use in conforming Business Vocabularies that import the SBVR vocabulary that contains that Definition. I would hope that there aren't many Necessities of this latter kind (case (b)). With respect to 'a', ISO says a definition "serves to differentiate the concept from related concepts". I don't find anywhere that it says there is a problem with a *definition* not *exactly* defining (implying) the extension (at a point in time). Are you saying differently? For example, I would like a good definition of "planet" to be the same today as tomorrow, even if new discoveries necessitate new Necessities to say what individuals qualify, and which don't. Disagree? If you have new Necessities to say which individuals qualify, is it possible that the new Necessity eliminates Pluto? If you add new Necessities, you are changing the definition. Now that Necessity may be a further "clarification" that doesn't invalidate any prior categorizations. But you do have to define the extension by an intensional definition that is good enough to distinguish a planet from a satellite or an asteroid or a comet or some other bizarre object in Oort's cloud (i.e., good enough to "differentiate the concept from related concepts"). In my view, case (a) specifically refers to Necessities that are part of that differentiation and therefore should be included somehow in the definition. If the old Definition wasn't good enough to do that, and you added a new Necessity to make that differentiation possible, then that new Necessity is a part of the new Definition. It would be useful to have some examples. But Issue 9613 doesn't cite any. When I asked about the relationship between Necessity and Definition, Donald told me that Necessities are part of, or implied by, the Definition. The consequence of this is that any 'thing' that violates a Necessity is *by definition* not an instance of the concept with that Necessity. Therefore, it is not possible for a Necessity to be violated. Given: Definition: A 'scholar' is a 'student' who passes all exams Necessity: Each scholar passes the final exam and John did not pass the final exam we can conclude John is NOT a 'scholar'. I am comfortable with this; others may not be. Any other would-be "Necessity" is really a "structural rule" -- a business rule for the (static) behaviors and relationships of instances of that concept in the reference business environment. Unlike a true "Necessity", a structural rule can in fact be violated. Given: Definition: A 'scholar' is a 'student' with a GPA of 3.5 or better. Structural rule: Each scholar MUST pass the final exam and John's GPA is 3.8. John did not pass the final exam. we can conclude John is a 'scholar' but the rule has been violated. If you called that Structural rule a Necessity, you don't have a rule violation, you have a *contradiction* in your KB: John is a scholar AND John is NOT a scholar. And since, from a contradiction you might have *deduced* all kinds of nonsense (who knows what all rules it caused to fire?), the entire KB is unreliable. The classic example in upper ontologies: Cows are herbivores. Herbivores do not eat animal tissue. "Mad cow disease" comes only from eating contaminated beef brains. At least one British cow had mad cow disease. Implication: UK Cows eat animal tissue. UK Cows are not herbivores. No UK Cow is a Cow. Implication: All UK dairy farms raise goats. Stilton cheese is made from imported milk. And so on. Garbage In, Garbage Out. One contradiction can contaminate the whole KB. (The final deduction in someone's version is that cheese is chalk.) So it is very important to distinguish Necessities from other structural rules and ad hoc constraints. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.391,BAYES_00: -1.665, HTML_10_20: 1.35,HTML_MESSAGE: 0.001,MIME_HTML_ONLY: 1.156 X-Spam-Level: X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Jun 2006 02:42:39 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 05:18 PM 5/31/2006, Ed Barkmeyer wrote: Ron wrote: With respect to 'a', ISO says a definition "serves to differentiate the concept from related concepts". I don't find anywhere that it says there is a problem with a *definition* not *exactly* defining (implying) the extension (at a point in time). Are you saying differently? For example, I would like a good definition of "planet" to be the same today as tomorrow, even if new discoveries necessitate new Necessities to say what individuals qualify, and which don't. Disagree? If you have new Necessities to say which individuals qualify, is it possible that the new Necessity eliminates Pluto? If you add new Necessities, you are changing the definition. You are changing the intension, but you are not necessarily changing the definition. It is extremely important to maintain the SBVR separation between meaning and expression of meaning. Everything in SBVR depends on that. I am still not satisfied that this distinction is being incorporated properly into this discussion, but maybe it will become clear. Now that Necessity may be a further "clarification" that doesn't invalidate any prior categorizations. But you do have to define the extension by an intensional definition that is good enough to distinguish a planet from a satellite or an asteroid or a comet or some other bizarre object in Oort's cloud (i.e., good enough to "differentiate the concept from related concepts"). In my view, case (a) specifically refers to Necessities that are part of that differentiation and therefore should be included somehow in the definition. Stated characteristics that are delimiting for a definition could also be expressed as Necessities. To my knowledge, SBVR does not current have a way to form a Definition with a more general concept and either (a) delimiting characteristics that are expressed *separately* or (b) those same delimiting characteristics expressed as (separate) Necessities. I believe Donald has said as much. But I'm not yet convinced that SBVR needs that since we have the underlying concept of intension. As long as intension can be formed properly in logical formulations, does it make any difference? If the old Definition wasn't good enough to do that, and you added a new Necessity to make that differentiation possible, then that new Necessity is a part of the new Definition. In my view, Pluto ceasing to be a planet tomorrow because a new Necessity added a degree of precision to the intension that didn't exist before does not necessarily mean that the old definition of 'planet' should *necessarily* be replaced. For example, a Necessity about tilt of orbit could come into play that was never there before. Does that *really* invalidate a *definition* (remember, definitions are *expressions*) that changes the essence of what a planet is (as represented by intension)? I think not. (There could be some that do, but that one probably doesn't.) Businesses need structural continuity of basic expressed meaning! It would be useful to have some examples. But Issue 9613 doesn't cite any. When I asked about the relationship between Necessity and Definition, Donald told me that Necessities are part of, or implied by, the Definition. The consequence of this is that any 'thing' that violates a Necessity is *by definition* not an instance of the concept with that Necessity. Therefore, it is not possible for a Necessity to be violated. Given: Definition: A 'scholar' is a 'student' who passes all exams Necessity: Each scholar passes the final exam and John did not pass the final exam we can conclude John is NOT a 'scholar'. I am comfortable with this; others may not be. I have no problem with this reasoning. However: * The Necessity is redundant and could be eliminated. I final exam *is* an exam, and the Definition already necessitates it. * I do not think the definition is a good one. It is much too specific to convey the *essence* of the concept. The *core* notion of 'scholar' today is not the same as the *core* notion of scholar tomorrow if we change "all" (exams) to 99% (of exams)? Nonsense. I would have *defined* scholar as 'a student who consistently demonstrates a high level of performance on scholastic challenges presented by the school'. That's what's needed for fundamental person-to-person business communication over time. Then let Necessities (e.g., "99% of exams taken") define the complete intension, and by that means the actual extension. * I do not think that the "99% of exams taken" Necessity is *implied* by the [my] definition. * I think the "99% of exams taken" is a structural *rule*. * Handling variability through *rules* (not definitions) is the essence of the business rules approach [my view]. * I would be *strongly* opposed to any specification in SBVR that prevents or discourages the practices I am describing. Any other would-be "Necessity" is really a "structural rule" -- a business rule for the (static) behaviors and relationships of instances of that concept in the reference business environment. Unlike a true "Necessity", a structural rule can in fact be violated. No. A structural rule *cannot* be violated. It can be misapplied, misunderstood or ill-conceived, but it *cannot* be violated. Only *humans* can violate business rules, which immediately makes them (the rules) operative. (P.S., If you are writing rule evaluation software, you could find that one of your propositions you said always had to be true (say a Necessity) is currently -- temporarily -- false, but that's a *system* view of rules, not a real-world view of rules. I'm sure you already understand that, although I find people getting it confused over that *a lot* ... especially software people!) Given: Definition: A 'scholar' is a 'student' with a GPA of 3.5 or better. Structural rule: Each scholar MUST pass the final exam and John's GPA is 3.8. John did not pass the final exam. we can conclude John is a 'scholar' but the rule has been violated. If you define that structural rule (as you did), then John is *not* a scholar any more. Period. John *cannot* be in the intension of 'scholar'. (P.S. "Must" is not generally preferred for structural rules since it generally is taken to connote 'obligation'.) If you called that Structural rule a Necessity, you don't have a rule violation, you have a *contradiction* in your KB: John is a scholar AND John is NOT a scholar. And since, from a contradiction you might have *deduced* all kinds of nonsense (who knows what all rules it caused to fire?), the entire KB is unreliable. There is no contradiction in the KB. *All* the 'constraints' on the intension must be satisfied -- whether arising from the definition or the structural rules (Necessities). Period. The classic example in upper ontologies: Cows are herbivores. Herbivores do not eat animal tissue. "Mad cow disease" comes only from eating contaminated beef brains. At least one British cow had mad cow disease. Implication: UK Cows eat animal tissue. UK Cows are not herbivores. No UK Cow is a Cow. Implication: All UK dairy farms raise goats. Stilton cheese is made from imported milk. And so on. Garbage In, Garbage Out. One contradiction can contaminate the whole KB. (The final deduction in someone's version is that cheese is chalk.) So it is very important to distinguish Necessities from other structural rules and ad hoc constraints. It is very important to distinguish *necessities* (which help form intensions, and can't be violated) from obligations (which *people* can violate). And that's exactly the difference between Structural (Definitional) Rules and Operative (Behavioral) Rules, and a central notion of SBVR. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,BAYES_00: -1.665,HTML_20_30: 0.567, HTML_MESSAGE: 0.001,MIME_HTML_ONLY: 1.156 X-Spam-Level: X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Jun 2006 02:36:10 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 05:18 PM 5/31/2006, Ed Barkmeyer wrote: I wrote: IMO, if we have a "Necessity" that is not part of or implied by the definition, we need to determine which of (a) and (b) is the case. And if it is (a), we need to fix the definition, and if it is (b), we need to put a red flag in the text to the effect that we are stating a requirement for valid individuals for formal SBVR (and probably in every case for SBVR Structured English only). Ron wrote: The last part of your answer seems to be worded such that it applies to the SBVR vocabulary itself, not to definitions in general. But is that what you intended?! Sorry, I got a little lost there. All of this applies to Definitions in SBVR-defined Vocabularies. At best it serves as guidance for business vocabularies. What I meant is that in SBVR we may define a term with a "complete" Definition, but further restrict it with a Necessity that is not implied by the definition, where that Necessity in effect applies to a particular form of expression, e.g. SBVR Structured English, or perhaps to its use in SBVR itself, but possibly not to its use in conforming Business Vocabularies that import the SBVR vocabulary that contains that Definition. I would hope that there aren't many Necessities of this latter kind (case (b)). O.K., until I see an example, I will also hope there are not many of these cases. Ron X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.196,BAYES_00: -1.665, HTML_10_20: 1.35,HTML_MESSAGE: 0.001,MIME_HTML_ONLY: 1.156 X-Spam-Level: X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Jun 2006 02:49:02 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 05:18 PM 5/31/2006, Ed Barkmeyer wrote: Ron wrote: With respect to 'a', ISO says a definition "serves to differentiate the concept from related concepts". I don't find anywhere that it says there is a problem with a *definition* not *exactly* defining (implying) the extension (at a point in time). Are you saying differently? For example, I would like a good definition of "planet" to be the same today as tomorrow, even if new discoveries necessitate new Necessities to say what individuals qualify, and which don't. Disagree? If you have new Necessities to say which individuals qualify, is it possible that the new Necessity eliminates Pluto? If you add new Necessities, you are changing the definition. You are changing the intension, but you are not necessarily changing the definition. It is extremely important to maintain the SBVR separation between meaning and expression of meaning. Everything in SBVR depends on that. I am still not satisfied that this distinction is being incorporated properly into this discussion, but maybe it will become clear. Now that Necessity may be a further "clarification" that doesn't invalidate any prior categorizations. But you do have to define the extension by an intensional definition that is good enough to distinguish a planet from a satellite or an asteroid or a comet or some other bizarre object in Oort's cloud (i.e., good enough to "differentiate the concept from related concepts"). In my view, case (a) specifically refers to Necessities that are part of that differentiation and therefore should be included somehow in the definition. Stated characteristics that are delimiting for a definition could also be expressed as Necessities. To my knowledge, SBVR does not current have a way to form a Definition with a more general concept and either (a) delimiting characteristics that are expressed *separately* or (b) those same delimiting characteristics expressed as (separate) Necessities. I believe Donald has said as much. But I'm not yet convinced that SBVR needs that since we have the underlying concept of intension. As long as intension can be formed properly in logical formulations, does it make any difference? If the old Definition wasn't good enough to do that, and you added a new Necessity to make that differentiation possible, then that new Necessity is a part of the new Definition. In my view, Pluto ceasing to be a planet tomorrow because a new Necessity added a degree of precision to the intension that didn't exist before does not necessarily mean that the old definition of 'planet' should *necessarily* be replaced. For example, a Necessity about tilt of orbit could come into play that was never there before. Does that *really* invalidate a *definition* (remember, definitions are *expressions*) that changes the essence of what a planet is (as represented by intension)? I think not. (There could be some that do, but that one probably doesn't.) Businesses need structural continuity of basic expressed meaning! It would be useful to have some examples. But Issue 9613 doesn't cite any. When I asked about the relationship between Necessity and Definition, Donald told me that Necessities are part of, or implied by, the Definition. The consequence of this is that any 'thing' that violates a Necessity is *by definition* not an instance of the concept with that Necessity. Therefore, it is not possible for a Necessity to be violated. Given: Definition: A 'scholar' is a 'student' who passes all exams Necessity: Each scholar passes the final exam and John did not pass the final exam we can conclude John is NOT a 'scholar'. I am comfortable with this; others may not be. I have no problem with this reasoning. However: * The Necessity is redundant and could be eliminated. I final exam *is* an exam, and the Definition already necessitates it. * I do not think the definition is a good one. It is much too specific to convey the *essence* of the concept. The *core* notion of 'scholar' today is not the same as the *core* notion of scholar tomorrow if we change "all" (exams) to 99% (of exams)? Nonsense. I would have *defined* scholar as 'a student who consistently demonstrates a high level of performance on scholastic challenges presented by the school'. That's what's needed for fundamental person-to-person business communication over time. Then let Necessities (e.g., "99% of exams taken") define the complete intension, and by that means the actual extension. * I do not think that the "99% of exams taken" Necessity is *implied* by the [my] definition. * I think the "99% of exams taken" is a structural *rule*. * Handling variability through *rules* (not definitions) is the essence of the business rules approach [my view]. * I would be *strongly* opposed to any specification in SBVR that prevents or discourages the practices I am describing. Any other would-be "Necessity" is really a "structural rule" -- a business rule for the (static) behaviors and relationships of instances of that concept in the reference business environment. Unlike a true "Necessity", a structural rule can in fact be violated. No. A structural rule *cannot* be violated. It can be misapplied, misunderstood or ill-conceived, but it *cannot* be violated. Only *humans* can violate business rules, which immediately makes them (the rules) operative. (P.S., If you are writing rule evaluation software, you could find that one of your propositions you said always had to be true (say a Necessity) is currently -- temporarily -- false, but that's a *system* view of rules, not a real-world view of rules. I'm sure you already understand that, although I find people getting it confused over that *a lot* ... especially software people!) Given: Definition: A 'scholar' is a 'student' with a GPA of 3.5 or better. Structural rule: Each scholar MUST pass the final exam and John's GPA is 3.8. John did not pass the final exam. we can conclude John is a 'scholar' but the rule has been violated. If you define that structural rule (as you did), then John is *not* a scholar any more. Period. John *cannot* be in the intension of 'scholar'. (P.S. "Must" is not generally preferred for structural rules since it generally is taken to connote 'obligation'.) If you called that Structural rule a Necessity, you don't have a rule violation, you have a *contradiction* in your KB: John is a scholar AND John is NOT a scholar. And since, from a contradiction you might have *deduced* all kinds of nonsense (who knows what all rules it caused to fire?), the entire KB is unreliable. There is no contradiction in the KB. *All* the 'constraints' on the intension must be satisfied -- whether arising from the definition or the structural rules (Necessities). Period. The classic example in upper ontologies: Cows are herbivores. Herbivores do not eat animal tissue. "Mad cow disease" comes only from eating contaminated beef brains. At least one British cow had mad cow disease. Implication: UK Cows eat animal tissue. UK Cows are not herbivores. No UK Cow is a Cow. Implication: All UK dairy farms raise goats. Stilton cheese is made from imported milk. And so on. Garbage In, Garbage Out. One contradiction can contaminate the whole KB. (The final deduction in someone's version is that cheese is chalk.) So it is very important to distinguish Necessities from other structural rules and ad hoc constraints. It is very important to distinguish *necessities* (which help form intensions, and can't be violated) from obligations (which *people* can violate). And that's exactly the difference between Structural (Definitional) Rules and Operative (Behavioral) Rules, and a central notion of SBVR. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Thu, 01 Jun 2006 11:42:46 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Ronald G. Ross" CC: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Ronald G. Ross wrote: You are changing the intension, but you are not necessarily changing the definition. I did not understand this statement. To me, "intension" IS the "definition" -- the intension is the specification that determines membership in the extension. If a thing does not satisfy the intension of a concept, it ain't one. It is extremely important to maintain the SBVR separation between meaning and expression of meaning. OK. So Ron is distinguishing between the "intension", which is the meaning, and the expression of the intension, which is the "definition" in some language. Then I will simply say that if the definition does not properly phrase the intension, the definition is incorrect. That is, what it says is not what was meant. Stated characteristics that are delimiting for a definition could also be expressed as Necessities. To my knowledge, SBVR does not current have a way to form a Definition with a more general concept and either (a) delimiting characteristics that are expressed *separately* or (b) those same delimiting characteristics expressed as (separate) Necessities. I believe Donald has said as much. But I'm not yet convinced that SBVR needs that since we have the underlying concept of intension. As long as intension can be formed properly in logical formulations, does it make any difference? I would agree with that, but "logical formulation" as specified in clauses 9 and 10 still need alignment and clarification. If the old Definition wasn't good enough to do that, and you added a new Necessity to make that differentiation possible, then that new Necessity is a part of the new Definition. In my view, Pluto ceasing to be a planet tomorrow because a new Necessity added a degree of precision to the intension that didn't exist before does not necessarily mean that the old definition of 'planet' should *necessarily* be replaced. Well, "effectivity" of a definition is another matter. A change in the scientific understanding propagates to changes in definition in various communities at various times (big problem in textbooks and references). But at the time the Necessity is formally introduced into a community, the intension has changed, and the Definition should change to match. For example, a Necessity about tilt of orbit could come into play that was never there before. Does that *really* invalidate a *definition* (remember, definitions are *expressions*) that changes the essence of what a planet is (as represented by intension)? I think not. I strongly disagree. If the community adopts the new Necessity, the old definition in inaccurate, and will cause confusion in communications. Businesses need structural continuity of basic expressed meaning! At one level, that is the "effectivity" issue. In your community, you can maintain the old definition as long as it is prudent to do so. The British Empire, for example, maintained the custom of designating dates "Old Style" and "New Style" into the 19th century, even though the calendar change was made in 1732. At another level, "continuity at all cost" is "refusal to adapt to change" -- a rigid attitude that makes the business very fragile. Part of the problem here is well-known in the evolution of knowledge models. Two important cases: 1. The same term has been used to designate two closely related concepts, because in all practical cases, the relationship is 1-to-1 and most users do not distinguish those concepts. Suddenly, a new observation or technology gives rise to many useful examples in which the relationship is 1-to-n or 0-to-1. (Consider "telephone network".) This forces a terminological evolution that makes the distinction, but a given speech community has to determine the relative importance of the distinction. 2. A characteristic formerly assigned to a general concept turns out only to hold for a more specific concept, which did not formerly have a term, and there are now useful examples of the general concept that don't have the characteristic. The terminological evolution in a given community will depend on whether that characteristic is important in that community. And when these evolutions occur, rules, laws, textbooks, etc., all have to change accordingly. In short, meanings change. And Necessities are part of the meaning. When you add a Necessity, you have changed the meaning. It would be wise to change the Definition to match. [discussion of bad example deleted] Any other would-be "Necessity" is really a "structural rule" -- a business rule for the (static) behaviors and relationships of instances of that concept in the reference business environment. Unlike a true "Necessity", a structural rule can in fact be violated. No. A structural rule *cannot* be violated. I did not understand this. To me, it means that a "structural rule" is in effect part of the definition of (one or more of) the terms involved. Further, I think that Terry and the database logic folks would have to disagree with this. Some structural rules are effectively impossible to violate because the information recording technology enforces the rule. But many "structural rules" ("integrity constraints") are enforced on database models "externally" to capture and quarantine inconsistencies in information. In practice, such rules are violated in transactions all the time, and the nature of the enforcement policy is to prevent such violations from corrupting the active information base. (This is what the RIF WG calls "normative rules".) I am reminded of a certain FreddieMac (FHLMC) officer who told me it was not possible that the interest rate on a loan would be greater than 15%. So I offered an enforcement policy that deletes all loans from that region if such a rate is encountered -- it is not a loan, and therefore what the region sent is not a set of loans. "Well, I suppose if the data were entered incorrectly, and the regional office didn't check it properly, ..." We settled for creating an exception file. And in the first 6 months of operation, we had 1200 loans in the exception file at one time or another. Structural rules ARE violated. It can be misapplied, misunderstood or ill-conceived, but it *cannot* be violated. Only *humans* can violate business rules, which immediately makes them (the rules) operative. First of all, that is not true. Machines can violate business rules, when they are entrusted with their execution, sometimes by erroneous design, sometimes by physical failure, sometimes by circumstances beyond their control. ("I don't know why that machine won't accept your card; this machine does.") Second, the purpose of many "normative" ("structural") rules is to identify from the artifacts that some operative business rule has been violated, misapplied, or misunderstood. In the FHLMC example, we got garbage because the regional software didn't check the data it sent us, even though the agreed-upon business rules said they would perform those tests. And their structural rule checking was designed to detect that the human who keyboarded the data from the paper forms put the values in the wrong columns. So there is indeed some operative rule that is being violated, but the structural rule is not itself operative. It is very important to distinguish *necessities* (which help form intensions, and can't be violated) from obligations (which *people* can violate). And that's exactly the difference between Structural (Definitional) Rules and Operative (Behavioral) Rules, and a central notion of SBVR. This is part of the confusion that has been generated. I certainly understood the distinction, but I didn't realize that "Structural Rule" meant "Definitional Rule". I don't object to the terminology, but I think the (important) concept of static "normative" rule is thereby excluded from SBVR. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.842,BAYES_00: -1.665 X-Spam-Level: X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Jun 2006 11:45:15 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 10:42 AM 6/1/2006, Ed Barkmeyer wrote: Ronald G. Ross wrote: You are changing the intension, but you are not necessarily changing the definition. I did not understand this statement. To me, "intension" IS the "definition" I wish someone else would jump in on this ... but no, a definition in SBVR is a *representation* (expression) formed by *stating* a general concept and some *delimiting* characteristics (enough for people to meaningfully distinguish it from related concepts). The full intension is the concept is *more* than that ... in my view, it is the *meaning* of the definition, plus the meaning of all pertinent Necessities. For a highly complex concept, there could be *lots* of Necessities. Would you really always want to express all of them in the definition? Would that facilitate *human* communication?? -- the intension is the specification that determines membership in the extension. If a thing does not satisfy the intension of a concept, it ain't one. That's 100% correct, always (as far as I understand). It is extremely important to maintain the SBVR separation between meaning and expression of meaning. OK. So Ron is distinguishing between the "intension", which is the meaning, and the expression of the intension, which is the "definition" in some language. I think that's fundamental to SBVR, not 'Ron' in this case ... but this is something for others to verify. Then I will simply say that if the definition does not properly phrase the intension, the definition is incorrect. That is, what it says is not what was meant. Not true. If the definition is sufficiently general or abstract (but still sufficient for people to distinguish the concept from related concepts), then the Definition can still be correct as you add Necessities (which could be highly specific, arcane or detailed). This may not be the approach that everyone prefers to take (which is fine), but it *is* an approach that is highly workable in business, and one which SBVR can and must support. For example, a Necessity about tilt of orbit could come into play that was never there before. Does that *really* invalidate a *definition* (remember, definitions are *expressions*) that changes the essence of what a planet is (as represented by intension)? I think not. I strongly disagree. If the community adopts the new Necessity, the old definition in inaccurate, and will cause confusion in communications. The notion of "good customer" is still "good customer" even if you slightly adjust some obscure Necessity that has the effect of removing just 1 customer from a million in the extension. The *full* meaning is always given by the intension. Definitions are first and foremost *for people* and the original definition is probably still good enough for that purpose (the purpose of human communication). Probably still no confusion with "related" concepts. This is simply a matter of practicality. In short, meanings change. And Necessities are part of the meaning. When you add a Necessity, you have changed the meaning. It would be wise to change the Definition to match. Only if the definition now fails to distinguish the concept from related concepts (for people). If you change your definitions every day or every minute (and some rules *do* change that fast), you are going to have a lot of confused people running around. In other words, good practice is a matter of finding the optimal balance. (Also, if you added a Necessity *and* changed the definition, haven't you introduced redundancy?) Any other would-be "Necessity" is really a "structural rule" -- a business rule for the (static) behaviors and relationships of instances of that concept in the reference business environment. Unlike a true "Necessity", a structural rule can in fact be violated. No. A structural rule *cannot* be violated. I did not understand this. To me, it means that a "structural rule" is in effect part of the definition of (one or more of) the terms involved. Part of the intension, but not necessarily part of the definition, as per the above. Further, I think that Terry and the database logic folks would have to disagree with this. Some structural rules are effectively impossible to violate because the information recording technology enforces the rule. But many "structural rules" ("integrity constraints") are enforced on database models "externally" to capture and quarantine inconsistencies in information. In practice, such rules are violated in transactions all the time, and the nature of the enforcement policy is to prevent such violations from corrupting the active information base. (This is what the RIF WG calls "normative rules".) Well, information system design and technology of any kind, including database technology and integrity constraints, are most definitely *out of scope* in the meaning and expression of all SBVR concepts and terms. I am reminded of a certain FreddieMac (FHLMC) officer who told me it was not possible that the interest rate on a loan would be greater than 15%. So I offered an enforcement policy that deletes all loans from that region if such a rate is encountered -- it is not a loan, and therefore what the region sent is not a set of loans. "Well, I suppose if the data were entered incorrectly, and the regional office didn't check it properly, ..." We settled for creating an exception file. And in the first 6 months of operation, we had 1200 loans in the exception file at one time or another. Structural rules ARE violated. They might be 'violated' in information systems, depending on the design, but as you yourself pointed out, they *cannot* be violated in business-level expression of knowledge - otherwise your (logical) knowledge base will result in internal inconsistencies. It can be misapplied, misunderstood or ill-conceived, but it *cannot* be violated. Only *humans* can violate business rules, which immediately makes them (the rules) operative. First of all, that is not true. Machines can violate business rules, when they are entrusted with their execution, sometimes by erroneous design, sometimes by physical failure, sometimes by circumstances beyond their control. ("I don't know why that machine won't accept your card; this machine does.") The design of the machine is outside SBVR scope. In the world of knowledge and guidance, necessities *can't* be violated (or your knowledge base will have internal inconsistencies), and you must recognize that people *can* violate rules of behavior (or you're closing your eyes to the reality of human behavior). All of SBVR thinking about rules comes from those basic assumptions (in my view). Second, the purpose of many "normative" ("structural") rules is to identify from the artifacts that some operative business rule has been violated, misapplied, or misunderstood. In the FHLMC example, we got garbage because the regional software didn't check the data it sent us, even though the agreed-upon business rules said they would perform those tests. And their structural rule checking was designed to detect that the human who keyboarded the data from the paper forms put the values in the wrong columns. The 'paper' and keyboarding issues, while extremely important obviously, are knowledge/record-keeping issues outside SBVR scope. SBVR just tries to get the fundamental concepts 'right'. So there is indeed some operative rule that is being violated, but the structural rule is not itself operative. It is very important to distinguish *necessities* (which help form intensions, and can't be violated) from obligations (which *people* can violate). And that's exactly the difference between Structural (Definitional) Rules and Operative (Behavioral) Rules, and a central notion of SBVR. This is part of the confusion that has been generated. I certainly understood the distinction, but I didn't realize that "Structural Rule" meant "Definitional Rule". It has been proposed and resolved (and maybe voted on) that these two terms are synonyms. From my perspective, that was always intended. I don't object to the terminology, but I think the (important) concept of static "normative" rule is thereby excluded from SBVR. If it refers to knowledge/record-keeping system, including database constraints, then yes, I suppose. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Thu, 01 Jun 2006 15:55:13 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Ronald G. Ross" CC: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No I wrote: Then I will simply say that if the definition does not properly phrase the intension, the definition is incorrect. That is, what it says is not what was meant. Ron wrote: Not true. If the definition is sufficiently general or abstract (but still sufficient for people to distinguish the concept from related concepts), then the Definition can still be correct as you add Necessities (which could be highly specific, arcane or detailed). This may not be the approach that everyone prefers to take (which is fine), but it *is* an approach that is highly workable in business, and one which SBVR can and must support. I see. My mathematics and engineering background tells me that the "definition" is the specification of the intension. Apparently in "business semantics", it is possible to distinguish a concept from all related concepts without specifying its entire intension. ... (Also, if you added a Necessity *and* changed the definition, haven't you introduced redundancy?) Ah. Perhaps this is the real difference: we needed to define "definition". I assumed that the Definition is the set of specifications needed to determine the intension. That is, the Definition tells me what I need to know to make admissibility decisions. Ron apparently sees the Definition plus the Necessities as the set of specifications needed to determine the intension. So in Ron's semantics, knowing the "Definition" gives you the gist of the classification, but may be insufficient to actually make any decisions. So an EJB "Definition" is an RGR "Definition + Necessities". No problem. This, of course, takes us back to 9613: Which of these is the SBVR "Definition"? Any other would-be "Necessity" is really a "structural rule" -- a business rule for the (static) behaviors and relationships of instances of that concept in the reference business environment. Unlike a true "Necessity", a structural rule can in fact be violated. No. A structural rule *cannot* be violated. I did not understand this. To me, it means that a "structural rule" is in effect part of the definition of (one or more of) the terms involved. Part of the intension, but not necessarily part of the definition, as per the above. With the RGR definitions, yes. Further, I think that Terry and the database logic folks would have to disagree with this. Some structural rules are effectively impossible to violate because the information recording technology enforces the rule. But many "structural rules" ("integrity constraints") are enforced on database models "externally" to capture and quarantine inconsistencies in information. In practice, such rules are violated in transactions all the time, and the nature of the enforcement policy is to prevent such violations from corrupting the active information base. (This is what the RIF WG calls "normative rules".) Well, information system design and technology of any kind, including database technology and integrity constraints, are most definitely *out of scope* in the meaning and expression of all SBVR concepts and terms. Not to put too fine a point on it, if I accepted that, I wouldn't be on this FTF. Most rules written into programs and databases aren't there because some IT person had to put them there to get the computer to get the answer right. They are there because some "business person" expressed to that IT person a "business rule" that is enforced by that IT rule, so that "business persons" don't have to perform that check or put that form in a different pile. I am reminded of a certain FreddieMac (FHLMC) officer who told me it was not possible that the interest rate on a loan would be greater than 15%. So I offered an enforcement policy that deletes all loans from that region if such a rate is encountered -- it is not a loan, and therefore what the region sent is not a set of loans. "Well, I suppose if the data were entered incorrectly, and the regional office didn't check it properly, ..." We settled for creating an exception file. And in the first 6 months of operation, we had 1200 loans in the exception file at one time or another. Structural rules ARE violated. They might be 'violated' in information systems, depending on the design, but as you yourself pointed out, they *cannot* be violated in business-level expression of knowledge - otherwise your (logical) knowledge base will result in internal inconsistencies. I'm not sure what a "business-level expression of knowledge" IS. But the last time I looked, a "loan record", as kept on paper in file cabinet, and as kept in bits in a database, are "business-level expressions of knowledge", because there is *no other* expression of that knowledge! And the information on that paper or in that database can be incorrect, and thereby violate a "structural rule". Further, the information on that paper can be such as to indicate that it is in the wrong file, or that it has an entry in the wrong database table. The management of that information was done wrong, and so a structural rule has been violated. That does not make that paper or database entry "not a loan record", because it is the only such record! It makes it an INVALID or MISPLACED loan record. Loan information written on the back of an old envelope is not a loan record. Loan information on a form that has been approved, signed, copied and filed is a loan record, even if one of the information units on that form violates a "structural rule", or the form is placed in the wrong service folder. Now the "real" business object is a 'loan', but it has no substance. The 'loan record' -- the expression of that object -- is the only substance it has. Many business objects have no substance: job, project, order, contract, etc. They are entirely putative artifacts that can only be examined by recourse to the recorded information. The record is the only source of information. Without a loan record, there is no loan. I think we need to distinguish between rules that are impossible to violate, and rules whose violation make some business process invalid. And in business, we have a long-standing term for the latter kind of violation: "exception". A recurrent theme: Only *humans* can violate business rules, which immediately makes them (the rules) operative. First of all, that is not true. Machines can violate business rules, when they are entrusted with their execution, sometimes by erroneous design, sometimes by physical failure, sometimes by circumstances beyond their control. The design of the machine is outside SBVR scope. Agreed. The design of the machine, and the design of humans (), are outside the scope of SBVR. But both are agents who execute business rules, and both are capable of violating them. In the world of knowledge and guidance, necessities *can't* be violated (or your knowledge base will have internal inconsistencies), and you must recognize that people *can* violate rules of behavior (or you're closing your eyes to the reality of human behavior). All of SBVR thinking about rules comes from those basic assumptions (in my view). If a Necessity distinguishes possibility from impossibility, or is-a from is-not-a, it cannot be violated. But any rule that distinguishes permissible states from possible states can be violated. So if Necessities cannot be violated, then they cannot distinguish permissible states from possible states. And if "structural rules" are "Necessities", they cannot distinguish permissible states from possible states; they can only distinguish possible states from impossible states and is-an-X from is-not-an-X. "A rental can have at most 2 drivers." must be an operative rule: it forbids the customer to put the third driver behind the wheel, and it can obviously be violated. But it is certainly not the case that when the third driver sits behind the wheel, it ceases to be a rental. It remains a rental; it becomes an exception -- a contract violation. "A rental can have at most 2 recorded drivers." is a structural rule. If the rental record has only 2 slots, it is not possible to record a third driver. Second, the purpose of many "normative" ("structural") rules is to identify from the artifacts that some operative business rule has been violated, misapplied, or misunderstood. In the FHLMC example, we got garbage because the regional software didn't check the data it sent us, even though the agreed-upon business rules said they would perform those tests. And their structural rule checking was designed to detect that the human who keyboarded the data from the paper forms put the values in the wrong columns. The 'paper' and keyboarding issues, while extremely important obviously, are knowledge/record-keeping issues outside SBVR scope. SBVR just tries to get the fundamental concepts 'right'. So do logicians, and they do it a helluva lot better. This is part of the confusion that has been generated. I certainly understood the distinction, but I didn't realize that "Structural Rule" meant "Definitional Rule". It has been proposed and resolved (and maybe voted on) that these two terms are synonyms. From my perspective, that was always intended. I don't object to the terminology, but I think the (important) concept of static "normative" rule is thereby excluded from SBVR. If it refers to knowledge/record-keeping system, including database constraints, then yes, I suppose. If SBVR is to be useful to "business people", it has to deal with the fact that these extremely important issues of record-keeping are the object of many business rules. The entire world of finance is based solely on record-keeping -- it has no substance. Identity theft succeeds by violating structural rules. I can accept the fact that SBVR doesn't want to deal with exceptions -- violations of structural rules that define permissible states -- but I cannot accept its defining them out of existence. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: RE: issue 9613 -- SBVR FTF issue Date: Thu, 1 Jun 2006 15:10:25 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9613 -- SBVR FTF issue Thread-Index: AcaFtcsyA9/4hcaJQjeYHLV6AQXpeQADlCdQ From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 01 Jun 2006 22:10:26.0335 (UTC) FILETIME=[2F7D92F0:01C685C8] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k51LwI68012643 Ed's and Ron's approaches are both supported. But structural rules should not be used to necessitate facts of arbitrary preferences that change from time to time. Consider the versions of bodies of meaning shown below. Start with two definitions in version 1: big thing Definition: thing with a large mass large mass Definition: mass greater than 1 kg Now I change the definition stated for the signifier 'large mass' to "mass greater than 1.1 kg" so that I have the following in version 2: big thing Definition: thing with a large mass large mass Definition: mass greater than 1.1 kg The two concepts in version 1 are both different from the two concepts in version two that have the same signifiers. The definitions are also different, even where the same expression is used. "thing with a large mass" has a different meaning between the two versions and is therefore a different definition -- it represents something different, so it is a different representation. Now consider version 3: big thing Definition: thing with a mass considered to be large by Ron Fact: Ron considers a mass greater than 1 kg to be large And version 4: big thing Definition: thing with a mass considered to be large by Ron Fact: Ron considers a mass greater than 1.1 kg to be large The meaning of 'big thing' is the same in versions 3 and 4 and the definitions are the same. They have exactly the same meaning. The extensions differ, but that is because the world has changed, not the meaning. Ron prefers something different in version 4. Use a structural rule where something is necessarily true in all possible worlds, not for stating values of parameters changed at the whim of business managers. Current preferences should be given as facts or can be given in operative rules (e.g. using "must be considered ..."), but should not be stated as "always" true. Now consider version 5: big thing Definition: thing with a mass considered to be large Rule: A mass must be considered to be large if it is greater than 1 kg And version 6: big thing Definition: thing with a mass considered to be large Rule: A mass must be considered to be large if it is greater than 1.1 kg Again, the meaning of 'big thing' remains the same in versions 5 and 6, but the company might act a little differently where decisions about what is big are concerned. Enjoy, Don -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Thursday, June 01, 2006 12:55 PM To: Ronald G. Ross Cc: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue I wrote: >> Then I will simply say that if the definition does not properly >> phrase the intension, the definition is incorrect. That is, what it >> says is not what was meant. Ron wrote: > Not true. If the definition is sufficiently general or abstract (but > still sufficient for people to distinguish the concept from related > concepts), then the Definition can still be correct as you add > Necessities (which could be highly specific, arcane or detailed). > > This may not be the approach that everyone prefers to take (which is > fine), but it *is* an approach that is highly workable in business, and > one which SBVR can and must support. I see. My mathematics and engineering background tells me that the "definition" is the specification of the intension. Apparently in "business semantics", it is possible to distinguish a concept from all related concepts without specifying its entire intension. > ... > (Also, if you added a Necessity *and* changed the definition, haven't > you introduced redundancy?) Ah. Perhaps this is the real difference: we needed to define "definition". I assumed that the Definition is the set of specifications needed to determine the intension. That is, the Definition tells me what I need to know to make admissibility decisions. Ron apparently sees the Definition plus the Necessities as the set of specifications needed to determine the intension. So in Ron's semantics, knowing the "Definition" gives you the gist of the classification, but may be insufficient to actually make any decisions. So an EJB "Definition" is an RGR "Definition + Necessities". No problem. This, of course, takes us back to 9613: Which of these is the SBVR "Definition"? >>>> Any other would-be "Necessity" is really a "structural rule" -- a >>>> business rule for the (static) behaviors and relationships of >>>> instances of that concept in the reference business environment. >>>> Unlike a true "Necessity", a structural rule can in fact be violated. >>> >>> No. A structural rule *cannot* be violated. >> >> I did not understand this. To me, it means that a "structural rule" >> is in effect part of the definition of (one or more of) the terms >> involved. > > Part of the intension, but not necessarily part of the definition, as > per the above. With the RGR definitions, yes. >> Further, I think that Terry and the database logic folks would have to >> disagree with this. Some structural rules are effectively impossible >> to violate because the information recording technology enforces the >> rule. But many "structural rules" ("integrity constraints") are >> enforced on database models "externally" to capture and quarantine >> inconsistencies in information. In practice, such rules are violated >> in transactions all the time, and the nature of the enforcement policy >> is to prevent such violations from corrupting the active information >> base. (This is what the RIF WG calls "normative rules".) > > Well, information system design and technology of any kind, including > database technology and integrity constraints, are most definitely *out > of scope* in the meaning and expression of all SBVR concepts and terms. Not to put too fine a point on it, if I accepted that, I wouldn't be on this FTF. Most rules written into programs and databases aren't there because some IT person had to put them there to get the computer to get the answer right. They are there because some "business person" expressed to that IT person a "business rule" that is enforced by that IT rule, so that "business persons" don't have to perform that check or put that form in a different pile. >> I am reminded of a certain FreddieMac (FHLMC) officer who told me it >> was not possible that the interest rate on a loan would be greater >> than 15%. So I offered an enforcement policy that deletes all loans >> from that region if such a rate is encountered -- it is not a loan, >> and therefore what the region sent is not a set of loans. "Well, I >> suppose if the data were entered incorrectly, and the regional office >> didn't check it properly, ..." We settled for creating an exception >> file. And in the first 6 months of operation, we had 1200 loans in >> the exception file at one time or another. Structural rules ARE >> violated. > > They might be 'violated' in information systems, depending on the > design, but as you yourself pointed out, they *cannot* be violated in > business-level expression of knowledge - otherwise your (logical) > knowledge base will result in internal inconsistencies. I'm not sure what a "business-level expression of knowledge" IS. But the last time I looked, a "loan record", as kept on paper in file cabinet, and as kept in bits in a database, are "business-level expressions of knowledge", because there is *no other* expression of that knowledge! And the information on that paper or in that database can be incorrect, and thereby violate a "structural rule". Further, the information on that paper can be such as to indicate that it is in the wrong file, or that it has an entry in the wrong database table. The management of that information was done wrong, and so a structural rule has been violated. That does not make that paper or database entry "not a loan record", because it is the only such record! It makes it an INVALID or MISPLACED loan record. Loan information written on the back of an old envelope is not a loan record. Loan information on a form that has been approved, signed, copied and filed is a loan record, even if one of the information units on that form violates a "structural rule", or the form is placed in the wrong service folder. Now the "real" business object is a 'loan', but it has no substance. The 'loan record' -- the expression of that object -- is the only substance it has. Many business objects have no substance: job, project, order, contract, etc. They are entirely putative artifacts that can only be examined by recourse to the recorded information. The record is the only source of information. Without a loan record, there is no loan. I think we need to distinguish between rules that are impossible to violate, and rules whose violation make some business process invalid. And in business, we have a long-standing term for the latter kind of violation: "exception". A recurrent theme: >>> Only *humans* can violate business rules, which >>> immediately makes them (the rules) operative. >> >> First of all, that is not true. Machines can violate business rules, >> when they are entrusted with their execution, sometimes by erroneous >> design, sometimes by physical failure, sometimes by circumstances >> beyond their control. > > The design of the machine is outside SBVR scope. Agreed. The design of the machine, and the design of humans (), are outside the scope of SBVR. But both are agents who execute business rules, and both are capable of violating them. > In the world of > knowledge and guidance, necessities *can't* be violated (or your > knowledge base will have internal inconsistencies), and you must > recognize that people *can* violate rules of behavior (or you're closing > your eyes to the reality of human behavior). All of SBVR thinking about > rules comes from those basic assumptions (in my view). If a Necessity distinguishes possibility from impossibility, or is-a from is-not-a, it cannot be violated. But any rule that distinguishes permissible states from possible states can be violated. So if Necessities cannot be violated, then they cannot distinguish permissible states from possible states. And if "structural rules" are "Necessities", they cannot distinguish permissible states from possible states; they can only distinguish possible states from impossible states and is-an-X from is-not-an-X. "A rental can have at most 2 drivers." must be an operative rule: it forbids the customer to put the third driver behind the wheel, and it can obviously be violated. But it is certainly not the case that when the third driver sits behind the wheel, it ceases to be a rental. It remains a rental; it becomes an exception -- a contract violation. "A rental can have at most 2 recorded drivers." is a structural rule. If the rental record has only 2 slots, it is not possible to record a third driver. >> Second, the purpose of many "normative" ("structural") rules is to >> identify from the artifacts that some operative business rule has been >> violated, misapplied, or misunderstood. In the FHLMC example, we got >> garbage because the regional software didn't check the data it sent >> us, even though the agreed-upon business rules said they would perform >> those tests. And their structural rule checking was designed to >> detect that the human who keyboarded the data from the paper forms put >> the values in the wrong columns. > > The 'paper' and keyboarding issues, while extremely important obviously, > are knowledge/record-keeping issues outside SBVR scope. SBVR just tries > to get the fundamental concepts 'right'. So do logicians, and they do it a helluva lot better. >> This is part of the confusion that has been generated. I certainly >> understood the distinction, but I didn't realize that "Structural >> Rule" meant "Definitional Rule". > > It has been proposed and resolved (and maybe voted on) that these two > terms are synonyms. From my perspective, that was always intended. > >> I don't object to the terminology, but I think the (important) >> concept of static "normative" rule is thereby excluded from SBVR. > > If it refers to knowledge/record-keeping system, including database > constraints, then yes, I suppose. If SBVR is to be useful to "business people", it has to deal with the fact that these extremely important issues of record-keeping are the object of many business rules. The entire world of finance is based solely on record-keeping -- it has no substance. Identity theft succeeds by violating structural rules. I can accept the fact that SBVR doesn't want to deal with exceptions -- violations of structural rules that define permissible states -- but I cannot accept its defining them out of existence. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Jun 2006 20:00:37 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 02:55 PM 6/1/2006, Ed Barkmeyer wrote: If a Necessity distinguishes possibility from impossibility, or is-a from is-not-a, it cannot be violated. But any rule that distinguishes permissible states from possible states can be violated. So if Necessities cannot be violated, then they cannot distinguish permissible states from possible states. And if "structural rules" are "Necessities", they cannot distinguish permissible states from possible states; they can only distinguish possible states from impossible states and is-an-X from is-not-an-X. "A rental can have at most 2 drivers." must be an operative rule: it forbids the customer to put the third driver behind the wheel, and it can obviously be violated. But it is certainly not the case that when the third driver sits behind the wheel, it ceases to be a rental. It remains a rental; it becomes an exception -- a contract violation. Correct on all points. That's an operative (behavioral) business rule, not a structural (definitional) business rule. The car rental would not cease being a car rental if it had 3 known drivers, no matter what the system and/or paper forms allowed or did not allow. However, if the car rental had *no* rental customer, then I think we could agree that whatever we had sure isn't a car rental. That would be proper use of a structural (definitional) business rule. You use those only when if not satisfied the thing isn't in the intension of something. "A rental can have at most 2 recorded drivers." is a structural rule. If the rental record has only 2 slots, it is not possible to record a third driver. This is not what SBVR would call a business rule. So it's not a structural business rule either. "Structure" by the way has to do with the structure of knowledge (forming of intensions, really), *not* the structure of any recording device. Big difference! I'm not saying there can't be recording-device rules ...obviously there can and are (gazillions!) ... but SBVR simply doesn't address them. If SBVR is to be useful to "business people", it has to deal with the fact that these extremely important issues of record-keeping are the object of many business rules. The entire world of finance is based solely on record-keeping -- it has no substance. First accounting is based on people-to-people communication -- concepts and terms -- a vocabulary and set of rules. There are textbooks and courses on those things. *Then* accounting requires record-keeping (whether by computer, pencil-and-paper and/or abacus ... whatever). SBVR focuses on the first thing, because if you can't get a grip on that, you will never do the record-keeping part right. (By the way, getting the former right doesn't mean you will get the latter right -- it just means you have a fighting chance.) In a way, this business about people-to-people communication is so obvious that we tend to trip (or skip) right over it. Take it for granted. But in my experience, it's the root cause of many if not most IT "requirements" problems. Identity theft succeeds by violating structural rules. There are operative (behavioral) rules and structural (definitional) rules. These establish the vocabulary (full intensions) to be able to 'talk' about the problem in the first place, and what the business norms of behavior are to be. Then there are record-keeping rules (outside SBVR). Where this kind of problem becomes fuzzy for those of us in IT is that some of the business concepts in this problem space *can* involve IT platforms. But that does not change the order of things. First you need a vocabulary to talk (precisely) about the problem, and norms of behavior. *Then* you need a knowledge/record-keeping system to support your anti-identity-theft solution design. Aside: It's a red herring that business vocabularies can never include technical terms. Of course they can if that's the business problem. The confusion always arises when the business creates a solution for a business problem, and that solution involves automation, and decisions are made about the automated solution that take the form of *rules*. Well, those aren't *business* rules. Example: An overdue account must flash in red on the screen. Not a business rule. A customer record may include only one phone number. Not a business rule. The system may record only two driver names in the record of a car rental. Not a business rule (stated that way). I can accept the fact that SBVR doesn't want to deal with exceptions -- violations of structural rules that define permissible states -- but I cannot accept its defining them out of existence. I can give you a definition and (some but probably not all) Necessities for the concept of "invalid tax return". An invalid tax return is still a tax return. But it is presumably not acceptable for further business processing. Here we would have a state of affairs (I may not be using that SBVR term precisely) that has been given a name, and could be given a definition and intension. I believe that would be fully adequate for dealing with the type of 'exceptions' you are talking about. So you'll have to try me again on that one. In fact, I believe one of the most innovative parts of SBVR is to deal appropriately with both the "exceptions" produced by operative (behavioral) rules (in one way), and the "exceptions" (specially named intensions) related to structural (definitional) rules in another. Try me again!? I wish a had more time to talk about "states", exceptions, etc. ... maybe John Hall will jump in here. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Jun 2006 19:20:51 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 02:55 PM 6/1/2006, Ed Barkmeyer wrote: Ed wrote: Unlike a true "Necessity", a structural rule can in fact be violated. Ron wrote: No. A structural rule *cannot* be violated. To repeat, a structural (aka definitional) rule *is* a true necessity. Further, I think that Terry and the database logic folks would have to disagree with this. Some structural rules are effectively impossible to violate because the information recording technology enforces the rule. But many "structural rules" ("integrity constraints") are enforced on database models "externally" to capture and quarantine inconsistencies in information. 'Integrity constraints' represent a jumble of: * Operative (Behavioral) Business Rules: A barred driver must not have possession of a rental car. (Can be violated in real life for a variety of reasons.) * Structural (Definitional) Business Rules: A car rental always has a rental customer. (Something simply isn't a car rental without a rental customer.) * System Rules: A customer record may include at most one phone number. (There's generally no such rule in real life or business, so someone has made a (database) design decision in the form of a rule.) In practice, such rules are violated in transactions all the time, and the nature of the enforcement policy is to prevent such violations from corrupting the active information base. (This is what the RIF WG calls "normative rules".) In a business rule environment, the idea is to be present at the birthpoint of knowledge. If you are in an environment where you cannot be at the birthpoint of knowledge, then all (or most) bets or off. I mean no criticism here of the RIF WG because I have no personal contact to date with them, and of course, the problem space is a hugely important one. However, in my somewhat extensive experience with internal business problems, trying to create after-the-fact rules to address already-lost consistency is nightmarish and incredibly expensive (not necessarily a negative for many consultants and outsourcers, of course). I can't begin to describe the mess some companies we see are in. Again, I am talking about internal business operations where there is some measure of control and opportunity (fundamental business requirement, actually) to coordinate a a targeted value chain. That does not characterize other environments -- say the semantic web, in my limited understanding. Well, information system design and technology of any kind, including database technology and integrity constraints, are most definitely *out of scope* in the meaning and expression of all SBVR concepts and terms. Not to put too fine a point on it, if I accepted that, I wouldn't be on this FTF. Most rules written into programs and databases aren't there because some IT person had to put them there to get the computer to get the answer right. They are there because some "business person" expressed to that IT person a "business rule" that is enforced by that IT rule, so that "business persons" don't have to perform that check or put that form in a different pile. I don't think we're speaking a different language on that one. Ron X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Jun 2006 18:47:59 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 02:55 PM 6/1/2006, Ed Barkmeyer wrote: Ed wrote: Ah. Perhaps this is the real difference: we needed to define "definition". I assumed that the Definition is the set of specifications needed to determine the intension. That is, the Definition tells me what I need to know to make admissibility decisions. Ron apparently sees the Definition plus the Necessities as the set of specifications needed to determine the intension. So in Ron's semantics, knowing the "Definition" gives you the gist of the classification, but may be insufficient to actually make any decisions. So an EJB "Definition" is an RGR "Definition + Necessities". No problem. This, of course, takes us back to 9613: Which of these is the SBVR "Definition"? In SBVR Structured English (SE), it is clear that a Definition does not include separate Necessities. The captions are clear in that respect. And SBVR SE was developed to illustrate and specify SBVR semantics themselves. No, in my view SBVR's Definition never has included, and was never intended to include, separate Necessities. Can you help clarify what needs to be done in SBVR to correct whatever is causing the confusion (over Definition, Necessity and intension)?? (Or maybe that is the point of the Issue.) Ron X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 01 Jun 2006 18:40:52 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 02:55 PM 6/1/2006, Ed Barkmeyer wrote: I wrote: Then I will simply say that if the definition does not properly phrase the intension, the definition is incorrect. That is, what it says is not what was meant. Ron wrote: Not true. If the definition is sufficiently general or abstract (but still sufficient for people to distinguish the concept from related concepts), then the Definition can still be correct as you add Necessities (which could be highly specific, arcane or detailed). This may not be the approach that everyone prefers to take (which is fine), but it *is* an approach that is highly workable in business, and one which SBVR can and must support. I see. My mathematics and engineering background tells me that the "definition" is the specification of the intension. Apparently in "business semantics", it is possible to distinguish a concept from all related concepts without specifying its entire intension. Interesting way to put it. Yes, I believe that is so. Aside: This is *exactly* the problem (or maybe I should say simply 'reality') of SBVR's own vocabulary. It is largely a mathematical and engineering vocabulary meant to establish the (logical) basis for *business* vocabularies. (There is probably no avoiding that, so this is an observation rather than a criticism.) But we must remember that business vocabularies are unlike mathematical and engineering vocabularies in certain crucial respects. (Please work through the following example to illustrate, at least in part.) Let's take an example involving 'intension, necessity and definition' for the business concept 'good customer'. (I happen to be on the plane right now, so you can guess where the example comes from.) Suppose I give the following Necessity: Necessity: At least one of the following always is true for a good customer: * has flown at least 50,000 miles on paid tickets during the last calendar year. * has flown at least 50 flight segments on paid tickets during the last calendar year. * has flown at least 40,000 miles AND 25 flight segments on paid tickets during the last calendar year. * has flown at least 25,000 miles AND 40 flight segments on paid tickets during the last calendar year. * has flown at least 150,000 miles OR 150 flight segments on paid or unpaid tickets during the last calendar year. * has flown at least 500,000 miles on paid tickets during the last 7 calendar years. * has flown at least 500 flight segments on paid tickets during the last 7 calendar years. * has flown on at least 10 highest-fare tickets during the last calendar year. * has flown on exactly the same route on the same days of the week at least 3 times a month in each of at least 7 months during the last calendar year. * has paid a total of more than $15,000 in paid tickets at least one month in advance during the last calendar year. * has flown with at least two family members on paid tickets 4 times during the last calendar year. I think you will agree I have given a fairly extensive specification of the concept's intension, at least for the sake of an this example(?). Now suppose this is your business and I am a new hire. Explain to me what a 'good customer' is. In other words give me a working definition that I can readily come to grips with, and remember, and count on to be the same tomorrow, and be reasonably productive with reasonably soon. Wouldn't it be better to (additionally) state(?): Definition [good customer]: a customer with which a continuing, lucrative business relationship is maintained Furthermore, for the sake of argument, let's say your business distinguishes between bad customers, run-of-the-mill customers, and good customers -- and that's pretty much it for your business vocabulary. Hasn't the *definition* (*not* including Necessity) given you (a) a general concept, and (b) delimiting characteristics sufficient to distinguish 'good customer' from 'related concepts'? Absolutely. Furthermore: (a) There is no redundancy whatsoever in my (full) specification of the intension (that is, between definition and Necessity). Such localization or isolation of logic is a central goal of the business rules approach (and hopefully other approaches as well). (b) We have attended to the needs of person-to-person communication (a central SBVR driver), as well as the needs of logically consistent knowledge bases (as you put it). I think the given combination of Definition and Necessity yields the optimal solution for *business* vocabularies (as opposed perhaps to mathematical and engineering vocabularies). Aside: I do not require by any means that everyone follow these practices under SBVR. However, they are proven and workable on a large scale in real business -- BRS has extensive project experience in this regard. So I feel strongly that SBVR must not exclude or deprecate these practices. Second Aside: As far as I understand, these practices are *already* supported by SBVR in its current version (which is obviously a good thing IMHO). Ron ... (Also, if you added a Necessity *and* changed the definition, haven't you introduced redundancy?) Ah. Perhaps this is the real difference: we needed to define "definition". I assumed that the Definition is the set of specifications needed to determine the intension. That is, the Definition tells me what I need to know to make admissibility decisions. Ron apparently sees the Definition plus the Necessities as the set of specifications needed to determine the intension. So in Ron's semantics, knowing the "Definition" gives you the gist of the classification, but may be insufficient to actually make any decisions. So an EJB "Definition" is an RGR "Definition + Necessities". No problem. This, of course, takes us back to 9613: Which of these is the SBVR "Definition"? Any other would-be "Necessity" is really a "structural rule" -- a business rule for the (static) behaviors and relationships of instances of that concept in the reference business environment. Unlike a true "Necessity", a structural rule can in fact be violated. No. A structural rule *cannot* be violated. I did not understand this. To me, it means that a "structural rule" is in effect part of the definition of (one or more of) the terms involved. Part of the intension, but not necessarily part of the definition, as per the above. With the RGR definitions, yes. Further, I think that Terry and the database logic folks would have to disagree with this. Some structural rules are effectively impossible to violate because the information recording technology enforces the rule. But many "structural rules" ("integrity constraints") are enforced on database models "externally" to capture and quarantine inconsistencies in information. In practice, such rules are violated in transactions all the time, and the nature of the enforcement policy is to prevent such violations from corrupting the active information base. (This is what the RIF WG calls "normative rules".) Well, information system design and technology of any kind, including database technology and integrity constraints, are most definitely *out of scope* in the meaning and expression of all SBVR concepts and terms. Not to put too fine a point on it, if I accepted that, I wouldn't be on this FTF. Most rules written into programs and databases aren't there because some IT person had to put them there to get the computer to get the answer right. They are there because some "business person" expressed to that IT person a "business rule" that is enforced by that IT rule, so that "business persons" don't have to perform that check or put that form in a different pile. I am reminded of a certain FreddieMac (FHLMC) officer who told me it was not possible that the interest rate on a loan would be greater than 15%. So I offered an enforcement policy that deletes all loans from that region if such a rate is encountered -- it is not a loan, and therefore what the region sent is not a set of loans. "Well, I suppose if the data were entered incorrectly, and the regional office didn't check it properly, ..." We settled for creating an exception file. And in the first 6 months of operation, we had 1200 loans in the exception file at one time or another. Structural rules ARE violated. They might be 'violated' in information systems, depending on the design, but as you yourself pointed out, they *cannot* be violated in business-level expression of knowledge - otherwise your (logical) knowledge base will result in internal inconsistencies. I'm not sure what a "business-level expression of knowledge" IS. But the last time I looked, a "loan record", as kept on paper in file cabinet, and as kept in bits in a database, are "business-level expressions of knowledge", because there is *no other* expression of that knowledge! And the information on that paper or in that database can be incorrect, and thereby violate a "structural rule". Further, the information on that paper can be such as to indicate that it is in the wrong file, or that it has an entry in the wrong database table. The management of that information was done wrong, and so a structural rule has been violated. That does not make that paper or database entry "not a loan record", because it is the only such record! It makes it an INVALID or MISPLACED loan record. Loan information written on the back of an old envelope is not a loan record. Loan information on a form that has been approved, signed, copied and filed is a loan record, even if one of the information units on that form violates a "structural rule", or the form is placed in the wrong service folder. Now the "real" business object is a 'loan', but it has no substance. The 'loan record' -- the expression of that object -- is the only substance it has. Many business objects have no substance: job, project, order, contract, etc. They are entirely putative artifacts that can only be examined by recourse to the recorded information. The record is the only source of information. Without a loan record, there is no loan. I think we need to distinguish between rules that are impossible to violate, and rules whose violation make some business process invalid. And in business, we have a long-standing term for the latter kind of violation: "exception". A recurrent theme: Only *humans* can violate business rules, which immediately makes them (the rules) operative. First of all, that is not true. Machines can violate business rules, when they are entrusted with their execution, sometimes by erroneous design, sometimes by physical failure, sometimes by circumstances beyond their control. The design of the machine is outside SBVR scope. Agreed. The design of the machine, and the design of humans (), are outside the scope of SBVR. But both are agents who execute business rules, and both are capable of violating them. In the world of knowledge and guidance, necessities *can't* be violated (or your knowledge base will have internal inconsistencies), and you must recognize that people *can* violate rules of behavior (or you're closing your eyes to the reality of human behavior). All of SBVR thinking about rules comes from those basic assumptions (in my view). If a Necessity distinguishes possibility from impossibility, or is-a from is-not-a, it cannot be violated. But any rule that distinguishes permissible states from possible states can be violated. So if Necessities cannot be violated, then they cannot distinguish permissible states from possible states. And if "structural rules" are "Necessities", they cannot distinguish permissible states from possible states; they can only distinguish possible states from impossible states and is-an-X from is-not-an-X. "A rental can have at most 2 drivers." must be an operative rule: it forbids the customer to put the third driver behind the wheel, and it can obviously be violated. But it is certainly not the case that when the third driver sits behind the wheel, it ceases to be a rental. It remains a rental; it becomes an exception -- a contract violation. "A rental can have at most 2 recorded drivers." is a structural rule. If the rental record has only 2 slots, it is not possible to record a third driver. Second, the purpose of many "normative" ("structural") rules is to identify from the artifacts that some operative business rule has been violated, misapplied, or misunderstood. In the FHLMC example, we got garbage because the regional software didn't check the data it sent us, even though the agreed-upon business rules said they would perform those tests. And their structural rule checking was designed to detect that the human who keyboarded the data from the paper forms put the values in the wrong columns. The 'paper' and keyboarding issues, while extremely important obviously, are knowledge/record-keeping issues outside SBVR scope. SBVR just tries to get the fundamental concepts 'right'. So do logicians, and they do it a helluva lot better. This is part of the confusion that has been generated. I certainly understood the distinction, but I didn't realize that "Structural Rule" meant "Definitional Rule". It has been proposed and resolved (and maybe voted on) that these two terms are synonyms. From my perspective, that was always intended. I don't object to the terminology, but I think the (important) concept of static "normative" rule is thereby excluded from SBVR. If it refers to knowledge/record-keeping system, including database constraints, then yes, I suppose. If SBVR is to be useful to "business people", it has to deal with the fact that these extremely important issues of record-keeping are the object of many business rules. The entire world of finance is based solely on record-keeping -- it has no substance. Identity theft succeeds by violating structural rules. I can accept the fact that SBVR doesn't want to deal with exceptions -- violations of structural rules that define permissible states -- but I cannot accept its defining them out of existence. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Fri, 02 Jun 2006 15:03:10 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Ronald G. Ross" CC: SBVR-FTF Subject: Re: issue 9613 -- SBVR FTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Ron, What I got out of the multiple treatises is that we are pretty much on the same page, but we have very different ways of expressing ourselves. All "Structural Rules" are "Necessities" and as such, are part of the (EJB notion of) "Definition". If a given individual violates a "Structural Rule" for X, the individual is not an X. So it is not possible for the proposition required by a Structural Rule to be FALSE. All business rules that can be violated, even though they appear to state requirements on static relationships, are "operative" rules. This is because those relationships are established by (uncontrollable) behaviors. These clarifications were important to me, because I misunderstood the meaning of "structural rule". So I'm out of this thread. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Fri, 02 Jun 2006 15:26:19 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Ronald G. Ross" CC: SBVR-FTF Subject: Accounting is a special case (from issue 9613) X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Ron, In the course of our recent exchanges, on a relatively irrelevant aside, you wrote: First accounting is based on people-to-people communication -- concepts and terms -- a vocabulary and set of rules. There are textbooks and courses on those things. With that justification, it would be possible to say that nuclear physics is based on people-to-people communication. And I simply reject that conclusion. Science is based on observing, studying and modeling natural phenomena, and then validating the models by experiment. People to people communication plays a critical supporting role in science, but not a basic role. *Then* accounting requires record-keeping (whether by computer, pencil-and-paper and/or abacus ... whatever). SBVR focuses on the first thing, because if you can't get a grip on that, you will never do the record-keeping part right. (By the way, getting the former right doesn't mean you will get the latter right -- it just means you have a fighting chance.) With respect to accounting, as a very special case, this is a complete mis-characterization. The discipline of accounting is about the formal organization, capture and reporting of financial knowledge. The notion "record-keeping" is *basic* to accounting. Accounting is about what records you keep and how you organize and aggregate them. The vocabulary of accounting is about financial notions and record-keeping notions. The purpose of accounting (and thus its name) is to have inspectable and understandable records to show how money flowed into and out of the enterprise and how value is retained in the enterprise. The principal notions in accounting are notions of "value", business actions that convert "value" from one form to another, and records of the values and of those actions from the viewpoint of their impact on value. The business rules relate not only to what value conversion behaviors are permitted, but also to what information must be captured and how. And the reason for the rules for "how" is to make the records "inspectable", so that they provide an "accounting" of the management of value in the business. I say that accounting is a very special case, because there are very few business activities in which record-keeping and information capture and management is so central and basic. But there are some, accounting is one, and you cannot divorce the "business concepts" from the record-keeping in this area. In a similar way, the financial industry of the 21st century is one in which there are few, if any, "states of affairs" that can be *observed*. Specie and visible labor are rare, and as a consequence, all of the states of interest exist only as "records". So almost all the business actions are about *fictitious* business concepts, or about the records that represent them, and those things are only sometimes distinguishable, because the concepts themselves only exist as information objects. In SBVR terms, the problem is that the expression is the only observable actuality. In a way, this business about people-to-people communication is so obvious that we tend to trip (or skip) right over it. Take it for granted. There is truth in this. OTOH, the purpose of many computational mechanisms is to implement people-to-people (and business agent to business agent) communication. The purpose of other computational mechanisms is to implement the business agency. And that is why I don't like talking about the distinction as "people" vs. "automata". The distinction that you make is better thought of as a distinction between the functional requirements (the "business rules") and the engineering artifacts (the "IT rules"). But many many "business rules" arise from the conversion of requirements and goals into "business processes", and the nature of the agents in that process affects the structure of that process, the nature of the communications, and the nature of the rules. So when the business agent is a (software-driven) machine, the nature of the rules matches. Is there a real difference between a requirement for the customer to present a valid credit card and a requirement for the customer to enter a valid userid and password? I agree that record-keeping is primarily an "engineering artifact", whether it is done with databases or file cabinets full of forms. BUT many business processes are rendered manageable (and recoverable) by incorporating record-keeping and reporting activities -- people-to-people communications. And because those communications are critical to controlled operation of the enterprise, the business rules often address those activities and their artifacts. So it is really hard to draw a line in this sand. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 02 Jun 2006 16:41:41 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: issue 9613 -- SBVR FTF issue Cc: SBVR-FTF At 04:26 PM 6/2/2006, Ronald G. Ross wrote: At 02:03 PM 6/2/2006, Ed Barkmeyer wrote: Ron, What I got out of the multiple treatises is that we are pretty much on the same page, but we have very different ways of expressing ourselves. Good. (And thank goodness it's not the opposite problem.) All "Structural Rules" are "Necessities" and as such, are part of the (EJB notion of) "Definition". If a given individual violates a "Structural Rule" for X, the individual is not an X. So it is not possible for the proposition required by a Structural Rule to be FALSE. I'll leave that last part to those better versed in formal logics, but I believe all of what you say is correct. All business rules that can be violated, even though they appear to state requirements on static relationships, are "operative" rules. Yes, I think that's correct. This is because those relationships are established by (uncontrollable) behaviors. I would say simply 'people can violate (operative) rules'. These clarifications were important to me, because I misunderstood the meaning of "structural rule". So I'm out of this thread. Thanks for taking the time. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 02 Jun 2006 17:32:32 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: Accounting is a special case (from issue 9613) Cc: SBVR-FTF At 02:26 PM 6/2/2006, Ed Barkmeyer wrote: Ron, Ed, I'll try to keep my comments brief. You make some good points. Ron wrote: *Then* accounting requires record-keeping (whether by computer, pencil-and-paper and/or abacus ... whatever). SBVR focuses on the first thing, because if you can't get a grip on that, you will never do the record-keeping part right. (By the way, getting the former right doesn't mean you will get the latter right -- it just means you have a fighting chance.) With respect to accounting, as a very special case, this is a complete mis-characterization. The discipline of accounting is about the formal organization, capture and reporting of financial knowledge. The notion "record-keeping" is *basic* to accounting. Accounting is about what records you keep and how you organize and aggregate them. The vocabulary of accounting is about financial notions and record-keeping notions. Yes, of course. Poor choice of words on my part. By "record-keeping" I meant *design of the recording-keeping platforming* ... " ... whether by computer, pencil-and-paper and/or abacus ... whatever". In many or most areas of business, the term "record keeping" wouldn't collide between actual subject matter and *knowledge/record-keeping platform design" as it does for accounting. The purpose of accounting (and thus its name) is to have inspectable and understandable records to show how money flowed into and out of the enterprise and how value is retained in the enterprise. The principal notions in accounting are notions of "value", business actions that convert "value" from one form to another, and records of the values and of those actions from the viewpoint of their impact on value. The business rules relate not only to what value conversion behaviors are permitted, but also to what information must be captured and how. And the reason for the rules for "how" is to make the records "inspectable", so that they provide an "accounting" of the management of value in the business. I say that accounting is a very special case, because there are very few business activities in which record-keeping and information capture and management is so central and basic. But there are some, accounting is one, and you cannot divorce the "business concepts" from the record-keeping in this area. I agree, given the business meaning of "recording keeping" as opposed to some platform-oriented meaning. In a way, this business about people-to-people communication is so obvious that we tend to trip (or skip) right over it. Take it for granted. There is truth in this. OTOH, the purpose of many computational mechanisms is to implement people-to-people (and business agent to business agent) communication. The purpose of other computational mechanisms is to implement the business agency. And that is why I don't like talking about the distinction as "people" vs. "automata". The distinction that you make is better thought of as a distinction between the functional requirements (the "business rules") and the engineering artifacts (the "IT rules"). But many many "business rules" arise from the conversion of requirements and goals into "business processes", and the nature of the agents in that process affects the structure of that process, the nature of the communications, and the nature of the rules. So when the business agent is a (software-driven) machine, the nature of the rules matches. Is there a real difference between a requirement for the customer to present a valid credit card and a requirement for the customer to enter a valid userid and password? I agree that record-keeping is primarily an "engineering artifact", whether it is done with databases or file cabinets full of forms. BUT many business processes are rendered manageable (and recoverable) by incorporating record-keeping and reporting activities -- people-to-people communications. And because those communications are critical to controlled operation of the enterprise, the business rules often address those activities and their artifacts. So it is really hard to draw a line in this sand. Yes, accounting seems to be a case where the vocabulary I normally use (e.g., "record-keeping") to make fundamental distinctions between *business vocabulary* and *system design vocabulary* tends to cause problems. In the large majority of cases, however, I find it holds up pretty well. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, Reply-To: From: "Donald Chapin" To: Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles Document and Diagram for Definitions & Rules Date: Mon, 7 Aug 2006 21:05:56 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQ Team -- I have updated the "SBVR Architectural Principles for Definitions & Rules" document and the "Concepts about Characteristics" diagram to bring them in line with the input from Ed Barkmeyer and the ISO Terminology community and with our discussion last Wednesday. Tomorrow I plan to finish the Issue 9613 Issue Resolution document containing the editing instructions for discussion on Wednesday. Donald > -----Original Message----- > From: Ed Barkmeyer [mailto:edbark@nist.gov] > Sent: 23 June 2006 19:54 > To: Donald.Chapin@btinternet.com > Cc: sbvr-ftf@omg.org > Subject: Re: issue 9613 -- SBVR FTF issue - Questions about Necessary & > Sufficient > > Donald, > > I think I made a serious error in describing "necessary" and "sufficient" > in > the telecon(s). > > In mathematics (and in Description Logics), there are two important > relationships between classifications of things (concepts) and conditions > on > things (characteristics). The distinction is in whether > - the condition implies membership in the category ("sufficient"), or > - membership in the category implies the condition ("necessary"). > > The sentence: > IF x is a Person and x is female THEN x is a Woman. > conveys a set of two "sufficient" characteristics for the concept Woman. > Any Thing x with these two properties is guaranteed to be in the extension > of > Woman. > > The sentence: > IF x is a Woman THEN x is female and x is a Person. > conveys two "necessary" characteristics for the concept Woman. > Any Thing x in the extension of Woman is guaranteed to have these two > properties. > > The sentence: > x is a Woman IS DEFINED AS x is a Person and x is female > or in math-speak > x is a Woman IF AND ONLY IF x is a Person and x is female > states a "definition". It defines an "intension" consisting of a pair of > characteristics that are BOTH necessary and sufficient. > > The sentence: > IF x has given birth to some Person THEN x is a Woman > conveys a sufficient characteristic for the concept Woman, but it is not a > "necessary" characteristic. Being a mother implies being a Woman, but > being a > Woman does not imply being a mother. > > The sentence: > IF x is a Woman THEN x has two X-chromosomes > states a "necessary" condition that is not "sufficient". All female > mammals > have two X-chromosomes. > > So a Definition has to state a set of conditions that are "sufficient" for > classification when taken together, and at the same time "necessary" in > that > they must be exhibited by every member of the class. > > It follows that every condition in the "sufficient" set used in the > Definition > of a concept is a "necessary" property of every instance of the concept. > > As John Hall observed, a Concept can have more than one Definition, each > identifying a set of properties that are sufficient for inclusion in the > extension, and necessary properties of every instance in the extension. > > Definitions are "equivalent" when their extensions are identical. But > mathematically it is often easier to show that the conditions given in one > definition include and imply other necessities that are the sufficient > conditions for the other definition, and vice versa. > > you wrote: > > > 1. Is the intension of a concept made up of one set of sufficient > > characteristics plus all the necessary characteristics that follow from > that > > set of sufficient characteristics? > > > > - or are all the characteristics that comprise an intension called > > necessary characteristics (by your definitions)? If so is there a > notion of > > 'additional' (to a set of sufficient characteristics) necessary > > characteristics; and what is that called? > > Hmm. I think that is a difficult question. I think of "intension" as > being > either: > - a formal definition, comprising one set of sufficient characteristics > - the characterization of things covered by the concept, as conceived by > someone using the signifier. > > The point of "definition by intension" is to provide ONE set of necessary > and > sufficient conditions/characteristics by which an instance of the concept > can > be identified as such. As I said above, it is possible for different > "intensions" in that sense to be equivalent. > > Similarly, what a person conceives as the classification intension may > imply > properties that are unimportant to him but can be used in a > characterization > of the same class from a different viewpoint. (And it is often a problem > in > coming to a service terminology for communication with another speech > community that we realize when that is the case. My "Receiver" is your > "Customer".) > > In some sense, the "intension" of the concept includes all of the > 'necessary' > properties, in that we *may* be able to infer them from the definition(s) > given. > > But in mathematics and physics, for example, it is also commonly the case > that > not all of the necessary properties implied by an intension are known (to > anyone). (For example, the mathematical concept "field" goes back to the > 17th > century -- it describes the rational numbers, among other systems -- and > the > concept "division ring", a weaker generalization, goes back to Etienne > Galois > about 1820, but it wasn't until about 1920 that Wedderburn proved that > every > finite division ring is a field. The missing characteristic -- a*b = b*a > for > all a and b in the ring -- was indeed necessary, it just took 100 years > for > someone to prove it. In the 1950s, Emily Noether came up with a new way > of > characterizing rings, and in her system 'Wedderburn's theorem' was almost > obvious.) > > So I would say that the set of ALL necessary characteristics -- those > understood by the framers of the definition and all others that are > implied, > whether the framers realized that or not -- could be said to be the > "generalized intension". But the "specific intension" is set of > characteristics used in the definition, and the "known intension" is the > set > of all characteristics the framers of the definition realized were made > necessary by that definition. In general, a business vocabulary is about > working with the "known intension". Can we all agree to use "intension" > to > mean the "known intension"? > > It is not easy to characterize the "known intension", by the way. It > includes > properties that are "inherited" from the more general concept, and those > that > are, or can be, "derived" from necessary fact-type relationships, and > those > that are implied by the dictionary meanings of the words used (aka "common > knowledge"), in addition to those that are explicitly stated in the > definition, or directly implied by it. The problem is that, once we allow > the > intension to include "less direct" implications, there is no way to > separate > that from the "generalized intension", which includes everything you could > deduce that way, no matter how convoluted the inferencing path. > > (It is an important part of "responsibility under the law" that some > consequences of a decision can be reasonably foreseen by anyone competent > to > make that decision, while predicting others might require an expert in > some > arcane aspect of the situation. That is essentially the difference > between > the "known intension" and the "generalized intension".) > > > 2. Are the characteristics in one set of sufficient characteristics > and > > those in the set of all necessary characteristics that follow from the > set > > of sufficient characteristics mutually exclusive (by definition)? > > > > - or are the sufficient characteristics all a subset of the > necessary > > characteristics? > > As noted above, not all sufficient characteristics are necessary. But the > ones you choose for a definition are both necessary and sufficient. So > they > are indeed a (not necessarily proper) subset of the necessary > characteristics. > > > 3. Would all of the characteristics in an intension always constitute > a > > set of sufficient (and probably more than sufficient) characteristics, > or > > does sufficient mean that there are no redundant characteristics in the > set? > > The preferred guidance for definitions is not to include redundant > characteristics in the "sufficient set" directly. But the set of all > characteristics in the intension must be at least sufficient. > > > 4. Are there any characteristics that are not either necessary or > > sufficient? > > In logic, I believe properties that are neither necessary nor sufficient > are > called "accidental". A thing can certainly have accidental properties > that > are related to its class but are neither necessary nor sufficient. For > example, a 'licensed driver' can have vehicles registered to him/her and > thus > also be a 'vehicle owner'. And this may be an important accidental > property > of licensed drivers for the Department of Motor Vehicles, but it is > neither > necessary nor sufficient. One can be either without being the other. > > > 5. Do the necessary characteristics follow from: > > > > a. just the sufficient characteristics of the concept? or > > > > b. the sufficient characteristics of the concept plus all (or > some > > part) of the characteristics in the intension of all the concepts in the > > vocabulary related to this concept? > > > > c. b.) plus other knowledge not recorded in the vocabulary? > > Technically, the necessary characteristics arise from being an instance of > the > concept, i.e. satisfying its intension. But the reality is b. > > c. is the case only if we allow that. But it could certainly happen that > some > Necessary characteristic follows from the definition of term A and the > definition of term B AND the knowledge that a NODE word used in one > definition > is a synonym for a NODE word used in the other. > > > 5. It is true that 'a set of sufficient characteristics' can be used > in > > three ways: > > > > a. to provide the more general concept and delimiting > characteristics > > of a definition > > > > b. to distinguish one concept from all others at the meaning (vs. > > representation) level > > > > c. to provide a Reference Scheme for a concept i.e. uniquely > identify > > the instances of the concept. > > Properly, as I said above (repairing what I said before), a set of > "sufficient > characteristics that are also necessary" can be used for a. and b. But c. > is > a different problem entirely. Determining that a thing satisfies the > intension of a concept and determining that two things are "identical" (or > "equal" or "equivalent") are entirely different problems. They both use > the > characteristics of the thing(s), but in different ways. > > If a ReferenceScheme is to be total, i.e., to be useable for every > instance of > the concept, it must be based on one or more necessary characteristics. > But > those characteristics need not be the "necessary and sufficient" > characteristics used in the definition. But since they are necessary, > they > must either be among the ones used in the definition or be implied by the > characteristics used in the definition (in the context of other > definitions in > the vocabulary). So all the characteristics used in a Reference Scheme > must > be part of the "known intension" of the concept. > > For example, the reference scheme for a volume in a series is likely to be > a > particular identifier for the series plus a particular identifier for the > volume. The reference scheme for the volume thus makes use of a (probably > undocumented) fact-type: volume has series-identifier, which is actually > derived by joining the relationships: volume belongs-to-series S, and S > has-identifier series-identifier. > > Note also that "accidental Reference Schemes" -- reference schemes based > on > accidental properties rather than necessary ones -- are in common use. > For > example, EU-Rent might have a business rule that a "customer" must have a > valid driver's licence, and another rule that a "customer" is identified > by a > Reference Scheme comprising the name and address on his driver's licence. > Not > all Persons have driver's licences -- it is not a "necessary" > characteristic. > But the scheme works for all Persons who become "EU Rent customers" > except > when the first business rule is violated. (And we have all seen examples > of > the complexity of the recovery process that occurs when an accidental > reference scheme is broken by the violation of an associated business > rule.) > > I'm sure this is more than you wanted to know. > > -Ed > > > > -- > Edward J. Barkmeyer Email: edbark@nist.gov > National Institute of Standards & Technology > Manufacturing Systems Integration Division > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 > > "The opinions expressed above do not reflect consensus of NIST, > and have not been reviewed by any Government authority." SBVR Architectural Principles for Definitions & Rules v7.doc Concepts about Characteristics 2006-08-07.ppt To: sbvr-ftf@omg.org Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles Document and Diagram for Definitions & Rules X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Tue, 8 Aug 2006 08:45:20 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/08/2006 08:45:24, Serialize complete at 08/08/2006 08:45:24 I think I understand what these principles are saying, and I have no problem with them. I do think the statement of the principles could be clearer: * I'm not sure how to read text such as "Definitions (representations) ...." - One interpretation is that "representations" is a synonym of "definitions". This seems like what the text means. - But section 8.3 makes it clear that a definition is just one kind of meaning. So now I'm left wondering whether the principle applies to all kinds of representations or just to definitions. * Similarly, principle #3 discusses "... the intension of a concept (meaning)". This could be a new definition of "meaning" as "the intension of a concept", or it could be read as "the intension of a concept" plus "concept as a type of meaning". * Regarding principle #4, is there a reason why SBVR has both fact types: "formulate" and "formalizes"? * In #5, does "give form to" mean the same as "formulates"? I ask because in SBVR, the words matter. If they do mean the same thing, it would be clearer to be consistent and use "formulates". Especially because "gives form to" is not defined in the spec. * Issue #9745 addresses the question of what concepts are included in "obligation" and "necessity". Principles #7-9 may depend upon the resolution of that issue. * Where does one find a statement of "term formulation good practice"? Is this the document called "Principles for Asserting the Existence of Things?" * #12 could be made clearer by dividing it into separate principles about "set of sufficient characteristics" versus "sufficient characteristic." This might also help with #21. * How does one identify "set of sufficient characteristics" in SBVR? How does one specify "sufficient characteristics?" * Regarding principle #19 - how does one specify a characteristic that is not necessary. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Reply-To: From: "Donald Chapin" To: Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Date: Wed, 9 Aug 2006 13:20:43 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1A= Attached is the Issue Resolution for Issue 9613 with editing instructions that implement the "SBVR Architectural Principles for Definitions & Rules" document and the "Concepts about Characteristics" diagram. Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 07 August 2006 21:06 > To: 'sbvr-ftf@omg.org' > Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles Document > and Diagram for Definitions & Rules > > > Team -- > > I have updated the "SBVR Architectural Principles for Definitions & Rules" > document and the "Concepts about Characteristics" diagram to bring them in > line with the input from Ed Barkmeyer and the ISO Terminology community > and with our discussion last Wednesday. > > Tomorrow I plan to finish the Issue 9613 Issue Resolution document > containing the editing instructions for discussion on Wednesday. > > Donald Issue9613.doc Disposition: Resolved OMG Issue No: 9613 Title: Explicitly Stated SBVR Architectural Principles for Relationships among 'Definitions' 'Rules' and 'Semantic Formulations' Source: Donald Chapin (donald.chapin@btinternet.com) Summary: The lack of an explicitly stated, concise set of SBVR architectural principles regarding the relationship of 'definitions' 'rules' and 'semantic formulations' is causing much needless SBVR-FTF discussion around related topics. If this lack is causing a problem for the creators of SBVR, then it's going to be even harder for people in the rest of the world to understand and agree on this critical aspect of SBVR. A set of SBVR architectural principles needs to be explicitly stated in SBVR. Resolution: Extensive FTF discussion, both via email and a 1 ½ day face to face meeting, and several revisions of a strawman set of architectural principles and an accompanying diagram covering the characteristics comprising the intension of a concept have resulted in an FTF agreement on both. The following revisions to SBVR ensure that SBVR adequately articulates each of these agreed principles and the relationships illustrated in the diagram. Revised Text: Add these new concepts to Clause 8.1.1 on page 19 immediately following the entry for .concept1 is coextensive with concept2.: characteristic set General Concept: set Definition: set of characteristics sufficient characteristic Definition: characteristic of a concept that specifies one of a set of facts that is said to be sufficient for the concept such that every thing for which that set of facts is true is necessarily an instance of the concept Necessity: Some sufficient characteristics are not necessary characteristics. Necessity: There is possibly more than one sufficient characteristic set in the intension of a given concept. Note: In mathematics and Description Logics .sufficient. means that .the condition implies membership in the category. sufficient characteristic set Definition: characteristic set of sufficient characteristics for a given concept necessary characteristic Definition: characteristic that is implied by the characteristics in a given sufficient characteristic set of a given concept and/or any of the characteristics in the intension of any of the other concepts in the body of shared meanings that are related to the given concept Necessity: a characteristic in the intension of a given concept is always true of any thing that is an instance of that concept. Note: In mathematics and Description Logics .necessary. means that .membership in the category implies the condition. intension Definition: characteristic set of the necessary characteristics that make up a given concept Source: ISO 1087-1 (English) (3.2.9) [.intension.] Synonym: necessary characteristic set Necessity: Two intensions are said to be the same if the intensions contain exactly the same characteristics. Necessity: Two intensions are said to be equivalent if all of the characteristics in the intensions are either the same or equivalent. essential characteristic Definition: characteristic that is both a sufficient characteristic of a that concept and a necessary characteristic in the intension of that concept Concept Type: role Dictionary Basis: a characteristic which is indispensable to understanding a given concept Source: ISO 1087-1 (English) (3.2.6) [.essential characteristic.] essential characteristic set Definition: characteristic set of essential characteristics for a given concept Necessity: There is possibly more than one essential characteristic set in the intension of a given concept. Necessity: There is one essential characteristic set for each sufficient characteristic set. Necessity: The intensional definition of a given concept implies an essential characteristic set for that concept that includes the delimiting characteristics represented by the intensional definition of that concept and the delimiting characteristics represented by the intensional definition of the more general concept of the given concept and all the more general concepts up to and including a concept that does not have a more general concept. Note: An explicit representation of an essential characteristic set in the intension of a concept can be one of these three types of intensional representations: a. A intensional definition containing wording for the more general concept plus all of the delimiting characteristics in the intension with respect to the .more general concept.. b. the fact statements for the form of expression (.concept incorporates characteristic.) for each characteristic in the one set of essential characteristics within the intension. c. A single Structural Rule that is worded in one of the forms itemized under Principle 25 (third prior principle): i. a .concept specializes concept. fact plus a set of facts specifying the delimiting characteristics for the concept with respect to the .more general concept.. ii. a set of facts specifying one set of essential characteristics for the concept. implied characteristic Definition: necessary characteristic in the intension of a given concept with respect to a given essential characteristic set in the intension of that concept that is not a member of the given essential characteristic set Revise the definition of .concept. in Clause 8.1.1 on page numbered 15 to read: Definition: unit of knowledge created by a unique intension Add these two necessities to end of the entry for .concept. Clause 8.1.1 on page numbered 15: Necessity: Two concepts with the same or equivalent intensions are the same concept. Necessity: Two concepts whose intensions are not the same or equivalent are two different concepts. Add a new verb concept immediately following the entry for .concept. in Clause 8.1.1 on page numbered 15: intension creates concept Add this verb concept to Clause 8.1.1.1 on page 19 immediately following the new entry for .sufficient characteristic set.: sufficient characteristic set sufficiently defines concept Revise the entry for .concept incorporates characteristic. in Clause 8.1.1.1 on page numbered 19 to read: Definition: the characteristic is an abstraction of a property of each instance of the concept that is created by the intension into which the characteristic is incorporated Example: The concept .qualified driver. incorporates into its intension the characteristic .driver is licensed. because it is necessary (by the definition of .qualified driver.) that each qualified driver is licensed. Note: The incorporation of a characteristic into the intension of a concept (a fact [proposition]) and a structural rule [a proposition] that specify the same or equivalent logic elements are equivalent propositions (meanings). Example . equivalent meanings: ..woman. incorporates .is female.. (fact [proposition]) (person is female = characteristic) .Necessity: each woman is a female. (structural rule [proposition]) Remove entry for .essential characteristic. from Clause 11.1.2.2 on page numbered 115 as it has been replaced by an entry in Clause 8.1.1 on page numbered 19 Remove entry for .characteristic is essential to concept. in Clause 11.1.2.2 on page numbered 115 as .essential characteristic. is now defined to be a .necessary and sufficient. characteristic and is derivable Revise definition of .delimiting characteristic. in Clause 11.1.2.2 on page numbered 115 as follows: Definition: essential characteristic used for distinguishing a concept from related concepts in the context of a given intensional definition Revise verb concept entry .concept has delimiting characteristic. in Clause 11.1.2.2 on page numbered 115 as follows: Intensional definition has delimiting characteristic Definition: the delimiting characteristic serves to distinguish the concept from other concepts in the context of an intensional definition Concept Type: is-property-of fact type Add the following at the end of the entry for .characteristic. in Clause 8.1.1 on page numbered 16: Necessity: Two characteristics are said to be equivalent if they are either asserted or computed to be equivalent Note: It is essential to distinguish between .characteristic. [unitary verb concept] and the use of characteristics; e.g. the set of characteristics that constitute an intension, or one set of essential characteristics within an intension [proposition] of a concept. Add the ollowing at the end of the entry for .structural rule. in Clause 12.1.2 on page numbered 139 Necessity: Each structural rule (definitional rule) is used in one and only one of the following ways: a. an equivalent meaning for one set of essential characteristics within the intension of a concept, which plays the role of a definition, containing: i. a .concept specializes concept. fact plus a set of facts specifying the delimiting characteristics for the concept with respect to the .more general concept.. ii. a set of facts specifying one set of essential characteristics for the concept. b. an equivalent meaning for an .implied characteristic.. Note: A structural rule can be given a continuous meaning over time using one of two methods: a. Give the structural rule a name in accordance with .term formulation. good practice and change the specific structural rule (proposition) that is the meaning represented by that rule name -- within the limits of the natural language meaning of that name as specified by .term formulation. good practice. b. Create an individual verb concept generalizing the structural rule and specify an .applicable. time frame within the structural rule so that it can be determined which structural rule is the single instance of the individual verb concept at any given time. Note: The incorporation of a characteristic into the intension of a concept (a fact [proposition]) and a structural rule [a proposition] that specify the same or equivalent logic elements are equivalent propositions (meanings). Example . equivalent meanings: ..woman. incorporates .is female.. (fact [proposition]) (person is female = characteristic) .Necessity: each woman is a female. (structural rule [proposition]) Add .implied characteristic. at the end of the list in Annex section C.3 on page numbered 201. Add following to the entry for a SBVR Structured English capability for .implied characteristic. as a new Annex section, C.3.16, on page numbered 208. C.3.16 Implied Characteristic An .Implied Characteristic. is supplemental to a definition. An .Implied Characteristic. caption is used to state something that is necessarily true, but not an essential characteristic. See the vocabulary entries in Part II for characteristics for more details. Example: implication has antecedent Definition: relates the implication to its conditional operand Implied Characteristic: implication having exactly one antecedent. Definitions express characteristics that are necessary and sufficient to distinguish things denoted by a concept. Sometimes there are characteristics beyond what is sufficient. The .Implied Characteristic. caption is used to state such characteristics. Add the following note at the end of the entry for .necessity. in Clause 8.1.2 on page numbered 19. Note: Necessity is interpreted in SBVR as .true by definition.. Add .term. styling to the following occurrences of .intension: - in the definition of .noun concept formulation. in Clause 9.1.1.9 on page numbered 63. - in the definition of .fact type formulation. in Clause 9.1.1.9 on page numbered 64. - in the definition of .category. in Clause 11.1.2.3 on page numbered 116. - in the definition of .more general concept. in Clause 11.1.2.3 on page numbered 116. - in the definition of .intensional definition. in Clause 11.1.3 on page numbered 118. Disposition: Resolved User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 09 Aug 2006 06:04:06 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAAbu5yA== Hi, Donald, I have given this a quick look and find the following items (out of the London meeting) missing from the write-up: * a new fact type 'characteristic set sufficiently delimits concept' * a new fact type ' characteristic set includes characteristic' (Syn. Form: 'characteristic is in characteristic set') -- which uses the existing SBVR fact type that relates a set to its members * a Necessity: A concept incorporates each characteristic in each characteristic set that sufficiently delimits the concept. * a Necessity: A concept incorporates a characteristic if the characteristic is in a characteristic set that sufficiently delimits the concept. ~ Keri On 8/9/06 5:20 AM, "Donald Chapin" wrote: > > Attached is the Issue Resolution for Issue 9613 with editing instructions > that implement the "SBVR Architectural Principles for Definitions & Rules" > document and the "Concepts about Characteristics" diagram. > > Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 09 Aug 2006 06:53:35 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAA3Yjqw== On 8/9/06 5:20 AM, "Donald Chapin" wrote: > > Attached is the Issue Resolution for Issue 9613 with editing instructions > that implement the "SBVR Architectural Principles for Definitions & Rules" > document and the "Concepts about Characteristics" diagram. I spotted that this Proposal proposes to give us a new Definition (plus some new Necessities) for the concept 'concept'. Isn't that ranging outside the scope of this Issue? Weren't these notions core to SBVR agreements forged long ago? I'm recalling the sessions that involved the Neumont folks (Terry, Andy) and Don to hammer out 'concept', 'intension', 'extension' and the like and how these all meshed. Can you please share with us why this vast rewrite is being proposed as this 11th hour? thanks, Keri To: sbvr-ftf@omg.org Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Wed, 9 Aug 2006 11:12:25 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/09/2006 11:12:25, Serialize complete at 08/09/2006 11:12:25 I happened to re-read section F.2 this morning, and noticed that the best practices suggested there are quite opposed to the principles proposed in issue 9613. F.2 argues for: "1. 'Essence by Definitions ...' "2. 'Boundaries by Rules' -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 09 Aug 2006 11:10:22 -0500 To: , From: "Ronald G. Ross" Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules At 07:20 AM 8/9/2006, Donald Chapin wrote: Attached is the Issue Resolution for Issue 9613 with editing instructions that implement the "SBVR Architectural Principles for Definitions & Rules" document and the "Concepts about Characteristics" diagram. I have quickly reviewed the proposed material. I am frankly shocked by the size and impact of this material. It goes well beyond what I would have ever expected at this point in time. It is unfair and unwise to ask the team to address such extensive changes at this late date. Given the number of unresolved issues already on the table, I am not in favor of taking on this new challenge. The BRS position is a follows. SBVR has borrowed where appropriate from the vocabulary standards ISO 1087 and 704. There was no point in re-inventing the wheel. However, it was never in the scope of SBVR to achieve close coordination with ongoing work of the people developing those standards. A suggestion: *If* there are enough members of the team who feel that undertaking this work is important (say 3 or more) and who are willing to volunteer the time, I suggest that the close mapping of SBVR concepts and the ISO notions to be treated as an Annex. I have additional issues, including but certainly not limited to the following. You propose a series of notes to be included in the entry of 'structural business rule', which is in the business-facing side of SBVR. These are completely unacceptable for at least two reasons: 1. Some of the notes are incomprehensible. For example: ********************************************************************* [Donald writes]: a. Give the structural rule a name in accordance with 'term formulation' good practice and change the specific structural rule (proposition) that is the meaning represented by that rule name -- within the limits of the natural language meaning of that name as specified by 'term formulation' good practice. ******************************************************************** 2. Structural rules are perfectly valid, first-class citizens of SBVR. The notes should be placed elsewhere (if anywhere) and treated as 'mapping' (engineering) concerns. As a final general response, I am already gravely concerned that SBVR is so far from the everyday notions of "concept" and "definition" that business people understand and use, that SBVR ceases to be useful as a business-oriented standard. Your proposals seem to take us well beyond that threshold. Ron Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 07 August 2006 21:06 > To: 'sbvr-ftf@omg.org' > Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles Document > and Diagram for Definitions & Rules > > > Team -- > > I have updated the "SBVR Architectural Principles for Definitions & Rules" > document and the "Concepts about Characteristics" diagram to bring them in > line with the input from Ed Barkmeyer and the ISO Terminology community > and with our discussion last Wednesday. > > Tomorrow I plan to finish the Issue 9613 Issue Resolution document > containing the editing instructions for discussion on Wednesday. > > Donald X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 09 Aug 2006 11:40:37 -0500 To: Mark H Linehan , sbvr-ftf@omg.org From: "Ronald G. Ross" Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules At 10:12 AM 8/9/2006, Mark H Linehan wrote: I happened to re-read section F.2 this morning, and noticed that the best practices suggested there are quite opposed to the principles proposed in issue 9613. F.2 argues for: "1. 'Essence by Definitions ...' "2. 'Boundaries by Rules' Mark, Here (below) is an example I circulated earlier this summer to illustrate this (and other) points. In the example, the "essence" definition is the one given by MWUD, and "boundary condition" is given by the structural rule specifying "9". This approach is fundamental to BRS practice, and frankly, to the way *business people* think and talk about "definitions" and "rules". I have been repeatedly assured that SBVR supports this practice. Indeed, from the BRS perspective, SBVR *must* support it. So I am quite interested in your feedback, if there are lingering questions. This is a very fundamental issue. Ron ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This two-part item appeared in the June 12, 2006 issue of Time Magazine ("Notebook" department, under "Numbers"): 75 -- Number of Guantanamo Bay detainees who last week joined a hunger strike led by three inmates who have been force-fed since last August 9 -- Number of consecutive meals a detainee must intentionally miss to be deemed a hunger striker ~~~~~ Definition of "hunger strike" from MWUD: "the action of one especially a prisoner who refuses to eat anything or enough to sustain life so as to obtain compliance with his demands" ~~~~ I want to practice definitions and rules as typical in the real world (meaning people-to-people communication). * In the real world, the definition (meaning) of "hunger strike" is the same yesterday, today and tomorrow, irrespective the threshold for the number of meals missed. The MWUD definition isn't changing. I can look it up tomorrow and it will almost certainly be the same. In other words, the concept will be the *same* concept, whether or not the threshold changes. (If that means the intension excludes the threshold, fine with me.) * In the real world, the commander of Guantanamo Bay might ask his staff, "How many detainees do we have on hunger strike today?" The staff answers "75". That's a fact. * In the real world, the commander of Guantanamo Bay might ask his staff, "What is our *rule* about how many consecutive meals a detainee must intentionally miss to be deemed a hunger striker?" The staff answers "the rule is 9". They would *not* say ""the fact is 9". * In the real world, the commander of Guantanamo Bay might have the rule, "The number of Guantanamo Bay detainees on hunger strike *reported to the press* must be the actual number." That's a rule his staff can *break*. It's fundamentally different from the former rule. Specifically, it is about behavior, rather than how you structure knowledge. The former rule can be misapplied or misunderstood, but it cannot be violated per se. It's just telling someone how to count. I do not want to force everyone to follow this approach, but I do want SBVR to directly support it without smoke and mirrors or a lot of hand-waving. P.S. Instead of "the rule is 9", the staff might answer "our definition says 9". If they want to go that way, fine. It's just not the MWUD way. And in our practice, it's not the business-rule way. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 09 Aug 2006 06:04:06 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAAbu5yA== Hi, Donald, I have given this a quick look and find the following items (out of the London meeting) missing from the write-up: * a new fact type 'characteristic set sufficiently delimits concept' * a new fact type ' characteristic set includes characteristic' (Syn. Form: 'characteristic is in characteristic set') -- which uses the existing SBVR fact type that relates a set to its members * a Necessity: A concept incorporates each characteristic in each characteristic set that sufficiently delimits the concept. * a Necessity: A concept incorporates a characteristic if the characteristic is in a characteristic set that sufficiently delimits the concept. ~ Keri On 8/9/06 5:20 AM, "Donald Chapin" wrote: > > Attached is the Issue Resolution for Issue 9613 with editing instructions > that implement the "SBVR Architectural Principles for Definitions & Rules" > document and the "Concepts about Characteristics" diagram. > > Donald Date: Thu, 10 Aug 2006 11:44:04 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: Mark H Linehan CC: sbvr-ftf@omg.org Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Mark, you wrote: I happened to re-read section F.2 this morning, and noticed that the best practices suggested there are quite opposed to the principles proposed in issue 9613. F.2 argues for: "1. 'Essence by Definitions ...' "2. 'Boundaries by Rules' The problem here is that some concepts and the distinctions among those concepts are fundamental to the business and require mutual understanding in the speech community. In those cases, the "essence" is the (exact) "intension" -- what this term includes and implies and what it does not include or imply. But many concepts in a vocabulary are much softer, in that using them as classifications for things or actions involves business judgement. So the essence is fuzzier, and business rules are used to set (and move!) the boundaries that involve judgements. For example, "criminal" is a person who has been convicted of a crime in a formal judicial process, while "racketeer" is someone who demonstrates a pattern of executing and/or supporting unlawful behaviors. In the first case, there is a "structural rule" (a Necessity) that specifies the essence of "criminal". In the second case, the definition doesn't come with any obvious criterion, but the Justice Department/Ministry will provide some guidelines or business rules that determine when they will prosecute an individual under that charge. And those rules may change with administrations/governments. The idea of the changes to clause 8 is to capture the concepts "essential" and "intension" clearly. The idea of Annex F (in the text you cited) is to provide guidance in distinguishing the well-defined criteria from the judgemental criteria. The fundamental idea is that if the well-defined criteria change, the term has a different meaning (!), and the community has to agree to that (or understand that they are bound by it). But if the judgemental criteria change, the meaning of the term doesn't really change, but the active guidelines/rules for making the judgements change. Further, one can make a business decision that violates a judgemental rule, and may involve some issue of review and enforcement. One cannot make a business decision that violates a structural rule. (Per Ben Franklin, you can call a steer a bull, and he may be flattered, but it doesn't change his situation -- he would much rather have that which entitles him to the designation.) And of course, the criteria for which rules are which are not always well-defined; some of them are judgemental! -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Reply-To: From: "Donald Chapin" To: Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Date: Thu, 10 Aug 2006 16:54:03 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7zluJtDwgeVHvSrO2ymLvBGF+3QAxjhdg Ron, Please see my response in line below. Donald On 09 August 2006 17:10 Ron Ross wrote: > I have quickly reviewed the proposed material. I am frankly shocked by > the size and impact of this material. It goes well beyond what I would > have ever expected at this point in time. It is unfair and unwise to > ask the team to address such extensive changes at this late date. > Given the number of unresolved issues already on the table, I am not > in favor of taking on this new challenge. I am not asking the team to address these Issues. Among others, Issue 9613 was addressed with agreement reached and documented at the London SBVR FTF face-to-face meeting. All we're doing now is finalizing the 9613 Issue Resolution editing instructions based on the documentation of agreement from the London meeting and answers to a few questions posed at that meeting and subsequently discussed in SBVR FTF telecons and emails. If you have concerns about how well some wording of some editing instructions reflects the wording of the documentation coming out of the London meeting, please suggest improvements to specific editing instructions so they more accurately reflect the agreement reached. > The BRS position is a follows. SBVR has borrowed where appropriate > from the vocabulary standards ISO 1087 and 704. There was no point in > re-inventing the wheel. However, it was never in the scope of SBVR to > achieve close coordination with ongoing work of the people developing > those standards. 'Intensional definition', 'characteristic', 'essential characteristic', 'delimiting characteristic' were all adopted into SBVR long ago way before its becoming an OMG specification. All that we did in this Issue when we reached agreement in London was to clarify the relationships among them and between them and 'structural rule', using the definitions of 'sufficient characteristic', 'necessary characteristic', and 'intension' kindly provided by Ed Barkmeyer. This is exactly the subject of Issue 9613. There is no commitment, either explicit or implied, in Issue 9613 Resolution for any line by line mapping with ISO terminology standards over time. > A suggestion: *If* there are enough members of the team who feel that > undertaking this work is important (say 3 or more) and who are willing > to volunteer the time, I suggest that the close mapping of SBVR > concepts and the ISO notions to be treated as an Annex. Such a thing could be done under an Annex, a BMI white paper, a separate RFP, or some other OMG vehicle. The decision to do such a thing is totally separate from Issue 9613 Resolution. > I have additional issues, including but certainly not limited to the > following. You propose a series of notes to be included in the entry > of 'structural business rule', which is in the business-facing side of > SBVR. These are completely unacceptable for at least two reasons: > > 1. Some of the notes are incomprehensible. For example: > > ********************************************************************* > > [Donald writes]: a. Give the structural rule a name in accordance with > 'term formulation' good practice and change the specific structural > rule (proposition) that is the meaning represented by that rule name > -- within the limits of the natural language meaning of that name as > specified by 'term formulation' good practice. > > ******************************************************************** This could be revised to make it clearer: a. Give the structural rule a name (ISO gives guidance for good practice term formulation) and change over time as needed the specific structural rule (proposition) that is the meaning represented by that rule name -- within the limits of the natural language meaning of that name as specified by term formulation good practice. Example (from London meeting): Rule Name: "Hunger Strike" Necessity 1: a detainee must intentionally miss 9 consecutive meals Necessity 2: a detainee must intentionally miss 9 consecutive meals (These necessities serve as equivalent of an intensional definition) Rule Name <-> Rule Meaning Connection: "Hunger Strike" <-> Necessity 1 (during Q1 2006) "Hunger Strike" <-> Necessity 2 (during Q2 2006) By the way this is in the form of a note, not a necessity. > 2. Structural rules are perfectly valid, first-class citizens of SBVR. > The notes should be placed elsewhere (if anywhere) and treated as > 'mapping' (engineering) concerns. > As a final general response, I am already gravely concerned that SBVR > is so far from the everyday notions of "concept" and "definition" > that business people understand and use, that SBVR ceases to be useful > as a business-oriented standard. Your proposals seem to take us well > beyond that threshold. I've always found that writing definitions in the ISO intensional style is a very good way for business people to understand and accept them. Reply-To: From: "Donald Chapin" To: Subject: FW: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Date: Thu, 10 Aug 2006 16:58:59 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca7zluJtDwgeVHvSrO2ymLvBGF+3QAxjhdgAABFy3A= Error below: Necessity 2 should read "a detainee must intentionally miss 11 consecutive meals" Sorry, Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 10 August 2006 16:54 > To: 'sbvr-ftf@omg.org' > Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing > Principles Document and Characteristics Diagram for Definitions & Rules > > Ron, > > Please see my response in line below. > > Donald > > > On 09 August 2006 17:10 Ron Ross wrote: > > > I have quickly reviewed the proposed material. I am frankly shocked by > > the size and impact of this material. It goes well beyond what I would > > have ever expected at this point in time. It is unfair and unwise to > > ask the team to address such extensive changes at this late date. > > Given the number of unresolved issues already on the table, I am not > > in favor of taking on this new challenge. > > I am not asking the team to address these Issues. Among others, Issue > 9613 was addressed with agreement reached and documented at the London > SBVR FTF face-to-face meeting. > > All we're doing now is finalizing the 9613 Issue Resolution editing > instructions based on the documentation of agreement from the London > meeting and answers to a few questions posed at that meeting and > subsequently discussed in SBVR FTF telecons and emails. > > If you have concerns about how well some wording of some editing > instructions reflects the wording of the documentation coming out of the > London meeting, please suggest improvements to specific editing > instructions so they more accurately reflect the agreement reached. > > > > The BRS position is a follows. SBVR has borrowed where appropriate > > from the vocabulary standards ISO 1087 and 704. There was no point in > > re-inventing the wheel. However, it was never in the scope of SBVR to > > achieve close coordination with ongoing work of the people developing > > those standards. > > 'Intensional definition', 'characteristic', 'essential characteristic', > 'delimiting characteristic' were all adopted into SBVR long ago way before > its becoming an OMG specification. All that we did in this Issue when we > reached agreement in London was to clarify the relationships among them > and between them and 'structural rule', using the definitions of > 'sufficient characteristic', 'necessary characteristic', and 'intension' > kindly provided by Ed Barkmeyer. > > This is exactly the subject of Issue 9613. > > There is no commitment, either explicit or implied, in Issue 9613 > Resolution for any line by line mapping with ISO terminology standards > over time. > > > > A suggestion: *If* there are enough members of the team who feel that > > undertaking this work is important (say 3 or more) and who are willing > > to volunteer the time, I suggest that the close mapping of SBVR > > concepts and the ISO notions to be treated as an Annex. > > Such a thing could be done under an Annex, a BMI white paper, a separate > RFP, or some other OMG vehicle. > > The decision to do such a thing is totally separate from Issue 9613 > Resolution. > > > > I have additional issues, including but certainly not limited to the > > following. You propose a series of notes to be included in the entry > > of 'structural business rule', which is in the business-facing side of > > SBVR. These are completely unacceptable for at least two reasons: > > > > 1. Some of the notes are incomprehensible. For example: > > > > ********************************************************************* > > > > [Donald writes]: a. Give the structural rule a name in accordance with > > 'term formulation' good practice and change the specific structural > > rule (proposition) that is the meaning represented by that rule name > > -- within the limits of the natural language meaning of that name as > > specified by 'term formulation' good practice. > > > > ******************************************************************** > > This could be revised to make it clearer: > > a. Give the structural rule a name (ISO gives guidance for good practice > term formulation) and change over time as needed the specific structural > rule (proposition) that is the meaning represented by that rule name -- > within the limits of the natural language meaning of that name as > specified by term formulation good practice. > > Example (from London meeting): > > Rule Name: "Hunger Strike" > > Necessity 1: a detainee must intentionally miss 9 consecutive meals > Necessity 2: a detainee must intentionally miss 9 consecutive meals > (These necessities serve as equivalent of an intensional definition) > > Rule Name <-> Rule Meaning Connection: > > "Hunger Strike" <-> Necessity 1 (during Q1 2006) > "Hunger Strike" <-> Necessity 2 (during Q2 2006) > > > By the way this is in the form of a note, not a necessity. > > > > 2. Structural rules are perfectly valid, first-class citizens of SBVR. > > The notes should be placed elsewhere (if anywhere) and treated as > > 'mapping' (engineering) concerns. > > As a final general response, I am already gravely concerned that SBVR > > is so far from the everyday notions of "concept" and "definition" > > that business people understand and use, that SBVR ceases to be useful > > as a business-oriented standard. Your proposals seem to take us well > > beyond that threshold. > > I've always found that writing definitions in the ISO intensional style is > a very good way for business people to understand and accept them. Reply-To: From: "Donald Chapin" To: Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution - Added Sentence to "Resolution" Section Date: Thu, 10 Aug 2006 17:08:08 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAOkZHYA== It has been suggested that the following sentence be added as a separate first paragraph under the "Resolution" section of the Issue 9613 Resolution document (Issue9613.doc): "The main change in the resolution of this Issue is to clarify the relationships among 'Intensional definition', 'characteristic', 'essential characteristic', 'delimiting characteristic' and the relationships between them and 'structural rule'." Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 09 August 2006 13:21 > To: 'sbvr-ftf@omg.org' > Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing > Principles Document and Characteristics Diagram for Definitions & Rules > > > Attached is the Issue Resolution for Issue 9613 with editing instructions > that implement the "SBVR Architectural Principles for Definitions & Rules" > document and the "Concepts about Characteristics" diagram. > > Donald > > > > -----Original Message----- > > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > > Sent: 07 August 2006 21:06 > > To: 'sbvr-ftf@omg.org' > > Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles Document > > and Diagram for Definitions & Rules > > > > > > Team -- > > > > I have updated the "SBVR Architectural Principles for Definitions & > Rules" > > document and the "Concepts about Characteristics" diagram to bring them > in > > line with the input from Ed Barkmeyer and the ISO Terminology community > > and with our discussion last Wednesday. > > > > Tomorrow I plan to finish the Issue 9613 Issue Resolution document > > containing the editing instructions for discussion on Wednesday. > > > > Donald Reply-To: From: "Donald Chapin" To: Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles Document and Diagram for Definitions & Rules Date: Thu, 10 Aug 2006 17:32:59 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca66IrFkyE5HgdnQ2izznmZx605HQBrs0TQ Mark, Please see my responses in-line below. Donald -------------------------------------------------------------------------------- From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: 08 August 2006 13:45 To: sbvr-ftf@omg.org Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles Document and Diagram for Definitions & Rules I think I understand what these principles are saying, and I have no problem with them. I do think the statement of the principles could be clearer: * I'm not sure how to read text such as "Definitions (representations) ...." - One interpretation is that "representations" is a synonym of "definitions". This seems like what the text means. The purpose was to remind the reader that .definitions. are a category of .representation. and not a kind of meaning; i.e. that I was talking about representation and not meaning. - But section 8.3 makes it clear that a definition is just one kind of meaning. So now I'm left wondering whether the principle applies to all kinds of representations or just to definitions. .Definition. is not a kind of meaning; it is a kind of representation. .Concept. and .intension. are in the .meaning space.. * Similarly, principle #3 discusses "... the intension of a concept (meaning)". This could be a new definition of "meaning" as "the intension of a concept", or it could be read as "the intension of a concept" plus "concept as a type of meaning". Again this is a reminder that I am talking about .meaning. and not .representation. here. * Regarding principle #4, is there a reason why SBVR has both fact types: "formulate" and "formalizes"? There are two different relationships. The .formulate. verb phrase relationship is about creating a very abstract structure for representing a meaning. The formalize verb phrase relationship is about the natural language wording of the representation; i.e. can the natural language wording be interpreted in formal logics or not? * In #5, does "give form to" mean the same as "formulates"? I ask because in SBVR, the words matter. If they do mean the same thing, it would be clearer to be consistent and use "formulates". Especially because "gives form to" is not defined in the spec. This wording will not go into the SBVR specification. I was using different phrasing aid understanding. * Issue #9745 addresses the question of what concepts are included in "obligation" and "necessity". Principles #7-9 may depend upon the resolution of that issue. SBVR is very clear on .obligation. and .necessity.. It is admonition and affirmation that are not so clear. In any case, the Issue 9613 Resolution document contains no editing instructions regarding these three principles. * Where does one find a statement of "term formulation good practice"? Is this the document called "Principles for Asserting the Existence of Things?" In ISO 704 .Terminology Work . Principles and Methods. Annex A. In Terminology Tutorial (http://www.termium.gc.ca/didacticiel_tutorial/english/lesson1/index_e.html) In .Handbook of Terminology (http://www.translationbureau.gc.ca/pwgsc_internet/fr/publications/gratuit_free/man_termino_e.htm) * #12 could be made clearer by dividing it into separate principles about "set of sufficient characteristics" versus "sufficient characteristic." This might also help with #21. This was done in the Issue 9613 Resolution editing instructions which is what affects what goes into the SBVR specification. * How does one identify "set of sufficient characteristics" in SBVR? How does one specify "sufficient characteristics?" It was decided to add a fact type for that at the London SBVR FTF meeting. You will find this in the Issue 9613 Resolution document. * Regarding principle #19 - how does one specify a characteristic that is not necessary. Compare the list of necessary characteristics with the list of sufficient characteristics and see which sufficient characteristics are not on the necessary characteristic list. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 10 Aug 2006 20:49:48 -0500 To: , From: "Ronald G. Ross" Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules At 10:54 AM 8/10/2006, Donald Chapin wrote: Ron, Please see my response in line below. Donald On 09 August 2006 17:10 Ron Ross wrote: > I have quickly reviewed the proposed material. I am frankly shocked by > the size and impact of this material. It goes well beyond what I would > have ever expected at this point in time. It is unfair and unwise to > ask the team to address such extensive changes at this late date. > Given the number of unresolved issues already on the table, I am not > in favor of taking on this new challenge. I am not asking the team to address these Issues. Among others, Issue 9613 was addressed with agreement reached and documented at the London SBVR FTF face-to-face meeting. All we're doing now is finalizing the 9613 Issue Resolution editing instructions based on the documentation of agreement from the London meeting and answers to a few questions posed at that meeting and subsequently discussed in SBVR FTF telecons and emails. Donald, With all due respect, suggesting that the host of new ideas you have presented in any way documents what we agreed in London stretches credence beyond any point of reason. The whole point of the London agreement was that there would *not* be anything more/new. None of this was discussed in London as part of any general agreement. Here is an example. You have suggested a new definition for "concept" (perhaps the most basic concept in the whole document). Not only did we not discuss that, the new definition actually *changes* the definition we adopted from ISO(!). So we're no longer even in sync with ISO (or are you saying we can somehow say what they mean even better than they actually said?!). Anyway, I *know* we did not discuss that! Another example: You drafted a whole series of new notes for structural rules. These were most certainly *not* part of any explicitly documented part of any agreement in London. I would never have agreed them in that form or in that location. In addition, have you passed these new ideas by Terry Halpin and Neumont? You recall what a heck of a time we had getting even limited time from them on the basic underpinnings of SBVR. Besides the general concern, I am specifically concerned about whether they are comfortable with rule (which includes necessity) being aligned in the new ways your new material suggests. And frankly, your proposals are drafted as if they were done in great haste. I have already given an example from the note for Structural Rules. There are other examples. I repeat from my earlier e-mail, it is too late in the day to be taking on this kind of challenge. Ron If you have concerns about how well some wording of some editing instructions reflects the wording of the documentation coming out of the London meeting, please suggest improvements to specific editing instructions so they more accurately reflect the agreement reached. > The BRS position is a follows. SBVR has borrowed where appropriate > from the vocabulary standards ISO 1087 and 704. There was no point in > re-inventing the wheel. However, it was never in the scope of SBVR to > achieve close coordination with ongoing work of the people developing > those standards. 'Intensional definition', 'characteristic', 'essential characteristic', 'delimiting characteristic' were all adopted into SBVR long ago way before its becoming an OMG specification. All that we did in this Issue when we reached agreement in London was to clarify the relationships among them and between them and 'structural rule', using the definitions of 'sufficient characteristic', 'necessary characteristic', and 'intension' kindly provided by Ed Barkmeyer. This is exactly the subject of Issue 9613. There is no commitment, either explicit or implied, in Issue 9613 Resolution for any line by line mapping with ISO terminology standards over time. > A suggestion: *If* there are enough members of the team who feel that > undertaking this work is important (say 3 or more) and who are willing > to volunteer the time, I suggest that the close mapping of SBVR > concepts and the ISO notions to be treated as an Annex. Such a thing could be done under an Annex, a BMI white paper, a separate RFP, or some other OMG vehicle. The decision to do such a thing is totally separate from Issue 9613 Resolution. > I have additional issues, including but certainly not limited to the > following. You propose a series of notes to be included in the entry > of 'structural business rule', which is in the business-facing side of > SBVR. These are completely unacceptable for at least two reasons: > > 1. Some of the notes are incomprehensible. For example: > > ********************************************************************* > > [Donald writes]: a. Give the structural rule a name in accordance with > 'term formulation' good practice and change the specific structural > rule (proposition) that is the meaning represented by that rule name > -- within the limits of the natural language meaning of that name as > specified by 'term formulation' good practice. > > ******************************************************************** This could be revised to make it clearer: a. Give the structural rule a name (ISO gives guidance for good practice term formulation) and change over time as needed the specific structural rule (proposition) that is the meaning represented by that rule name -- within the limits of the natural language meaning of that name as specified by term formulation good practice. Example (from London meeting): Rule Name: "Hunger Strike" Necessity 1: a detainee must intentionally miss 9 consecutive meals Necessity 2: a detainee must intentionally miss 9 consecutive meals (These necessities serve as equivalent of an intensional definition) Rule Name <-> Rule Meaning Connection: "Hunger Strike" <-> Necessity 1 (during Q1 2006) "Hunger Strike" <-> Necessity 2 (during Q2 2006) By the way this is in the form of a note, not a necessity. > 2. Structural rules are perfectly valid, first-class citizens of SBVR. > The notes should be placed elsewhere (if anywhere) and treated as > 'mapping' (engineering) concerns. > As a final general response, I am already gravely concerned that SBVR > is so far from the everyday notions of "concept" and "definition" > that business people understand and use, that SBVR ceases to be useful > as a business-oriented standard. Your proposals seem to take us well > beyond that threshold. I've always found that writing definitions in the ISO intensional style is a very good way for business people to understand and accept them. User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 10 Aug 2006 20:36:57 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RA== On 8/9/06 5:20 AM, "Donald Chapin" wrote: > > Attached is the Issue Resolution for Issue 9613 with editing instructions > that implement the "SBVR Architectural Principles for Definitions & Rules" > document and the "Concepts about Characteristics" diagram. Donald, I have been working on the diagram I offered at our last meeting. It is taking longer than I had hoped, so here are some initial comments. First, general ones; then, specifics. General: a) There are numerous errors in the SBVR-SE styling for things intended to be formal. For example, random phrases are claimed to be .keyword. (but are not), and (more problematic) some are styled .keyword. when they should be .verb.. Specifically, all of your .of. uses should be verb (for .has/is of.). b) Following on from this... As I tried to reconcile what I took to be the verb .of. (i.e., appealing to a .has. fact type), I often had difficulty finding the supporting (based on) fact type. For example, you say .characteristic of concept. when I assume you intend to mean what is represented by the fact type .is incorporated into. (.incorporates.). Trying to go from bits of a definition that claim to be formal but aren.t is taking me more time than I had anticipated. I know you don.t like the has/of form practice so when I see you use it in cases where a stronger verb is offered I pause to ponder whether I correctly interpret your intent. c) Some vocabulary elements appear to be under the wrong item. For example, you have a Necessity and a Note under .sufficient characteristic. that seem more appropriate to .sufficient characteristic set.. d) In London, we said that the characteristics appearing in the various sets were .roles. (i.e., that being in some relevant set is what makes a characteristic of that particular type). However, you show these as categories. That seems wrong (per the London agreement). This also has some interesting side-effect (which I.ll get to under the Specifics). e) Some of the elements of the instructions are not styled correctly. For example, several of the Notes. One, in particular, retains a reference to the Architectural Principles document. f) Finally, for the sake of the editor (and anyone who is attempting to work from these instructions), it would help greatly if you could place them in order of the pages that will be changed. I did quite a bit of jumping around until I compiled the following .cheat sheet.. For anyone trying to print the relevant, impacted pages from the PDF, here is what you.ll need (the first number is the PDF footer-page number; the second number is what you.ll tell your Print Dialog): 15 ==> 29 16 ==> 30 18 ==> 32 19 ==> 33 63 ==> 77 64 ==> 78 114 ==> 128 115 ==> 129 116 ==> 130 118 ==> 132 139 ==> 153 201 ==> 215 208 ==> 222 Specifics: 1) A critical fact type appears to be missing. I could find no way to relate a characteristic set with a concept. Indeed, as you stated in the last telcon, you took the fact type .characteristic set sufficiently delimits concept. (with the verb phrase changed, I sense, erroneously) from the London agreement and demoted it to one of the categories. But you do rely on there being a fact type at the most general level in several of the constraints that you express in your formal styling. 2) Following on from (1) there is a missing constraint . to ensure that all of the characteristics that are members of their appropriate, specialized set to belong to the same concept that .owns. the characteristic set. This is a standard pattern when you have a .triangle. of fact types. (Check with John Hall . it.s standard in the Model Systems material.) There were two rules on a London flipchart that illustrated this. 3) There are problems in the sequence of SBVR Vocabulary presentation that you have outlined. For example, you ask for .concept. (p. 15) to be changed to use .intension. in its definition and yet that term (.intension.) is not introduced until a later section/diagram. Also problematic is your instruction to add .intension creates concept. on p. 15. 4) One of the changes introduces a challenge to the circles of compliance. .Intensional definition. (from Clause 11/business-facing vocabulary) is now relied upon in Clause 8. 5) Why does the entry for .characteristic set. use a General Concept line when the same mgc is given at the beginning of the Definition? 6) What does the Necessity under .sufficient characteristic. mean? (Categories are not mutually exclusive unless so-declared so this does not appear to be needed ... and the syntax appears wrong.) 7) What does the last Note under .sufficient characteristic. mean, in SBVR terms? 8) What does the Note under .essential characteristic set. mean? (And did we agree this?) In particular, please decode this phrase: .an explicit representation of an essential characteristic set in the intension of a concept.. (Is there a not-explicit representation of a characteristic set, of any type, in the intension of a concept.?) 9) The two new Necessities for .concept. don.t appear to be in correct SBVR-SE. And, what do they mean/imply? (This has not been discussed.) 10) In London, in the fact type that relates a characteristic-set to its related concept, .determines. was used rather than .defines. . This makes a difference in meaning. 11) In the new Note for .concept incorporates characteristic. the sentence seems to have the wrong object. In any case, the sentence is foggy. 12) You justify the removal of the fact type .characteristic is essential to concept. (Clause 11) in part because you claim it is derivable. That is unclear. 13) The Clause 11 definition of .delimiting characteristic. relied on .essential characteristic. being a role. While .essential characteristic. remains defined as not a role, there is a problem with the representation of delimiting characteristic. 14) The fact type that .delimiting characteristic. participates in was changed from .concept. to .intensional definition.. I don.t recall that being explained/discussed/agreed. 15) A Necessity has been added under .structural rule.. It is unclear. 16) The first Note under .structural rule. is unclear. (And I do not recall we ever discussed giving something dealing with .continuous meaning over time.. Is that within our scope?) 17) The 2nd Note under .structural role. is unclear. (Also, I do not recall agreeing it.) ~~~~~~~~ I will continue to work on the consolidated diagram and, if I am able to produce something useful, will send it off for tomorrow.s meeting. ~ Keri Reply-To: From: "Donald Chapin" To: Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Date: Fri, 11 Aug 2006 12:52:08 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQ Ron, On 11 August 2006 02:50 Ron Ross wrote: > Here is an example. You have suggested a new definition for > "concept" (perhaps the most basic concept in the whole document). Not > only did we not discuss that, the new definition actually *changes* > the definition we adopted from ISO(!). So we're no longer even in sync > with ISO (or are you saying we can somehow say what they mean even > better than they actually said?!). Anyway, I *know* we did not discuss > that! Just two things were done to the definition of concept: 1. 'Necessary' was inserted before the word 'characteristics' to incorporate the answers from Ed Barkmeyer to questions posed for him to answer in the London meeting; so that it read "unit of knowledge created by a unique combination of necessary characteristics". 2. 'Intension' was substituted for its synonym 'combination of necessary characteristics' ('necessary characteristic set'). > In addition, have you passed these new ideas by Terry Halpin > and Neumont? You recall what a heck of a time we had getting even > limited time from them on the basic underpinnings of SBVR. Besides the > general concern, I am specifically concerned about whether they are > comfortable with rule (which includes necessity) being aligned in the > new ways your new material suggests. Neumont University is on the SBVR FTF and they regular comment on Issue Resolutions that concern them. Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 11 Aug 2006 05:24:26 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules From: John and Keri To: "Donald R. Chapin" , SBVR-FTF CC: Terry Halpin , Andy Carver Thread-Topic: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CE= On 8/11/06 4:52 AM, "Donald Chapin" wrote: >> In addition, have you passed these new ideas by Terry Halpin >> and Neumont? You recall what a heck of a time we had getting even >> limited time from them on the basic underpinnings of SBVR. Besides the >> general concern, I am specifically concerned about whether they are >> comfortable with rule (which includes necessity) being aligned in the >> new ways your new material suggests. > > Neumont University is on the SBVR FTF and they regular comment on Issue > Resolutions that concern them. Donald, I read in Ron's note that he would like to call on that 'special attention' that you can get from Terry (as you have on other critical issues -- e.g., in the last meeting when you said you could get him specifically involved to review work underway by Ed and Don). Since this deals with things to do with intension, extension, etc. and may alter aspects agreed long-ago in the Don/Terry dialogs (not to mention the Pat Hayes understanding), I (for one) would very much like to hear Terry's assessment of any impact. Thanks, Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 11 Aug 2006 06:04:58 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules From: John and Keri To: "Donald R. Chapin" , SBVR-FTF CC: Terry Halpin , "'Andy Carver'" Thread-Topic: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CEAAHh4MAAA8e4a Thanks, Donald. Another point occurs to me (as I continue work on the diagram) when I came to 'intension', which is taking on 'necessary characteristic set' as a synonym. The edit instructions need to specify which of the new (and perhaps changed) entries need (or lose) the little 'FL' tag. And for those, I would think that the Neumont folks would want to pay particular attention since they will be involved in the Clause 10 mapping. ~ Keri On 8/11/06 5:38 AM, "Donald Chapin" wrote: > Keri, > > Will do. > > Donald > > > >> -----Original Message----- >> From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] >> Sent: 11 August 2006 13:24 >> To: Donald R. Chapin; SBVR-FTF >> Cc: Terry Halpin; Andy Carver >> Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing >> Principles Document and Characteristics Diagram for Definitions & Rules >> >> On 8/11/06 4:52 AM, "Donald Chapin" wrote: >> >>>> In addition, have you passed these new ideas by Terry Halpin >>>> and Neumont? You recall what a heck of a time we had getting even >>>> limited time from them on the basic underpinnings of SBVR. Besides the >>>> general concern, I am specifically concerned about whether they are >>>> comfortable with rule (which includes necessity) being aligned in the >>>> new ways your new material suggests. >>> >>> Neumont University is on the SBVR FTF and they regular comment on Issue >>> Resolutions that concern them. >> >> Donald, >> >> I read in Ron's note that he would like to call on that 'special >> attention' >> that you can get from Terry (as you have on other critical issues -- e.g., >> in the last meeting when you said you could get him specifically involved >> to >> review work underway by Ed and Don). >> >> Since this deals with things to do with intension, extension, etc. and may >> alter aspects agreed long-ago in the Don/Terry dialogs (not to mention the >> Pat Hayes understanding), I (for one) would very much like to hear Terry's >> assessment of any impact. >> >> Thanks, >> Keri >> > > > Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Cc: "'Terry Halpin'" , "'Andy Carver'" Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Date: Fri, 11 Aug 2006 13:38:20 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CEAAHh4MA== Keri, Will do. Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 11 August 2006 13:24 > To: Donald R. Chapin; SBVR-FTF > Cc: Terry Halpin; Andy Carver > Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing > Principles Document and Characteristics Diagram for Definitions & Rules > > On 8/11/06 4:52 AM, "Donald Chapin" wrote: > > >> In addition, have you passed these new ideas by Terry Halpin > >> and Neumont? You recall what a heck of a time we had getting even > >> limited time from them on the basic underpinnings of SBVR. Besides the > >> general concern, I am specifically concerned about whether they are > >> comfortable with rule (which includes necessity) being aligned in the > >> new ways your new material suggests. > > > > Neumont University is on the SBVR FTF and they regular comment on Issue > > Resolutions that concern them. > > Donald, > > I read in Ron's note that he would like to call on that 'special > attention' > that you can get from Terry (as you have on other critical issues -- e.g., > in the last meeting when you said you could get him specifically involved > to > review work underway by Ed and Don). > > Since this deals with things to do with intension, extension, etc. and may > alter aspects agreed long-ago in the Don/Terry dialogs (not to mention the > Pat Hayes understanding), I (for one) would very much like to hear Terry's > assessment of any impact. > > Thanks, > Keri > User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 11 Aug 2006 06:42:53 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Diagram view (a) From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Diagram view (a) Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CEAAHh4MAACRO5E Donald & Team, For our discussion... Attached is a (first-cut) diagram reflecting Issue 9613. ~ Keri file: ViewPer9613-a.jpg ViewPer9613-a.jpg Reply-To: From: "Donald Chapin" To: "'John and Keri'" , "'SBVR-FTF'" Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules Date: Fri, 11 Aug 2006 15:17:24 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RAAWTcBg Keri, -------------------------------------------------------------------------------- On 11 August 2006 04:37 Keri wrote: Donald, I have been working on the diagram I offered at our last meeting. It is taking longer than I had hoped, so here are some initial comments. First, general ones; then, specifics. Thanks for the work and the feedback which I respond to below. General: a) There are numerous errors in the SBVR-SE styling for things intended to be formal. For example, random phrases are claimed to be .keyword. (but are not), and (more problematic) some are styled .keyword. when they should be .verb.. Specifically, all of your .of. uses should be verb (for .has/is of.). I said in the SBVR FTF meeting Wednesday that I concentrated on the getting the content right from the meeting notes and the input form ED Barkmeyer and the ISO terminology people, and that there were almost certainly technical errors in the SBVR Structured English. b) Following on from this... As I tried to reconcile what I took to be the verb .of. (i.e., appealing to a .has. fact type), I often had difficulty finding the supporting (based on) fact type. For example, you say .characteristic of concept. when I assume you intend to mean what is represented by the fact type .is incorporated into. (.incorporates.). Trying to go from bits of a definition that claim to be formal but aren.t is taking me more time than I had anticipated. I know you don.t like the has/of form practice so when I see you use it in cases where a stronger verb is offered I pause to ponder whether I correctly interpret your intent. Again I was doing the best to get the content into the fewest and simplest editing instructions as requested, and simply couldn.t focus on the validation checking a tool would do for me at the same time. It required another pass through the Issue Resolution document to go through that SBVR SE validation process, but I ran out of time before the Wednesday FTF telecon. I apologize for causing you extra work. c) Some vocabulary elements appear to be under the wrong item. For example, you have a Necessity and a Note under .sufficient characteristic. that seem more appropriate to .sufficient characteristic set.. Please suggest the correct entry to put them under. d) In London, we said that the characteristics appearing in the various sets were .roles. (i.e., that being in some relevant set is what makes a characteristic of that particular type). However, you show these as categories. That seems wrong (per the London agreement). This also has some interesting side-effect (which I.ll get to under the Specifics). We can work out the .role. vs. .category. question with Ed Barkmeyer.s help. e) Some of the elements of the instructions are not styled correctly. For example, several of the Notes. One, in particular, retains a reference to the Architectural Principles document. Styling needs to be fixed and the reference removed. f) Finally, for the sake of the editor (and anyone who is attempting to work from these instructions), it would help greatly if you could place them in order of the pages that will be changed. Reordering the editing instructions is easily done. I did quite a bit of jumping around until I compiled the following .cheat sheet.. For anyone trying to print the relevant, impacted pages from the PDF, here is what you.ll need (the first number is the PDF footer-page number; the second number is what you.ll tell your Print Dialog): 15 ==> 29 16 ==> 30 18 ==> 32 19 ==> 33 63 ==> 77 64 ==> 78 114 ==> 128 115 ==> 129 116 ==> 130 118 ==> 132 139 ==> 153 201 ==> 215 208 ==> 222 Specifics: 1) A critical fact type appears to be missing. I could find no way to relate a characteristic set with a concept. Indeed, as you stated in the last telcon, you took the fact type .characteristic set sufficiently delimits concept. (with the verb phrase changed, I sense, erroneously) from the London agreement and demoted it to one of the categories. But you do rely on there being a fact type at the most general level in several of the constraints that you express in your formal styling. Intension. whose synonym is .necessary characteristic set. is related to concept in its definition and in the fact type .intension creates concept. taken from the definition. I can add a note to this entry to say this. 2) Following on from (1) there is a missing constraint . to ensure that all of the characteristics that are members of their appropriate, specialized set to belong to the same concept that .owns. the characteristic set. This is a standard pattern when you have a .triangle. of fact types. (Check with John Hall . it.s standard in the Model Systems material.) There were two rules on a London flipchart that illustrated this. When we see the diagram that takes .sufficient characteristic. and .necessary characteristic. into account, we will know if that pattern still exists. 3) There are problems in the sequence of SBVR Vocabulary presentation that you have outlined. For example, you ask for .concept. (p. 15) to be changed to use .intension. in its definition and yet that term (.intension.) is not introduced until a later section/diagram. Then we need to put it where it belongs Also problematic is your instruction to add .intension creates concept. on p. 15. On what basis is this problematic? 4) One of the changes introduces a challenge to the circles of compliance. .Intensional definition. (from Clause 11/business-facing vocabulary) is now relied upon in Clause 8. Then it needs to be moved to Clause 8 5) Why does the entry for .characteristic set. use a General Concept line when the same mgc is given at the beginning of the Definition? It doesn.t need to. It.s an SBVR SE technicality I overlooked. 6) What does the Necessity under .sufficient characteristic. mean? (Categories are not mutually exclusive unless so-declared so this does not appear to be needed ... and the syntax appears wrong.) See .Concepts about Characteristics. diagram. We agreed there could be multiple .sufficient characteristic sets. in the intension of one concept. The multiple .essential characteristic sets. follow directly based on the definition of .essential characteristic.. 7) What does the last Note under .sufficient characteristic. mean, in SBVR terms? Ask Ed Barkmeyer to elaborate. It says the same thing as the definition for the concept 8) What does the Note under .essential characteristic set. mean? (And did we agree this?) It.s from the principles document gone over in detail in London and included in the meeting notes. It says there are three ways to write down what is in an essential characteristic set. In particular, please decode this phrase: .an explicit representation of an essential characteristic set in the intension of a concept.. See the latest .Concepts about Characteristics. diagram for .essential characteristic set in the intension of a concept. (Is there a not-explicit representation of a characteristic set, of any type, in the intension of a concept.?) Yes, an .intensional definition. does not explicit, directly (maybe directly is a better word) state all the essential characteristic in one of the sets of essential characteristics in the intension of a concept. It only directly, explicitly states the .delimiting characteristics.. The rest are inherited from higher level delimiting characteristics. 9) The two new Necessities for .concept. don.t appear to be in correct SBVR-SE. And, what do they mean/imply? (This has not been discussed.) Then they will be fixed. They mean what they say based on the other related definitions. If you have a more specific question, please ask and I.ll respond. This is based on the principle discussed in London that different intensions (different sets of necessary characteristics) create different concepts. 10) In London, in the fact type that relates a characteristic-set to its related concept, .determines. was used rather than .defines. . This makes a difference in meaning. This can be discussed. Ed Barkmeyer can help with the right word. 11) In the new Note for .concept incorporates characteristic. the sentence seems to have the wrong object. In any case, the sentence is foggy. The is straight from the principles that we agreed. The word .both. is missing. Fixed as: .The incorporation of a characteristic into the intension of a concept (a fact [proposition]) and a structural rule [a proposition] that both specify the same or equivalent logic elements are equivalent propositions (meanings). Maybe the wording needs clarifying. If so, let.s do it. 12) You justify the removal of the fact type .characteristic is essential to concept. (Clause 11) in part because you claim it is derivable. That is unclear. There is a fact type (agreed in London) to state that a given characteristics is a sufficient characteristic in a set of sufficient characteristics for a given concept. There is another fact type (concept incorporates characteristic) to state that a given characteristics is a necessary characteristic in the intension of a given concept. If a characteristic is specific both to be a sufficient characteristic and a necessary characteristic, it is by definition an essential characteristic. 13) The Clause 11 definition of .delimiting characteristic. relied on .essential characteristic. being a role. While .essential characteristic. remains defined as not a role, there is a problem with the representation of delimiting characteristic. We can work out the .role. vs. .category. question with Ed Barkmeyer.s help. 14) The fact type that .delimiting characteristic. participates in was changed from .concept. to .intensional definition.. I don.t recall that being explained/discussed/agreed. It is a logical consequence of having multiple ways of creating an .intensional definition. and the fact that a characteristic is .delimiting. only with respect the .more general concept. in the intensional definition that contains the delimiting characteristic. 15) A Necessity has been added under .structural rule.. It is unclear. This was taken from the principles document discussed in London. To provide a answer I need specific questions about clarity. 16) The first Note under .structural rule. is unclear. (And I do not recall we ever discussed giving something dealing with .continuous meaning over time.. Is that within our scope?) The second point was taken from the principles document. The first point (which is an alternative mother to the second point) comes from answers from the ISO terminology people. Please ask specific clarifying questions. 17) The 2nd Note under .structural role. is unclear. (Also, I do not recall agreeing it.) This is exactly the same note as referenced in item 11 above. Donald ~~~~~~~~ I will continue to work on the consolidated diagram and, if I am able to produce something useful, will send it off for tomorrow.s meeting. ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 11 Aug 2006 07:30:56 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- what is "agreement"? From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- what is "agreement"? Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RAAWTcBgAACJUQs= Donald, One of my biggest problems with this material is that you continue to assert that there is .agreement. when what we have had (and are having) is .discussion.. Indeed, we have gone over the Architectural Principles document, in London and in post-London telcons. But I (and I assume others) are far from grasping, much less .agreeing to., its content. For a specific point, in the meeting of Aug. 3 we were in discussion on a critical point of disconnect between Don and you on .chasing the taxonomy. of characteristic inheritance -- and we were working from the A.P. document. I expected to have that discussion continue and reach resolution. Then a set of edit instructions appeared. I don.t know how that under-discussion point was resolved, if at all. So please ... let.s slow down and get this right. I agree with you that this is critical material. I also suspect that I will agree with where it is going, when it gets there. But at this stage, I am mostly clueless, and therefore cautious. ~ Keri On 8/11/06 7:17 AM, "Donald Chapin" wrote: See .Concepts about Characteristics. diagram. We agreed there could be multiple .sufficient characteristic sets. in the intension of one concept. The multiple .essential characteristic sets. follow directly based on the definition of .essential characteristic.. ... 8) What does the Note under .essential characteristic set. mean? (And did we agree this?) It.s from the principles document gone over in detail in London and included in the meeting notes. It says there are three ways to write down what is in an essential characteristic set. User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 11 Aug 2006 11:54:17 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Small business example of Chr-Sets and Characteristics for a Concept From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Small business example of Chr-Sets and Characteristics for a Concept Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CEAAHh4MAACRO5EAArgIjg= On 8/11/06 6:42 AM, "John and Keri" wrote: > Donald & Team, For our discussion... > > Attached is a (first-cut) diagram reflecting Issue 9613. > > ~ Keri > file: ViewPer9613-a.jpg In today's meeting I requested a *small* example (that a 'business' person could relate to) that could be used to illustrate a correct understanding of this proposal and how it would be applied to a specific set of instances. As requested in London, I am providing the example that we started there (which originated with Patrick and which I elaborated upon - ref. flipchart 060617-01). Short intro.: The context is a "Game Park" (GP) that has (due to its limited, startup funding) a small number of animals and plants. It gives tours and teaches children how to recognize plants and animals (limited to those that it has in the Park). Vocabulary-defined characteristics (assume adequate definition for each): * is alive * has locomotion capacity * has a long nose * is large * is grey * is orange (etc. - other colors) Concepts, with applicable characteristics in list form: > thing (the top of the taxonomy) > living thing * being a thing (chr. for its 'more general concept') * is alive > animal * being a living thing (chr. for its 'more general concept') * has locomotion capacity > plant * being a living thing (chr. for its 'more general concept') * has not locomotion capacity > elephant * being an animal (chr. for its 'more general concept') * has a long nose * is large * is grey [the other animals ... omitted here] ~~~~~~~~~~~~~~~~ In the world of the GP, when a child encounters 'a thing' she can correctly identify it as an elephant in one of two ways: 1) that it is an animal (by determining that it is a living thing and that it has locomotion capacity) and then that it has a long nose. I.e., the only animal in the GP with a large nose is an elephant. 2) that it is an animal (by determining that it is a living thing and that it has locomotion capacity) and then that it is large and it is grey. I.e., there are other animals in the GP that are large; there are others that are grey. But only an elephant is large and grey. =============================== Please correct any of the following that are mis-statements (i.e., anything that does not reflect an accurate understanding of the model): A) If I ask, "how many characteristics are incorporated into the concept 'elephant'?" the answer is "4", namely: > being an animal (its more general concept) > having a long nose > being large > being grey B) All four of these characteristics are in the 'necessary characteristic set' of the concept 'elephant' -- i.e., for a thing to be an elephant it must have all 4 of these properties. C) The concept 'elephant' has only one necessary characteristic set. D) The concept 'elephant' has 2 sufficient characteristic sets: [1] The sufficient characteristic set (VT) that includes these two characteristics of elephant: > being an animal > having a long nose [2] The sufficient characteristic set (VG) that includes these three characteristics of elephant: > being an animal > being large > being grey ================================= Before I explore more of the model, is this correct, so far? ~ Keri To: sbvr-ftf@omg.org Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Wed, 9 Aug 2006 13:00:16 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/09/2006 13:00:17, Serialize complete at 08/09/2006 13:00:17 [Sorry, my keyboard went wild and a previous version of this got sent out by accident.] I happened to re-read section F.2 this morning, and noticed that the best practices suggested there are quite opposed to the principles proposed in issue 9613. F.2 argues for: "1. 'Essence by Definitions ...' "2. 'Boundaries by Rules: All constraints should be expressed as rules separate from definitions. ...' I realize that section F is not normative, and also that #9613 allows for using structural rules to define characteristics. Nevertheless, 9613 definitely seems to "slant" the spec the opposite way from section F. When I think about the definitions of sufficient characteristic and sufficient characteristic set, I'm not convinced they capture what is intended. If I say that "a car is a vehicle that has 4 wheels and primarily carries passengers and weighs less than 1 ton" then the set of {4 wheels, primarily carries passengers, weighs < 1 ton} jointly are sufficient. But the individual characteristics are not sufficient. So therefore they do not constitute a sufficient characteristic set according to 9613. Editing comments. In particular, some of the definitions and rules in 9613 don't conform to the Structured English of annex C. * "There is possibly" in necessity rule of "sufficient characteristic" and elsewhere. * "and/or" in definition of "necessary characteristic" * "of a that" in the definition of "essential characteristic" * "make up" used as a verb in the definition of "intension" but not defined in a fact type * ditto for "in" in the definition of "necessary characteristic" * "equivalent if all of" and "either the same or equivalent" styled as keywords in the necessity rule of "intension" * The Note for "essential characteristic" references "Principle 25 (third prior principle)" * A reference to "term formulation good practice' -- which does not appear in the spec I don't understand the proposed "Implied Characteristic" caption: * The intro paragraph says an implied characteristic "is necessarily true, but not an essential characteristic." But the definition of both implied and essential characteristics says that they are necessary characteristic. Either the intro is wrong or a necessary characteristic is not necessarily true. At the very least, this is confusing. * The example given is confusing: (a) the definition doesn't match the normative definition; (b) according to the normative definition, an antecedent always has one antecedent. That makes "having exactly one antecedent" an essential characteristic of an implication, not an implied characteristic. * Why not use a "Possibility" caption to indicate implied characteristics. For example: rental car has sun roof Possibility: rental car has zero or one sun roof Overall, I find both the definitions and explanations of most of this very hard to understand. I think a push to simplify is really needed in order for anyone to make it effective in SBVR. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Date: Thu, 10 Aug 2006 11:44:04 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: Mark H Linehan CC: sbvr-ftf@omg.org Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing Principles Document and Characteristics Diagram for Definitions & Rules X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Mark, you wrote: I happened to re-read section F.2 this morning, and noticed that the best practices suggested there are quite opposed to the principles proposed in issue 9613. F.2 argues for: "1. 'Essence by Definitions ...' "2. 'Boundaries by Rules' The problem here is that some concepts and the distinctions among those concepts are fundamental to the business and require mutual understanding in the speech community. In those cases, the "essence" is the (exact) "intension" -- what this term includes and implies and what it does not include or imply. But many concepts in a vocabulary are much softer, in that using them as classifications for things or actions involves business judgement. So the essence is fuzzier, and business rules are used to set (and move!) the boundaries that involve judgements. For example, "criminal" is a person who has been convicted of a crime in a formal judicial process, while "racketeer" is someone who demonstrates a pattern of executing and/or supporting unlawful behaviors. In the first case, there is a "structural rule" (a Necessity) that specifies the essence of "criminal". In the second case, the definition doesn't come with any obvious criterion, but the Justice Department/Ministry will provide some guidelines or business rules that determine when they will prosecute an individual under that charge. And those rules may change with administrations/governments. The idea of the changes to clause 8 is to capture the concepts "essential" and "intension" clearly. The idea of Annex F (in the text you cited) is to provide guidance in distinguishing the well-defined criteria from the judgemental criteria. The fundamental idea is that if the well-defined criteria change, the term has a different meaning (!), and the community has to agree to that (or understand that they are bound by it). But if the judgemental criteria change, the meaning of the term doesn't really change, but the active guidelines/rules for making the judgements change. Further, one can make a business decision that violates a judgemental rule, and may involve some issue of review and enforcement. One cannot make a business decision that violates a structural rule. (Per Ben Franklin, you can call a steer a bull, and he may be flattered, but it doesn't change his situation -- he would much rather have that which entitles him to the designation.) And of course, the criteria for which rules are which are not always well-defined; some of them are judgemental! -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: RE: [SBVR FTF] RE: issue 9613 -- view of 'London' elements Date: Mon, 14 Aug 2006 13:10:44 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [SBVR FTF] RE: issue 9613 -- view of 'London' elements Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CEAAHh4MAACRO5EAGU941QAPb+lcA== From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 14 Aug 2006 20:10:45.0403 (UTC) FILETIME=[B9E3CEB0:01C6BFDD] I just found a document I first prepared during the London meeting which defines a fact type we agreed upon in London. I think it has wording we discussed in the meeting, and also a Necessity. I should have sent out the document right after the London meeting. I just added a diagram showing how the new fact type fits into Figure 8.2. I also added 'intension' to the diagram because I believe we all agree it is a fundamental idea that we adopt from ISO. I can add the text for 'intension' if people want to move forward on this material. Keri's diagram has several problems with putting terms for roles into boxes as if they were for categories. The concept 'intension' is a role of a characteristic set. A set of characteristics is intrinsically just a set of characteristics. It is in relation to a concept that it is an intension or that it sufficiently delimits the concept. Similarly, a characteristic is not 'implied' or 'essential' except in a role in relation to a set of characteristics or a definition. A characteristic could be delimiting in relation to one characteristic set and implied from another. Regards, Don -----Original Message----- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Sunday, August 13, 2006 7:02 AM To: SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- view of 'London' elements For discussion. As follow-up to the Aug. 11 telcon discussion, attached is a variation I have composed from the London notes & flipcharts. (Note: I did also reflect some things, e.g., 'implied characteristic', that I did not find in my 'London' notes but were in what Donald has supplied.) ~ Keri file: ViewPer9613-b.jpg Issue96131.doc Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics Date: Mon, 14 Aug 2006 21:20:17 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 thread-index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RAAWTcBgAACJUQsAor98wA== Keri, -------------------------------------------------------------------------------- On 11 August 2006 15:31 Keri wrote: For a specific point, in the meeting of Aug. 3 we were in discussion on a critical point of disconnect between Don and you on .chasing the taxonomy. of characteristic inheritance -- and we were working from the A.P. document. I expected to have that discussion continue and reach resolution. If I understand the subject you are referencing correctly, it is about delimiting characteristics and the more general concept in an intensional definition and how they imply the essential characteristic set of the concept that has the intensional definition. The inheritance of all the delimiting characteristics in the generalization hierarchy of a concept as the set of its essential characteristics was adopted when .essential characteristic., .delimiting characteristic., and .intensional definition. were adopted from ISO. That this is part of their meaning has been verified with the ISO community. It is not clear to me why you perceive this as an open question. Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 14 Aug 2006 15:10:53 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RAAWTcBgAACJUQsAor98wAAEMJmQ On 11 August 2006 15:31 Keri wrote: For a specific point, in the meeting of Aug. 3 we were in discussion on a critical point of disconnect between Don and you on .chasing the taxonomy. of characteristic inheritance -- and we were working from the A.P. document. I expected to have that discussion continue and reach resolution. On 8/14/06 1:20 PM, "Donald Chapin" wrote: If I understand the subject you are referencing correctly, it is about delimiting characteristics and the more general concept in an intensional definition and how they imply the essential characteristic set of the concept that has the intensional definition. The inheritance of all the delimiting characteristics in the generalization hierarchy of a concept as the set of its essential characteristics was adopted when .essential characteristic., .delimiting characteristic., and .intensional definition. were adopted from ISO. That this is part of their meaning has been verified with the ISO community. It is not clear to me why you perceive this as an open question. Let.s see if I can give a concrete illustration (and thereby determine whether there is an open question or not). Using the example I sent a few days ago, how many characteristics are incorporated into the concept .elephant.? Are there 4? -- i.e., * being an animal (which is the chr. for its 'more general concept') * has a long nose * is large * is grey Are there 6? -- i.e., * being a thing (the most general 'more general concept' -- i.e., the .top.) * is alive (by virtue of being a living thing) * has locomotion capacity (by virtue of being an animal) * has a long nose * is large * is grey Where I thought we left things was that Don (and perhaps others) saw .4. -- the .concept as a unit of knowledge. statement -- and you (and perhaps others) saw .6.. Thanks, Keri Subject: RE: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics Date: Mon, 14 Aug 2006 16:03:25 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RAAWTcBgAACJUQsAor98wAAEMJmQAAGissA= From: "Baisley, Donald E" To: "John and Keri" , "Donald R. Chapin" , "SBVR-FTF" X-OriginalArrivalTime: 14 Aug 2006 23:03:26.0099 (UTC) FILETIME=[D9588E30:01C6BFF5] Hi Keri, Perhaps you can produce a more clear example and include a definition. Are you questioning whether the intension of a concept includes characteristics that are inherent in the characteristics and general concept given explicitly in a definition? Of course they are. If .has a long nose. is in the intension, then so is .has a nose.. I don.t imagine Donald disagrees. Enjoy, Don -------------------------------------------------------------------------------- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Monday, August 14, 2006 3:11 PM To: Donald R. Chapin; SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics On 11 August 2006 15:31 Keri wrote: For a specific point, in the meeting of Aug. 3 we were in discussion on a critical point of disconnect between Don and you on .chasing the taxonomy. of characteristic inheritance -- and we were working from the A.P. document. I expected to have that discussion continue and reach resolution. On 8/14/06 1:20 PM, "Donald Chapin" wrote: If I understand the subject you are referencing correctly, it is about delimiting characteristics and the more general concept in an intensional definition and how they imply the essential characteristic set of the concept that has the intensional definition. The inheritance of all the delimiting characteristics in the generalization hierarchy of a concept as the set of its essential characteristics was adopted when .essential characteristic., .delimiting characteristic., and .intensional definition. were adopted from ISO. That this is part of their meaning has been verified with the ISO community. It is not clear to me why you perceive this as an open question. Let.s see if I can give a concrete illustration (and thereby determine whether there is an open question or not). Using the example I sent a few days ago, how many characteristics are incorporated into the concept .elephant.? Are there 4? -- i.e., * being an animal (which is the chr. for its 'more general concept') * has a long nose * is large * is grey Are there 6? -- i.e., * being a thing (the most general 'more general concept' -- i.e., the .top.) * is alive (by virtue of being a living thing) * has locomotion capacity (by virtue of being an animal) * has a long nose * is large * is grey Where I thought we left things was that Don (and perhaps others) saw .4. -- the .concept as a unit of knowledge. statement -- and you (and perhaps others) saw .6.. Thanks, Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 14 Aug 2006 19:43:29 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics From: John and Keri To: Don Baisley , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RAAWTcBgAACJUQsAor98wAAEMJmQAAGissAAB+KKYg== Don, To the question you.ve asked, the answer is .no.. The heart of this question is two-fold: 1) For a given concept, is being of the more general concept considered to be one of the characteristics that is incorporated into that concept? In the Game Park example, for the concept .elephant. the more general concept is .animal. -- so, for the concept .elephant., is being of the more general concept .animal. considered to be one of the characteristics of .elephant.? (I have heard both answers . yes, it is a characteristic, and no, it is something else ... not a characteristic.) 2) Are the characteristics of all the more general concepts (i.e., up the taxonomy hierarchy) of a concept considered to be characteristics incorporated into the concept in question? How this is counted depends on the answer to (1) but in one variation there would be 6 -- a count that includes the 3 .inherited. characteristics and omits the more general concept as a characteristic, except at the .top. of the hierarchy. (Again, I have heard both interpretations.) The reason I.ve not (yet) provided a .definition. is because, as I understand this exercise, we need to come to agreement on the meaning elements. .Definition. is on the representation side (and, it is argued, only one of the alternatives for presenting the meaning). ~ Keri On 8/14/06 4:03 PM, "Baisley, Donald E" wrote: Hi Keri, Perhaps you can produce a more clear example and include a definition. Are you questioning whether the intension of a concept includes characteristics that are inherent in the characteristics and general concept given explicitly in a definition? Of course they are. If .has a long nose. is in the intension, then so is .has a nose.. I don.t imagine Donald disagrees. Enjoy, Don -------------------------------------------------------------------------------- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Monday, August 14, 2006 3:11 PM To: Donald R. Chapin; SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics On 11 August 2006 15:31 Keri wrote: For a specific point, in the meeting of Aug. 3 we were in discussion on a critical point of disconnect between Don and you on .chasing the taxonomy. of characteristic inheritance -- and we were working from the A.P. document. I expected to have that discussion continue and reach resolution. On 8/14/06 1:20 PM, "Donald Chapin" wrote: If I understand the subject you are referencing correctly, it is about delimiting characteristics and the more general concept in an intensional definition and how they imply the essential characteristic set of the concept that has the intensional definition. The inheritance of all the delimiting characteristics in the generalization hierarchy of a concept as the set of its essential characteristics was adopted when .essential characteristic., .delimiting characteristic., and .intensional definition. were adopted from ISO. That this is part of their meaning has been verified with the ISO community. It is not clear to me why you perceive this as an open question. Let.s see if I can give a concrete illustration (and thereby determine whether there is an open question or not). Using the example I sent a few days ago, how many characteristics are incorporated into the concept .elephant.? Are there 4? -- i.e., * being an animal (which is the chr. for its 'more general concept') * has a long nose * is large * is grey Are there 6? -- i.e., * being a thing (the most general 'more general concept' -- i.e., the .top.) * is alive (by virtue of being a living thing) * has locomotion capacity (by virtue of being an animal) * has a long nose * is large * is grey Where I thought we left things was that Don (and perhaps others) saw .4. -- the .concept as a unit of knowledge. statement -- and you (and perhaps others) saw .6.. Thanks, Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 15 Aug 2006 07:53:55 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- holistic view of concept and characteristic From: John and Keri To: SBVR-FTF , Don Baisley Thread-Topic: [SBVR FTF] RE: issue 9613 -- holistic view of concept and characteristic Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CEAAHh4MAACRO5EAGU941QAPb+lcAAop/gz On 8/14/06 1:10 PM, "Baisley, Donald E" wrote: > I just found a document I first prepared during the London meeting which > defines a fact type we agreed upon in London. I think it has wording we > discussed in the meeting, and also a Necessity. ... Thanks, Don. Your diagram is a close match to my notes. (Flipchart 3 had two Necessities.) > Keri's diagram has several problems with putting terms for roles into > boxes as if they were for categories. ... I was applying one of our legal conventions per our Profile. Since this is a 'discussion document' it helps to have as many concepts clearly laid out as possible/practicable. Once we have agreement we can address which can be shown more compactly. However, from your feedback I have spotted that some additional concepts should be shown as 'roles' and I have incorporated that into the attached version. Thanks for the input. As I pointed out in my earlier note, this diagram builds on the London ideas but also includes the whole picture of 'concept & characteristic' elements from SBVR -- a 'holistic' view was requested. Here are the major points that this diagram reflects: * All the characteristics are roles; it is the **characteristic set** that is for one particular concept. * One of the characteristic sets of a concept is a set of that concept's 'necessary' characteristics. Each concept only has one such set, which plays the role of that concept's intension. * A concept may have several 'sufficient' characteristic sets. A sufficient characteristic set is composed of characteristics that are, first, 'necessary, for the concept. The characteristics that are 'necessary' but omitted from a given sufficient set are 'implied' from the perspective of that sufficient set. I.e., they "follow on" from the sufficient set (which was the informal language we used in London). * On the expression side, we have 'intensional definition', which is one of the ways to represent the meaning of a concept. Per ISO, that form of representation reflects two things: a superordinate concept of the concept being defined, plus wording that expresses the characteristics in one of that concept's sufficient sets. I.e., that set is "delimiting" vis-à-vis the stated more general concept. * The 'essential' characteristics of a concept are all the 'inherited' characteristics up the taxonomy tree of that concept -- i.e., following the chain of the concept's exploded 'more general concept' lineage (parent, grandparent, etc.). But, to emphasize, this is a 'discussion document' -- and it is NOT my particular, personal view -- it is what I am hearing from the 'majority'. cheers, ~ Keri file: ViewPer9613-e.jpg ViewPer9613-e.jpg Subject: RE: [SBVR FTF] RE: issue 9613 -- Inheriting DelimitingCharacteristics as Essential Characteristics Date: Tue, 15 Aug 2006 11:01:29 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SBVR FTF] RE: issue 9613 -- Inheriting DelimitingCharacteristics as Essential Characteristics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RAAWTcBgAACJUQsAor98wAAEMJmQAAGissAAB+KKYgAf3xIA From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 15 Aug 2006 18:01:29.0838 (UTC) FILETIME=[D5A040E0:01C6C094] Keri, 1. Yes. The characteristic .is an animal. is incorporated into the concept .elephant.. 2. Yes. The characteristic .moves independently. is incorporated into the concept .elephant. because it is inherent in the characteristic .is an animal.. Enjoy, Don -------------------------------------------------------------------------------- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Monday, August 14, 2006 7:43 PM To: Baisley, Donald E; SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- Inheriting DelimitingCharacteristics as Essential Characteristics Don, To the question you.ve asked, the answer is .no.. The heart of this question is two-fold: 1) For a given concept, is being of the more general concept considered to be one of the characteristics that is incorporated into that concept? In the Game Park example, for the concept .elephant. the more general concept is .animal. -- so, for the concept .elephant., is being of the more general concept .animal. considered to be one of the characteristics of .elephant.? (I have heard both answers . yes, it is a characteristic, and no, it is something else ... not a characteristic.) 2) Are the characteristics of all the more general concepts (i.e., up the taxonomy hierarchy) of a concept considered to be characteristics incorporated into the concept in question? How this is counted depends on the answer to (1) but in one variation there would be 6 -- a count that includes the 3 .inherited. characteristics and omits the more general concept as a characteristic, except at the .top. of the hierarchy. (Again, I have heard both interpretations.) The reason I.ve not (yet) provided a .definition. is because, as I understand this exercise, we need to come to agreement on the meaning elements. .Definition. is on the representation side (and, it is argued, only one of the alternatives for presenting the meaning). ~ Keri On 8/14/06 4:03 PM, "Baisley, Donald E" wrote: Hi Keri, Perhaps you can produce a more clear example and include a definition. Are you questioning whether the intension of a concept includes characteristics that are inherent in the characteristics and general concept given explicitly in a definition? Of course they are. If .has a long nose. is in the intension, then so is .has a nose.. I don.t imagine Donald disagrees. Enjoy, Don -------------------------------------------------------------------------------- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Monday, August 14, 2006 3:11 PM To: Donald R. Chapin; SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics On 11 August 2006 15:31 Keri wrote: For a specific point, in the meeting of Aug. 3 we were in discussion on a critical point of disconnect between Don and you on .chasing the taxonomy. of characteristic inheritance -- and we were working from the A.P. document. I expected to have that discussion continue and reach resolution. On 8/14/06 1:20 PM, "Donald Chapin" wrote: If I understand the subject you are referencing correctly, it is about delimiting characteristics and the more general concept in an intensional definition and how they imply the essential characteristic set of the concept that has the intensional definition. The inheritance of all the delimiting characteristics in the generalization hierarchy of a concept as the set of its essential characteristics was adopted when .essential characteristic., .delimiting characteristic., and .intensional definition. were adopted from ISO. That this is part of their meaning has been verified with the ISO community. It is not clear to me why you perceive this as an open question. Let.s see if I can give a concrete illustration (and thereby determine whether there is an open question or not). Using the example I sent a few days ago, how many characteristics are incorporated into the concept .elephant.? Are there 4? -- i.e., * being an animal (which is the chr. for its 'more general concept') * has a long nose * is large * is grey Are there 6? -- i.e., * being a thing (the most general 'more general concept' -- i.e., the .top.) * is alive (by virtue of being a living thing) * has locomotion capacity (by virtue of being an animal) * has a long nose * is large * is grey Where I thought we left things was that Don (and perhaps others) saw .4. -- the .concept as a unit of knowledge. statement -- and you (and perhaps others) saw .6.. Thanks, Keri Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR FTF] RE: issue 9613 -- Inheriting Delimiting Characteristics as Essential Characteristics Date: Tue, 15 Aug 2006 20:33:15 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 thread-index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1AAUoI3RAAWTcBgAACJUQsAor98wAAEMJmQAAGissAAB+KKYgAiQpGg Keri, I have created a diagram for characteristics showing their nature with respect to .sufficient. and .necessary.. It is based on Ed B.s email which quotes the standard logic and math understanding of .necessary and .sufficient.. Hopefully that will help to put the ideas together into a pattern. Please see responses below. Donald -------------------------------------------------------------------------------- On 15 August 2006 03:43 Keri wrote: The heart of this question is two-fold: 1) For a given concept, is being of the more general concept considered to be one of the characteristics that is incorporated into that concept? In the Game Park example, for the concept .elephant. the more general concept is .animal. -- so, for the concept .elephant., is being of the more general concept .animal. considered to be one of the characteristics of .elephant.? (I have heard both answers . yes, it is a characteristic, and no, it is something else ... not a characteristic.) To get a consistent answer the question needs to be more specific; i.e. It is an essential characteristic of .elephant.? Is it an implied characteristic of elephant? Is it an implied characteristic of elephant? Yes. It is an essential characteristic of .elephant.? No. The essential characteristic set for .elephant. is the set of all the delimiting characteristics in each intensional definition all the way up the .more general concept. hierarchy until you get to a concept that is a top level concept. 2) Are the characteristics of all the more general concepts (i.e., up the taxonomy hierarchy) of a concept considered to be characteristics incorporated into the concept in question? How this is counted depends on the answer to (1) but in one variation there would be 6 -- a count that includes the 3 .inherited. characteristics and omits the more general concept as a characteristic, except at the .top. of the hierarchy. (Again, I have heard both interpretations.) The reason I.ve not (yet) provided a .definition. is because, as I understand this exercise, we need to come to agreement on the meaning elements. .Definition. is on the representation side (and, it is argued, only one of the alternatives for presenting the meaning). Again, I think the question needs to be more specific as to .essential. or implied.. In ISO 1087 essential characteristics work in a very specific way with respect to intensional definitions. How Necessary & Sufficienbt Work.ppt User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 15 Aug 2006 14:13:09 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- view of 'London' elements From: John and Keri To: Don Baisley , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- view of 'London' elements Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CEAAHh4MAACRO5EAGU941QAPb+lcAA15pVW On 8/14/06 1:10 PM, "Baisley, Donald E" wrote: > I just found a document I first prepared during the London meeting which > defines a fact type we agreed upon in London. ... Hi, Don, Re. the 'Resolution' document that you sent yesterday. Issue 9613 has two main components and your write-up only covers the first -- namely, improving on the SBVR concepts and terminology for 'characteristic' and (in particular) how 'characteristic' relates to 'concept'. The rest of this Issue relies on our having a consensus on these items so that we can have a meaningful ('shared understanding') dialog on the second part. The second component (which is the "architectural" thrust of this Issue) covers the desire to confirm that, for practice and tooling that needs to do so, SBVR can be applied to vocabulary development (i.e., compose a body of definitions) without relying on any concepts/terminology from Clause 12. In other words, visualize this as "SBV" ("SBVR" minus the "R"). ~ Keri Reply-To: From: "Donald Chapin" To: Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution v3 Date: Tue, 15 Aug 2006 22:45:57 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 thread-index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUA== Attached is a major update to the Issue 9613 Resolution document. Over the weekend I incorporated all the fixes and feedback on the Issue 9613 Resolution document that I received from Ed, Keri, Ron, et al. Also the editing instructions have been re-sequenced into the order of the SBVR Interim Specification. This is the version I sent to Ed Barkmeyer on Monday. I wanted to make it as easy as possible for him to make any changes he felt were needed. Since he has not had time to edit this yet, I thought I should make it available to everyone the day before tomorrow's telecon. The examples are still being worked on and will follow as soon as possible. Donald P.S. This is the version Neumont University reviewed (see other email) > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 09 August 2006 13:21 > To: 'sbvr-ftf@omg.org' > Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing > Principles Document and Characteristics Diagram for Definitions & Rules > > > Attached is the Issue Resolution for Issue 9613 with editing instructions > that implement the "SBVR Architectural Principles for Definitions & Rules" > document and the "Concepts about Characteristics" diagram. > > Donald > > > > -----Original Message----- > > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > > Sent: 07 August 2006 21:06 > > To: 'sbvr-ftf@omg.org' > > Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles Document > > and Diagram for Definitions & Rules > > > > > > Team -- > > > > I have updated the "SBVR Architectural Principles for Definitions & > Rules" > > document and the "Concepts about Characteristics" diagram to bring them > in > > line with the input from Ed Barkmeyer and the ISO Terminology community > > and with our discussion last Wednesday. > > > > Tomorrow I plan to finish the Issue 9613 Issue Resolution document > > containing the editing instructions for discussion on Wednesday. > > > > Donald Issue9613-v3.doc Reply-To: From: "Donald Chapin" To: Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution v3 -- Neumont University Review Date: Tue, 15 Aug 2006 22:48:18 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 thread-index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAAZoTg Answer from Neumont University as promised. Donald > -----Original Message----- > From: Andy Carver [mailto:Andy.Carver@neumont.edu] > Sent: 15 August 2006 18:04 > To: Donald.Chapin@btinternet.com; Tony Morgan; Terry Halpin > Subject: RE: Verification if SBVR Issue Resolution Revisions > > Hi Donald, > > Tony and I both did a quick read of this document and didn't notice any > problem. However, a deeper examination would take more time than is > available to us right now. Terry is swamped with critical deadlines and > could not possibly look at it this week. > > Regards, > Andy > > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: Monday, August 14, 2006 11:00 AM > To: Tony Morgan; Terry Halpin; Andy Carver > Subject: Verification if SBVR Issue Resolution Revisions > > > > Tony, Terry & Andy, > > The SBVR FTF has asked me to check with you specifically to see if you > have any problems with these revisions to SBVR to properly integrate > structural rules and definitions, and provide clarifications for some of > the ISO terms based on input from them when I was in Vienna. > > Please let me know as soon as possible as we are hoping to finalize this > on Wednesday. > > Ed Barkmeyer is reviewing it today also. > > Many Thanks, > > Donald > > > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 15 August 2006 22:46 > To: 'sbvr-ftf@omg.org' > Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution v3 > > > Attached is a major update to the Issue 9613 Resolution document. > > Over the weekend I incorporated all the fixes and feedback on the Issue > 9613 Resolution document that I received from Ed, Keri, Ron, et al. > > Also the editing instructions have been re-sequenced into the order of the > SBVR Interim Specification. > > This is the version I sent to Ed Barkmeyer on Monday. I wanted to make it > as easy as possible for him to make any changes he felt were needed. > > Since he has not had time to edit this yet, I thought I should make it > available to everyone the day before tomorrow's telecon. > > The examples are still being worked on and will follow as soon as > possible. > > Donald X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 15 Aug 2006 17:28:13 -0500 To: , From: "Ronald G. Ross" Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution v3 -- Neumont University Review At 04:48 PM 8/15/2006, Donald Chapin wrote: Answer from Neumont University as promised. I am not comfortable with moving ahead on this until Neumont in general, and Terry in particular, has had time for a 'deep review'. What suddenly is the hurry? Since these new ideas go right to the heart of "concept" and "definition" (not to mention "rule") it is simply imprudent to move forward without it. This is in the interest of everyone. Ron Donald > -----Original Message----- > From: Andy Carver [mailto:Andy.Carver@neumont.edu] > Sent: 15 August 2006 18:04 > To: Donald.Chapin@btinternet.com; Tony Morgan; Terry Halpin > Subject: RE: Verification if SBVR Issue Resolution Revisions > > Hi Donald, > > Tony and I both did a quick read of this document and didn't notice any > problem. However, a deeper examination would take more time than is > available to us right now. Terry is swamped with critical deadlines and > could not possibly look at it this week. > > Regards, > Andy > > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: Monday, August 14, 2006 11:00 AM > To: Tony Morgan; Terry Halpin; Andy Carver > Subject: Verification if SBVR Issue Resolution Revisions > > > > Tony, Terry & Andy, > > The SBVR FTF has asked me to check with you specifically to see if you > have any problems with these revisions to SBVR to properly integrate > structural rules and definitions, and provide clarifications for some of > the ISO terms based on input from them when I was in Vienna. > > Please let me know as soon as possible as we are hoping to finalize this > on Wednesday. > > Ed Barkmeyer is reviewing it today also. > > Many Thanks, > > Donald > > > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 15 August 2006 22:46 > To: 'sbvr-ftf@omg.org' > Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution v3 > > > Attached is a major update to the Issue 9613 Resolution document. > > Over the weekend I incorporated all the fixes and feedback on the Issue > 9613 Resolution document that I received from Ed, Keri, Ron, et al. > > Also the editing instructions have been re-sequenced into the order of the > SBVR Interim Specification. > > This is the version I sent to Ed Barkmeyer on Monday. I wanted to make it > as easy as possible for him to make any changes he felt were needed. > > Since he has not had time to edit this yet, I thought I should make it > available to everyone the day before tomorrow's telecon. > > The examples are still being worked on and will follow as soon as > possible. > > Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 15 Aug 2006 22:29:09 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Issue Resolution v3 From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Issue Resolution v3 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAQkZI3 On 8/15/06 2:45 PM, "Donald Chapin" wrote: > Attached is a major update to the Issue 9613 Resolution document. > ... Donald, Thanks for making these extensive changes. The one thing lacking is a diagram that will let us visualize an overall picture of these changes. In tomorrow's meeting could we refer to the diagram that I sent earlier (and attached again, here) to examine our understanding of this proposal? When we last left this dialog we agreed that we would work to "edit down" the big picture and this would be a way to do that. Thanks, Keri ViewPer9613-e1.jpg Reply-To: From: "Donald Chapin" To: Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution v4 - Examples Partly Complete Date: Wed, 16 Aug 2006 14:29:51 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 thread-index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxg Attached is version 4 of the Issue 9613 Resolution document with the examples for the first half of the document. The rest will follow. All changes from version 3 are changed tracked. Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 15 August 2006 22:46 > To: 'sbvr-ftf@omg.org' > Subject: RE: [SBVR FTF] RE: issue 9613 -- Issue Resolution v3 > > > Attached is a major update to the Issue 9613 Resolution document. > > Over the weekend I incorporated all the fixes and feedback on the Issue > 9613 Resolution document that I received from Ed, Keri, Ron, et al. > > Also the editing instructions have been re-sequenced into the order of the > SBVR Interim Specification. > > This is the version I sent to Ed Barkmeyer on Monday. I wanted to make it > as easy as possible for him to make any changes he felt were needed. > > Since he has not had time to edit this yet, I thought I should make it > available to everyone the day before tomorrow's telecon. > > The examples are still being worked on and will follow as soon as > possible. > > Donald > > > P.S. This is the version Neumont University reviewed (see other email) > > > > > -----Original Message----- > > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > > Sent: 09 August 2006 13:21 > > To: 'sbvr-ftf@omg.org' > > Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution Implementing > > Principles Document and Characteristics Diagram for Definitions & Rules > > > > > > Attached is the Issue Resolution for Issue 9613 with editing > instructions > > that implement the "SBVR Architectural Principles for Definitions & > Rules" > > document and the "Concepts about Characteristics" diagram. > > > > Donald > > > > > > > -----Original Message----- > > > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > > > Sent: 07 August 2006 21:06 > > > To: 'sbvr-ftf@omg.org' > > > Subject: RE: issue 9613 -- SBVR FTF issue - Updated Principles > Document > > > and Diagram for Definitions & Rules > > > > > > > > > Team -- > > > > > > I have updated the "SBVR Architectural Principles for Definitions & > > Rules" > > > document and the "Concepts about Characteristics" diagram to bring > them > > in > > > line with the input from Ed Barkmeyer and the ISO Terminology > community > > > and with our discussion last Wednesday. > > > > > > Tomorrow I plan to finish the Issue 9613 Issue Resolution document > > > containing the editing instructions for discussion on Wednesday. > > > > > > Donald Issue9613-v4.doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 16 Aug 2006 07:16:11 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- confusion in our dialog From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- confusion in our dialog Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAQkZI3ABJoDAE= X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k7GEGmEm004430 Donald, As I review the material (documents & notes) re. this Issue there are four aspects that continue the confusion. If we could take care in these it would aid in our communication. 1) mix of meaning and expression elements. For example, talking about 'structural rule' (or structural business rule) and 'definition' -- or 'characteristic' and 'definition'. The former elements (rule, characteristic) are items of meaning while the latter (definition, intensional definition) are expression. For a specific: "there are two ways to use structural business rule: for an entire Intensional definition or ..." 2) the raw characteristic (the unary fact type) vs. when we are talking about some role a characteristic might plays vis-à-vis some concept For example, on your recent, clarifying PPT drawing, it has many places where it shows 'characteristic'. Is this really talking about a unary fact type or does it intend for us to understand some role of a characteristic vis-à-vis some concept? 3) Overqualification. We talk about "necessary characteristic" (vis-à-vis a concept). But are not all 'incorporated into a concept' characteristics by definition 'necessary'? What would be an example of a not-necessary characteristic that is incorporated into a concept? 4) terminology. talking about "a characteristic of a concept" does not mean "a characteristic that is incorporated by a concept" (ref. a May note from Don). Yet these phrases appear to be used synonymously. Are they so intended? Thanks, ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 23 Aug 2006 06:08:32 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- consolidation/simplification of elements From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- consolidation/simplification of elements Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAQkZI3ABJoDAEBXa1ixg== In the last telcon, I remarked that there were "too many sets" in our proposed structures of characteristics. At the time of the meeting, I wasn't able to be more specific. I have added more detail ... and draw on some informal terminology that aided our long-ago dialog on 'segmentation'. ~~~ Concept-incorporates-characteristic -- we call that whole set of characteristics, for a concept, the 'intension' (and can refer to a characteristic in that set as a 'necessary characteristic'). This much was nicely clarified in the meeting. For the other sets/kinds of sets, I observed that we are being overly verbose. Referring to Donald's most recent .ppt sketch, this is what appears to be emerging: Consider a concept that incorporates 14 characteristics (i.e., its intension is a set that is composed of 14 'necessary' characteristics). We can then also cut that pie of 14 characteristics in multiple ways. Each way we cut the pie-of-14 yields a characteristic set that is 'sufficient' for that same concept. A characteristic that is in that set is termed 'essential'. And, from the perspective of that set, the left-over characteristics from the pie-of-14 are what we are terming 'implied'. So, if we cut the pie-of-14 so that we have a sufficient set of 5 essential characteristics then there are 9 implied characteristics that are relative to that sufficient set. And if we cut the pie-of-14 a second way -- say, as a sufficient set of 3 essential characteristics -- then there are 11 implied characteristics that are relative to THAT sufficient set. But we are always starting with whatever is the intension/set of necessary characteristics that are incorporated into the concept. Is this right? Does this make sense? If so, it would appear that we *only* need to focus on coming to consensus on the following concepts (and terms for them): * intension (aka 'necessary characteristic set', if that synonym is helpful) * necessary characteristic * sufficient characteristic set * essential characteristic * implied characteristic While it is possible to create terms for 'essential characteristic set' and 'implied characteristic set', doing so adds unnecessary 'noise' to our concept base. ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 23 Aug 2006 18:38:20 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- a business example From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- a business example Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAQkZI3ABJoDAEBd90eAg== For discussion. As I was reworking the material for the 'actionable' Issue, I realized that we have a readily-available business example that can be used to exercise Issue 9613's concepts -- namely, 'business policy'. Using the following terminology with the understanding put forth in the last telcon, we can develop an initial cut at using 'business policy' to illustrate: o intension (aka 'necessary characteristic set') o necessary characteristic o sufficient characteristic set o essential characteristic o implied characteristic The following example illustrates (for 'business policy') one 'necessary characteristic set' (i.e., the 'intension') and two 'sufficient characteristic sets'. Necessary Characteristic Set / Intension (& each element is a 'necessary' characteristic) ================================================================ o being an element of governance o being an element of guidance o being a proposition o being a meaning o not being a business rule o not being an admonition o not being an affirmation o being not directly enforceable o being not practicable o possibly being the basis for one or more business rules o possibly being based on one or more fact types Sufficient Characteristic Set #1 (& each element is an 'essential' characteristic) ========================================================== o being an element of governance o being not directly enforceable ...and each of the remaining 'necessary' characteristics is an 'implied' characteristic (from the perspective of Sufficient Characteristic Set #1) o being an element of guidance o being a proposition o being a meaning o not being a business rule o not being an admonition o not being an affirmation o being not practicable o possibly being the basis for one or more business rules o possibly being based on one or more fact types Sufficient Characteristic Set #2 (& each element is an 'essential' characteristic) ========================================================== o being an element of guidance o not being a business rule o not being an admonition o not being an affirmation ...and each of the remaining 'necessary' characteristics is an 'implied' characteristic (from the perspective of Sufficient Characteristic Set #2) o being an element of governance o being a proposition o being a meaning o being not directly enforceable o being not practicable o possibly being the basis for one or more business rules o possibly being based on one or more fact types Comments? Corrections?? regards, Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sun, 13 Aug 2006 07:01:45 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- view of 'London' elements From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- view of 'London' elements Thread-Index: Aca86HPtXe5G2MkrTbyLz9zwKcLfzQAU/YCQAAEq7CEAAHh4MAACRO5EAGU941Q= For discussion. As follow-up to the Aug. 11 telcon discussion, attached is a variation I have composed from the London notes & flipcharts. (Note: I did also reflect some things, e.g., 'implied characteristic', that I did not find in my 'London' notes but were in what Donald has supplied.) ~ Keri file: ViewPer9613-b.jpg X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 25 Aug 2006 22:17:40 -0500 To: John and Keri , SBVR-FTF From: "Ronald G. Ross" Subject: Re: [SBVR] Issue 9477 and 9613 - as package elements At 07:40 AM 8/23/2006, John and Keri wrote: On 8/22/06 9:50 PM, "Donald Chapin" wrote: > Keri, > > I'm still hoping that we can put the Issue Resolution for the four packaged > Issues to a vote before the end of the week of Aug. 28 - Sept. 1. Donald, For your planning purposes ... I do not currently have any time available the week of Aug 28 - Sept. 1 to work on SBVR matters. My assessment is that you have introduced a raft of new material for issue 9613. It was not discussed or agreed in London. Based on SBVR history, it could take months to assimilate it all. I appreciate your endless optimism and energy, but we need to be realistic. I would discourage any notion of voting on this stuff. Ron Hmmm... From the perspective of 9613, that seems awfully optimistic. We are still working on coming to a common perspective on the terminology (the first 'component') and haven't even begun to review/grasp the architectural features of the second (the 'rule-less' SBVR component). > I have been told by the OMG that we have a little leeway on getting the SBVR > FTF Report by Monday, Sept 4th. > > It will be much better with the Architecture Board not to have to defer > these key Issues. It would also be better for progress and the morale of > the SBVR FTF team to have these four Issues behind us. But, of course, only with solid understanding and agreement. > In any case, we either have to vote on a Resolution or Deferral of these > four Issues before the SBVR FTF Report can be completed. > > If we can agree on an Issue Resolution, the page numbers will not need to be > changed. Thanks for confirming my understanding that the page numbers would need to be changed if deferred. ~ Keri DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:X-MimeOLE:In-Reply-To; b=cltujbuHhH2kUoq4Bvy46n7mzFMrE0ROaXcg0OVFYuQbNaIFbft+89CDmdbhOQ+Ze22ngyH5JlCQ+i8B/CPdzxRaOa7ac0esA/9IoT2i49aIL/w3d4JPyppmyOC8jJvptWzNRGBb1p/F/kBkMmTrc2cwVHp813D1iDFZ6vF07Zs= ; Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR] Issue 9477 and 9613 - as package elements Date: Sat, 26 Aug 2006 18:20:13 +0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbIvjxwAxw3+USjSY6mDsjyWRuEGwAOX8pQ Ron, On 26 August 2006 11:18 Ron Ross wrote: > >On 8/22/06 9:50 PM, "Donald Chapin" wrote: > > > I'm still hoping that we can put the Issue Resolution for the four > packaged > > > Issues to a vote before the end of the week of Aug. 28 - Sept. 1. > > Donald, > > For your planning purposes ... I do not currently have any > time available the week of Aug 28 - Sept. 1 to work on SBVR matters. > > My assessment is that you have introduced a raft of new > material for issue 9613. It was not discussed or agreed in London. > Based on SBVR history, it could take months to assimilate it all. > > I appreciate your endless optimism and energy, but we need > to be realistic. I would discourage any notion of voting on this stuff. I would remind you that everything in the draft Issue 9613 Resolution is a direct implementation of one or more principles in the "SBVR Architectural Principles for Definitions & Rules" document or in Ed Barkmeyer's email answering questions posed to him in that document. In the London meeting this document was discussed and revised on screen, principle for principle, with the group not moving to the next principle until there were no more changes to the current one. Donald DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:X-MimeOLE:In-Reply-To; b=Vzaal+j61nbXt/Ryu+6WIsqtHGh++SIsJDs5Vq1CfTYbs/VAtKm+4s13dHVCmSUHCJgiZNeGQUEdA3p6VLu61gzP1tmrO+EURx1qwryP+AR0pycjyG8xj0DxZ0V3XM8oE0ejfS0HfVzzas/e6zWb0Mj01ZCZPQfdkub6iwnqKgs= ; Reply-To: From: "Donald Chapin" To: Subject: RE: [SBVR FTF] RE: issue 9613 -- Draft Issue Resolution v5 - SIMPLIFIED Date: Sat, 26 Aug 2006 20:38:58 +0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3A= Attached is the updated Issue 9316 Resolution with an accompanying working diagram as promised. The major changes are: 1. Moved to Clause 10 as formal logic definitions - sufficient characteristic as 'sufficient' - necessary characteristic as 'necessary' 2. Dropped - sufficient characteristic set - essential characteristic set corresponds to sufficient characteristic set - intensional definition defines concept - structural rule applies to concept 3. Changed from category to role in fact type: - essential characteristic - essential characteristic set - implied characteristic 4. Replaced 'intension' in the definition of concept with 'essential characteristic set' based on - what Ed Barkmeyer said in Aug. 11 telecon about essential characteristic sets defining concepts (classes)in OWL - consultation with the ISO terminology people 5. Clarified the definition of implied characteristic to exclude any characteristic that is part of the essential characteristic set which implies the implied characteristic. 5. Made 'intension' the combination of 'essential characteristic set' and implied characteristic set' and changed "intension creates concept" to "intension makes up concept" 6. Dropped 'concept incorporates characteristic' as it is now redundant because it is covered by "characteristic is essential to concept" + "essential characteristic set sufficiently defining concept implies implied characteristic" and by "intension makes up concept" I believe I've dealt with all the input I've received except for the examples. Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 16 August 2006 14:30 > To: 'sbvr-ftf@omg.org' > Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution v4 - Examples > Partly Complete > > > Attached is version 4 of the Issue 9613 Resolution document with the > examples for the first half of the document. The rest will follow. > > All changes from version 3 are changed tracked. > > Donald Issue9613-v5.doc Issue 9613 Working Diagram v1.jpg User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 28 Aug 2006 11:37:10 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- back to basics From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- back to basics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qx I have attached two sketches. The first (ViewFor9613-A.jpg) is along the lines of the flipchart notes Don and I drew in London. It reflects the basics for 'intension' and 'extension', along with the ISO definitions that we originally drew on. The second (ViewFor9613-B.jpg) is a view of some entries that may be contributing to our confused conversation. Note how we use 'defines' and 'definition' and (especially) where things lie on the great meaning/representation divide. If we are trying to sort out what facilities we have on the 'left' side (i.e., to capture/structure/formulate a meaning) -- which seems to be at the heart of this Issue -- we need avoid dragging in elements of some wording, which comes into the picture when that meaning needs to be given a voice. hoping this helps, ~ Keri ViewFor9613-A.jpg ViewFor9613-B.jpg DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:In-Reply-To:Thread-Index; b=6R7GqyOVhfb48w+jkE5UtuWG1eH1mVmueY1h14Vgr7s3AcjqmfClmvqg8QQNhzRXzSzKgzpqeKSneHXy930JKK7bZi9ge9yR4mO+FYNFwsUeHHMZ0UmK3DkACUAdljoBJGKZyp//BAvUzybSDTZXGuv+TO0ftx9pgm570TkW7m4= ; Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR FTF] RE: issue 9613 -- back to basics Date: Wed, 30 Aug 2006 12:54:47 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAFRvWRA= Keri, You are right that it is good to get back to basics and build up from there. It is also very important to keep 'meaning' separate from 'representation'. Please see additional comments below. Donald On 28 August 2006 19:37 Keri wrote: > I have attached two sketches. > > The first (ViewFor9613-A.jpg) is along the lines of the flipchart notes > Don > and I drew in London. It reflects the basics for 'intension' and > 'extension', along with the ISO definitions that we originally drew on. The diagram does depict two fundamental parts of SBVR, but omits the ISO definition of 'concept'. Building on your diagram there are a few key points: 1. The fact type we agreed to add London (flip chart 060617-03) seems to be missing: - "'characteristic set' sufficient delimits 'concept'" Don made it very clear that this fact type was always for 'necessary and sufficient' (essential) characteristics in a recent SBVR FTF meeting. Unfortunately this fact type is incomplete as it does not show the critical role of 'characteristic'. Essential characteristic is defined by a characteristic being in a characteristic set that is related to a given concept by the "... sufficiently delimits ..." fact type. That is why I used a ternary fact type. Of course it can be done with two or three binary fact types plus some necessities, but this three-way relationship is so basic that I believe it is best for the sake of readers to depict it that way. However, I won't make an Issue over multiple binary fact types vs. one ternary fact type as long as the definitions and necessities are adequate. 2. The essential distinction in understanding what a concept is (i.e. whether two concepts are the same or different concepts; and whether changing a characteristic (or necessity) of a concept creates a different concept or just specifies a different implied characteristic of the same concept) is between 'essential' and 'implied' characteristics. This is why dealing with the two parts of the intension (essential characteristic set + implied characteristic set) is critical. The fact type "'concept' incorporates 'characteristic'" is ambiguous on this point and can also be derived (informally stated) from "'characteristic set' sufficient delimits 'concept'" and "'implied characteristic set' is implied by 'essential 'characteristic set'". That is why I removed it. To be able to know what a concept is we need to distinguish between 'essential characteristics' and 'implied characteristics' in every case. 3. In my draft diagram I used the same ternary fact type pattern for 'implied characteristic' that I did for 'essential characteristic' as it works in a similar ternary way. 4. The equivalence among 'characteristics' and 'essential characteristic sets' is necessary to be able to hold a conversation about whether two concepts are the same or different. Purposely there is no attempt to structure this enough for automated processing. There is just enough structure proposed to be able to have a reasonable conversation based on objective criteria. If we can come to a shared understanding on these basics, I believe that an acceptable solution will fall into place. > The second (ViewFor9613-B.jpg) is a view of some entries that may be > contributing to our confused conversation. Note how we use 'defines' and > 'definition' and (especially) where things lie on the great > meaning/representation divide. > > If we are trying to sort out what facilities we have on the 'left' side > (i.e., to capture/structure/formulate a meaning) -- which seems to be at > the > heart of this Issue -- we need avoid dragging in elements of some wording, > which comes into the picture when that meaning needs to be given a voice. Well done for spotting this "'closed proposition' defines 'concept'" fact type. It passed by my peripheral vision, but in all the time pressure I failed to focus on it as a central part of the definition vs. necessity (structural rule) question. The verb phrase 'defines' is very misleading based on the purpose and definition of this fact type and should be changed to something like: "'closed projection' formulates 'concept'" or "'closed projection' determines 'extension' of 'concept'" The wording of the definition is also inaccurate and need to be changed. It should read something like: "the closed projection formulates the essential characteristic set of the concept such that the result of the projection is the extension of the concept" User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 30 Aug 2006 06:39:58 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- back to basics From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- back to basics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAFRvWRAABcSwiA== On 8/30/06 4:54 AM, "Donald Chapin" wrote: > > If we can come to a shared understanding on these basics, I believe that an > acceptable solution will fall into place. > And we won't know that we have a shared understanding -- of the problem you are trying to solve or any of your proposed solutions -- until we have applied them to an example. Please refer to the example I sent out on Aug. 23 (subject line includes "a business example"). Thanks, Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 30 Aug 2006 06:57:47 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- back to basics From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- back to basics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAFRvWRAABmP7FA== On 8/30/06 4:54 AM, "Donald Chapin" wrote: > The diagram does depict two fundamental parts of SBVR, but omits the ISO > definition of 'concept'. > > Building on your diagram there are a few key points: > > 1. The fact type we agreed to add London (flip chart 060617-03) seems to > be missing: > > - "'characteristic set' sufficient delimits 'concept'" > > Don made it very clear that this fact type was always for 'necessary and > sufficient' (essential) characteristics in a recent SBVR FTF meeting. > > Unfortunately this fact type is incomplete as it does not show the critical > role of 'characteristic'. Essential characteristic is defined by a > characteristic being in a characteristic set that is related to a given > concept by the "... sufficiently delimits ..." fact type. > ... So, from your note, we have a beginning of a list of problems that we can explore, to see if they are indeed something that needs addressing in SBVR. And, if yes, then we can outline what an appropriate solution might be. In the above, I have captured that: 1) The ISO definition of 'concept' is omitted from (not supported in) SBVR. 2) SBVR is missing a needed fact type (characteristic set sufficient delimits concept) and the new concept (characteristic set). 3) The concept 'essential characteristic' does not work as it is currently defined. (with illustrations of what isn't right in the current material) Is this the kind of list you'll be compiling for us? Frankly, after the meeting two weeks ago I was expecting to see the questions/suggestions from that meeting expanded upon in your next draft. But what we got instead was a 'scrap and rewrite' -- something that people in the meeting (Ed, in particular) indicated that we shouldn't be doing. But if we are now open to going back to a re-do then it should begin with the Issue's problem statement itself. regards, ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 28 Aug 2006 10:25:10 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Draft Issue Resolution v5 - SIMPLIFIED From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Draft Issue Resolution v5 - SIMPLIFIED Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUA== Donald, I have spent much of yesterday and 3 hours today trying to make sense of this latest material. It has changed so much from what we last discussed, and has so many errors/questions (I was up to 34 when I gave up), that I suggest the following. We need to refocus on what the fundamental need is that we are attempting to address in this Issue. Then, we can explore whether we already have the elements in SBVR to do what is needed. As the Proposal currently reads there is still considerable jumping from the meaning side to the expression side, in a confusing melange of detail that obscures what the goal is. I sense that we still have considerable confusion in a very small set of concepts and terminology and, with some modest general improvements (such as were sketched on the London flipcharts) plus a couple of improved definitions, we will be able to do what you need to do. But first we all need to *understand*. Furthermore, to exercise our common, evolving understanding, I urge that we use one of our own, familiar SBVR concepts to apply these notions -- say, 'business policy', which provides a rich-enough mix of multiple characteristics and characteristic sets. After all, if we cannot apply this to our own work, what hope does the SBVR practitioner have? regards, ~ Keri On 8/26/06 5:38 AM, "Donald Chapin" wrote: > > Attached is the updated Issue 9316 Resolution with an accompanying working > diagram as promised. > > The major changes are: > > 1. Moved to Clause 10 as formal logic definitions > > - sufficient characteristic as 'sufficient' > - necessary characteristic as 'necessary' > > 2. Dropped > > - sufficient characteristic set > - essential characteristic set corresponds to sufficient > characteristic set > - intensional definition defines concept > - structural rule applies to concept > > 3. Changed from category to role in fact type: > > - essential characteristic > - essential characteristic set > - implied characteristic > > 4. Replaced 'intension' in the definition of concept with 'essential > characteristic set' based on > > - what Ed Barkmeyer said in Aug. 11 telecon about essential > characteristic sets defining concepts (classes)in OWL > > - consultation with the ISO terminology people > > 5. Clarified the definition of implied characteristic to exclude any > characteristic that is part of the essential characteristic set which > implies the implied characteristic. > > 5. Made 'intension' the combination of 'essential characteristic set' and > implied characteristic set' and changed "intension creates concept" to > "intension makes up concept" > > 6. Dropped 'concept incorporates characteristic' as it is now redundant > because it is covered by "characteristic is essential to concept" + > "essential characteristic set sufficiently defining concept implies implied > characteristic" and by "intension makes up concept" > > I believe I've dealt with all the input I've received except for the > examples. > > Donald > > >> -----Original Message----- >> From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] >> Sent: 16 August 2006 14:30 >> To: 'sbvr-ftf@omg.org' >> Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution v4 - Examples >> Partly Complete >> >> >> Attached is version 4 of the Issue 9613 Resolution document with the >> examples for the first half of the document. The rest will follow. >> >> All changes from version 3 are changed tracked. >> >> Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 31 Aug 2006 16:55:23 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- adjectives as entries for 'noun concepts' From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- adjectives as entries for 'noun concepts' Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3ABEz33OA== Donald, Another confusing point about the v.5 rework. In v.5 you have new entries for the terms 'necessary' and 'sufficient'. Yet vocabulary terms are for 'noun concepts' ... and these appear to be adjectives. Did you intend these to be for characteristics? i.e., "is necessary" and "is sufficient"? What motivated the shift in terminology/concept base from what we have been communicating with since London -- i.e., 'necessary characteristic', 'sufficient characteristic' (et al)? thanks, Keri DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:In-Reply-To:X-MimeOLE; b=UBmLaeapO6KIe859Dlqb4kV1u+g/2B+QnOAoY2AuUpXj4QMLKfbE/6EI5YXv5O6yKkKUOrNfuKkq23/trG4Kr2n7acKzc00+cqwbPhHuRY6pZB6TPt61VlYKxixTOIvtkeDrLYC0VAJBtx5Hk2QZaHDQDQyCO073dGRSkPpl1vI= ; Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR FTF] RE: issue 9613 -- adjectives as entries for 'noun concepts' Date: Wed, 13 Sep 2006 17:18:09 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3ABEz33OAJ9gopg Keri, You are right that, since SBVR does not current support adjectives, 'sufficient' and 'necessary' in Clause 10 need to be defined as the characteristics 'being sufficient' and 'being necessary'. That simplifies the definition in Clause 8 of - 'essential characteristic' to "characterisitc that is both necessary and sufficient" - 'necessary characterisitc' to "characterisitc that is necessary" Sorry I missed that. The motivation for putting the mathematical/logical definition in Clause 10 came from Ed B. as that is the pattern SBVR follows and it simplifies Clause 8. I don't think we really need 'sufficient characteristic' in Clause 8. By itself it is out of scope of the concerns of what concepts are. Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 01 September 2006 00:55 > To: SBVR-FTF > Subject: Re: [SBVR FTF] RE: issue 9613 -- adjectives as entries for 'noun > concepts' > > Donald, > > Another confusing point about the v.5 rework. > > In v.5 you have new entries for the terms 'necessary' and 'sufficient'. > Yet > vocabulary terms are for 'noun concepts' ... and these appear to be > adjectives. > > Did you intend these to be for characteristics? i.e., "is necessary" and > "is sufficient"? > > What motivated the shift in terminology/concept base from what we have > been > communicating with since London -- i.e., 'necessary characteristic', > 'sufficient characteristic' (et al)? > > thanks, > Keri > User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 01 Sep 2006 07:15:43 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- back to basics From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- back to basics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAMAI3yM= Donald, Here is the updated 'basics' view I promised, reflecting the concepts/terms we've been using and applying them to the diagram from the London meeting. regards, Keri file: ViewFor9613-C.jpg On 8/28/06 11:37 AM, "John and Keri" wrote: > I have attached two sketches. > > The first (ViewFor9613-A.jpg) is along the lines of the flipchart notes Don > and I drew in London. It reflects the basics for 'intension' and > 'extension', along with the ISO definitions that we originally drew on. > ... ViewFor9613-C.jpg DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:In-Reply-To:Thread-Index; b=x2R5OVrwQNoTUVY5UuIrJDFlc1DOtejnsODdFW2b7F96+X0EgyuZryv6VarlINIHhzW9qGuMxzqUumEH+RI21TvcH0U1rH0u0yoKq5vja/MI/jTaxJvTAaxfa5WvLsH2cQelxDAVviNY/Sf+cSntxAGtP+aN17yc5aIqBCl1I0E= ; Reply-To: From: "Donald Chapin" To: "'John and Keri'" , "'SBVR-FTF'" Subject: RE: [SBVR FTF] RE: issue 9613 -- back to basics Date: Fri, 1 Sep 2006 16:42:38 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAMAI3yMAAvJTwA== Keri, Thanks. It will almost certainly be the first part of next week before I can do anything more on 9613. The SBVR FTF Report is taking all my time right now and this weekend is my birthday so I don't plan to work. I'll get back to you on 9613 as soon as I can. Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 01 September 2006 15:16 > To: Donald R. Chapin; SBVR-FTF > Subject: Re: [SBVR FTF] RE: issue 9613 -- back to basics > > Donald, > > Here is the updated 'basics' view I promised, reflecting the > concepts/terms > we've been using and applying them to the diagram from the London meeting. > > regards, > Keri > file: ViewFor9613-C.jpg > > > On 8/28/06 11:37 AM, "John and Keri" > wrote: > > I have attached two sketches. > > > > The first (ViewFor9613-A.jpg) is along the lines of the flipchart notes > Don > > and I drew in London. It reflects the basics for 'intension' and > > 'extension', along with the ISO definitions that we originally drew on. > > ... User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 04 Sep 2006 09:36:48 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- back to basics From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- back to basics Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAMAI3yMAm80xKQ== Donald, Attached is an "applied view" write-up to accompany the diagram view that I sent earlier. (Note that I've corrected the diagram a bit from the 'C' version, with some things I spotted as I compiled the text.) It would be good if we use this to take a check-point, to see if we agree with the subset of concepts and fact types that this reflects -- and, of course, correct/clarify as needed. Once we have a small set of basics we can then elaborate with the rest of this Issue's points. ~ Keri file: Issue9613.1 (v.1).doc On 9/1/06 7:15 AM, "John and Keri" wrote: > Donald, > > Here is the updated 'basics' view I promised, reflecting the concepts/terms > we've been using and applying them to the diagram from the London meeting. > > regards, > Keri > file: ViewFor9613-C.jpg Issue9613.1 (v.1).doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 31 Aug 2006 16:36:56 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- change in what 'creates' a concept? From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- change in what 'creates' a concept? Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3ABEpkC2A== X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k7VNZftj010773 Donald, BACKGROUND: ~~~~~~~~~ ISO defines 'concept' as: unit of knowledge created by a unique combination of characteristics In your v.3 document, you had the 'concept' definition as: unit of knowledge created by a unique intension And 'intension' was a role of a set of characteristics -- those 'necessary' (i.e., the set of characteristics incorporated into/by the concept) In your v.5 document, you changed the definition of 'concept' to: unit of knowledge created by a unique essential characteristic set ~~~~~~~~~ QUESTION: Prior to v.5, we had been saying that each concept has exactly one intension (its set of 'necessary' characteristics) and possibly many 'essential' sets -- with each 'essential' set reflecting a more general concept plus those characteristics, drawn from the 'necessary' set, that are delimiting vis-à-vis the more general concept. And the rest (from that perspective) we were terming 'implied characteristics'. I am puzzled to see in v.5 that you have stopped using the notion of the singular 'intension' in the definition of 'concept' and shifted to be talking about one of the concept's possible, multiple characteristic sets. Can you clarify why you elected to move away from ISO's 'intension' in your new definition of 'concept'? thanks, Keri DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:In-Reply-To:X-MimeOLE; b=y45B7bMMZoszXQOvRWGg40ytF/y9SmfpTfZGPNECRGP871iUNtUC+UXQkH5XkPMD5Zzc1OC6PQS7PjctrTUqMXFDPGgyuzSdbDjkc9Yq+z6gVeJYl+wBuyeoPI5XvfymL4xceK/mijKqJOV3JcIjLvREU7a74UfzJVuFYdVPNHA= ; Reply-To: From: "Donald Chapin" To: "'John and Keri'" , "'SBVR-FTF'" Subject: RE: [SBVR FTF] RE: issue 9613 -- change in what 'creates' a concept? Date: Wed, 13 Sep 2006 18:44:47 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3ABEpkC2AJ+nxbw X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k8DHhDdc001510 Keri, The concept of a single intension for each concept remains intact in the "Issue9613-v5.doc". The singleness of intension is inherent in the idea of concept. Having said there is a single intension for each concept (which is true), the fact that not all implied characteristics are typically made explicit, nor do they need to be, means that there can appear to be different intensions of a given concept. This is caused by making different implied characteristics explicit over time, or in separate but equivalent concepts which have different implied characteristics made explicit (and which are the same concept if there are in the same body of shared meanings). The change in the definition of concept from version 4 - (1) "unit of knowledge created by a unique 'intension'" to version 5 - (2) "unit of knowledge created by a unique 'essential characteristic set'" was made because I wasn't thinking clearly enough when I wrote (1). That was brought to my attention by five events that occurred during or around the time of the August 30th SBVR telecon: - Ed B's comment that it is the necessary and sufficient characteristics that define the classes in OWL - Don B's comments/concerns over the fact that not all the implied characteristics in an intension are made explicit and therefore 'equivalent intensions' is a difficult thing to deal with - the actual words in the ISO definitions hit me with fresh impact: 'created by' vs. 'makes up' - an awareness dawned that essential characterisitc sets are always explicit, or at least explicitly specified indirectly in intensional definitions. Therefore they are a sound basis for establishing the identity of a concept and distinguishing between concepts. - another that I can't remember at the moment ... Thus the change in version 5 to (2) above. On 01 September 2006 00:37 Keri wrote: > BACKGROUND: > ~~~~~~~~~ > > ISO defines 'concept' as: > unit of knowledge created by a unique combination of characteristics > > In your v.3 document, you had the 'concept' definition as: > unit of knowledge created by a unique intension > And 'intension' was a role of a set of characteristics -- those > 'necessary' > (i.e., the set of characteristics incorporated into/by the concept) > > In your v.5 document, you changed the definition of 'concept' to: > unit of knowledge created by a unique essential characteristic set > > ~~~~~~~~~ > QUESTION: > > Prior to v.5, we had been saying that each concept has exactly one > intension > (its set of 'necessary' characteristics) and possibly many 'essential' > sets Yes, I agree that is what we have been saying during and since the London SBVR FTF meeting in June. > -- with each 'essential' set reflecting a more general concept plus those > characteristics, drawn from the 'necessary' set, that are delimiting > vis-à-vis the more general concept. This is not what ISO 1087-1 says and not what I and at least some of the others meant by what we said in London and since. An essential characteristic set of a concept is defined by ISO 1087-1 to be the set that includes the delimiting characteristics represented in one intensional definition for the concept, plus the delimiting characteristics of the more general concept represented in that intensional definition for the concept, and so on including the delimiting characteristics all the way to the top of the concept specialization hierarchy. Also essential characteristics in ISO 1087-1 are "necessary and sufficient" characteristics. For a given essential characteristic set there can be multiple concept specialization hierarchies each with their own structure of more general concepts and corresponding delimiting characteristics at each level of the hierarchy. However, separate from that there can be more than one essential characteristic set that creates a given concept. In this case the multiple essential characterisitc sets must be an 'equivalent set of essential characteristic sets' as defined in "Issue9613-v5.doc". By definition all (essential) characteristics in the essential characterisitc sets that create a concept are part of the intension of that concept. You are right that examples are essential here, but I can do only one thing at a time. I'll get to them. And the rest (from that perspective) > we > were terming 'implied characteristics'. 'Implied characteristics' are implied characteristics ONLY with respect to one essential characteristic set that creates the concept. Each such characterisitc must be either in all the other essential characteristic sets that create the concept or implied by all those essential characteristic sets it is not in. > I am puzzled to see in v.5 that you have stopped using the notion of the > singular 'intension' in the definition of 'concept' and shifted to be > talking about one of the concept's possible, multiple characteristic sets. The intension is still singular. It is the essential characterisitc sets that can be multiple. (see above) > Can you clarify why you elected to move away from ISO's 'intension' in > your > new definition of 'concept'? See the explanation of my initial error above. Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 18 Sep 2006 18:50:43 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- Checkpoint Definition of Remaining Problems From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- Checkpoint Definition of Remaining Problems Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3ADj942cABDEckQAM2T/TA= Thanks, Donald, Ed, and Don, for the discussion and additional detail. I have incorporated the dialog (as much as I could rationalize) into the first 3 discussion points. Attached are the revised discussion write-ups and diagrams. ~ Keri files: Issue9613.1 (v.2).doc Issue9613.2 (v.1).doc [unchanged] Issue9613.3 (v.2).doc Issue9613.1 (v.2).doc Issue96131.2 (v.1).doc Issue9613.3 (v.2).doc DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:In-Reply-To:X-MimeOLE; b=KY7nWsOTsDGt6uxLPnIAd0f5jiIfmYhBRLgOfv1ifl3XlV7i0IImas1oQU+2pZkL+2z9vpthq5WSAv1Y7N5ReeNX+J+11qsE+RfffSjGAINEfkmM5dAclIE3boKyvvUG0Oflfed02OA7t4HscoDDaUb43gdFx3VDzMDlBZhW1vQ= ; Reply-To: From: "Donald Chapin" To: Subject: RE: [SBVR FTF] RE: issue 9613 -- Checkpoint Definition of Remaining Problems Date: Wed, 13 Sep 2006 17:07:31 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3ADj942cA== Keri, You asked that I provide a sharply focused definition of the problems remaining under Issue 9613. There is one key problem with several contributing-cause problems. The bottom line problem is that SBVR does not yet provide an adequate objective set of criteria and accompanying language which can serve as the basis for a reasonable discussion among members of the same semantic community (or members of different semantic communities who need to identify equivalent concepts) that will regularly result in a adequate level of agreement as to whether or not: - two concepts are the same concept, or - incorporating one more or one less characteristic into a concept makes it a different concept. This is an absolutely critical problem. The whole claim of SBVR to provide the semantics (meaning) of business vocabulary and business rules stands or falls depending on whether or not this problem is solved. We know that the meaning of business rule statements and definitions is based on the meanings that are verb concepts. We also know that the meanings that are verb concepts are based on the meanings that are noun concepts. Thus the ability to consistently distinguish meanings that are noun concepts is the cornerstone of the whole edifice. The contributing-cause problems are as follows. 1. "'Concept' incorporates 'characteristic'" is ambiguous with respect to the relationship between the characteristics in the intension that makes up a concept that are part of each essential characteristic set that creates the concept, and those that are not. Since there can be many characteristics in the intension (necessary characterisitc set) of a concept that are not, and do not need to be made, explicit in an SBVR vocabulary, "'concept' incorporates 'characteristic'" is additionally ambiguous for the above purposes. Using this SBVR verb concept without the additional language and criteria below gives a false sense of adequacy. - It might be better not to have this fact type so this ambiguity cannot be inadvertently introduced. Otherwise we need a necessity something like "any characterisitc incorporated into a concept must be either in each essential characterisitc set that creates the concept or implied by any essential characteristic set that it is not in". 2. The only sound basis for defining (meaning, not representation) concepts is a set of essential (necessary & sufficient) characteristics. This is what creates the concept. If two sets of essential characteristics are equivalent, the two concepts they create are the same concept. - This requires (some binary/ternary form of): - "'characteristic' is essential to 'concept'" - 'essential characterisitc' - "'characterisitc set' sufficiently defines 'concept'" - 'essential characteristic set'. - these SBVR verb concepts must make it clear that it is the set (of essential characteristics) that 'creates' the concept, while necessary characteristics 'make up' a concept individually. - In addition there must be an unambiguous way to identify all the essential characteristics in a concept's essential characterisitc set from the concept's intensional definition and the intensional definitions of all its more general concepts using the more general concept and delimiting characteristics represented by the intensional definition. - In addition determining the equivalence of two essential characterisitc sets requires the ability to assert the equivalence between two characteristics and between a characteristic and a set of characteristics. This is provided in "Issue9613-v5.doc" by: - characteristic1 is equivalent to characteristic2 - characteristic is equivalent to characteristic set - essential characteristic set1 is equivalent to essential characteristic set2 - equivalent set of essential characteristic sets NOTE: There is nothing here that says a tool must be able to do this, but we must have the vocabulary and criteria so that people can do it. If tools do it, so much the better, but it does not need to be required as a tool function by SBVR. 3. The characteristics that are made explicit in an intension in an SBVR vocabulary and that are not in a given essential characteristic set must be able to be implied from that essential characterisitc set plus the other concepts in the semantic community's body of shared meanings related to the concept. Otherwise they cannot be in the intension of the concept. - This requires the ability to ask the question "Is each explicit characteristic that is incorporated into a concept and that is not part of each given essential characterisitc set implied by that essential characteristic set and related concepts in the body of shared meanings?" and to get a consistent answer from members of the semantic community. - to document the assessment that a characteristic can be implied, or simply assert that, the following is required: - 'implied characteristic' - 'essential characteristic set' sufficiently defining 'concept' implies 'characteristic'" (or some other form of this) NOTE: This provides the ability to assess that even though the explicit characteristics in the intensions of two concepts that have equivalent essential characterisitc set are different, the concepts are still equivalent because it can be shown that the explicit implied characteristics in one are also implied in the other. Again no one is saying this must be automated, but it must be possible for people to do consistently or SBVR is without foundation. 4. There is currently an incomplete and therefore ambiguous connection between 'necessity' (proposition represented by 'necessity statements' in SBVR SE; 'proposition that another proposition is a necessity'), and 'essential characteristic sets' and/or 'implied characteristics'. Without knowing whether a given 'necessity' is intended to specify an 'essential characteristic set' or an 'implied characterisitc' for a given concept, it is not possible to determine what the concept is and whether its intension is correct (i.e. characteristics not in an essential characteristic set are implied by it). This is true for all the concepts that a given 'necessity' applies to. - Need a required way to specify that each 'necessity', for each concept it applies to, either provides the specification for an essential characteristic set or that it does not. If the 'necessity' does not provide the specification for an essential characterisitc set, it must meet the requirements above of being a characteristic implied from each of the essential characteristic sets that create any of the concepts that the 'necessity' applies to. How this is expressed in an SBVR vocabulary must be unambiguous. Currently "Issue9613-v5.doc" uses: - "'structural rule' is equivalent to 'intensional definition'" (should be 'essential characterisitc set', not 'intensional definition) - "'structural rule' is equivalent to 'implied characteristic'" 5. The relationships between 'definition' (both intensional and extensional) and 'semantic formulation' (both 'necessity' and 'closed projection') and the 'intension' and 'extension' of a concept in some cases seem to be wrong and other cases missing. - The connections between 'intensional definition', 'necessity' logical formulation (structural rule), 'essential characteristic set' and 'concept' are missing (as discussed above). - The connection between 'definition', 'closed projection' and 'concept' seems ambiguous, and maybe incorrect, as 'closed projection' is usually associated with 'extension' and not directly with 'concept'. Also associating 'closed projection' with 'definition' in general (vs. intensional or extensional definition) seems strange. - The connection between 'extensional definition', some kind of semantic formulation, and extension seemns to be missing. Until we have a resolution to Issue 9613 that solves all these problems and any others that become evident while agreeing the solution, we are not finished with Issue 9613. It is my belief that, aside from SBVR technical errors, "Issue9613-v5.doc" comes very close to solving all these problems without any extra baggage. Discussion of that document and your diagram "ViewFor9613.1-2-3 (v.1).jpg" against this set of problems should bring us to the best adequate solution. Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 26 August 2006 13:39 > To: sbvr-ftf@omg.org > Subject: RE: [SBVR FTF] RE: issue 9613 -- Draft Issue Resolution v5 - > SIMPLIFIED > > > Attached is the updated Issue 9316 Resolution with an accompanying working > diagram as promised. > > The major changes are: > > 1. Moved to Clause 10 as formal logic definitions > > - sufficient characteristic as 'sufficient' > - necessary characteristic as 'necessary' > > 2. Dropped > > - sufficient characteristic set > - essential characteristic set corresponds to sufficient > characteristic set > - intensional definition defines concept > - structural rule applies to concept > > 3. Changed from category to role in fact type: > > - essential characteristic > - essential characteristic set > - implied characteristic > > 4. Replaced 'intension' in the definition of concept with 'essential > characteristic set' based on > > - what Ed Barkmeyer said in Aug. 11 telecon about essential > characteristic sets defining concepts (classes)in OWL > > - consultation with the ISO terminology people > > 5. Clarified the definition of implied characteristic to exclude any > characteristic that is part of the essential characteristic set which > implies the implied characteristic. > > 5. Made 'intension' the combination of 'essential characteristic set' > and > implied characteristic set' and changed "intension creates concept" to > "intension makes up concept" > > 6. Dropped 'concept incorporates characteristic' as it is now redundant > because it is covered by "characteristic is essential to concept" + > "essential characteristic set sufficiently defining concept implies > implied > characteristic" and by "intension makes up concept" > > I believe I've dealt with all the input I've received except for the > examples. > > Donald > > > > -----Original Message----- > > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > > Sent: 16 August 2006 14:30 > > To: 'sbvr-ftf@omg.org' > > Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution v4 - Examples > > Partly Complete > > > > > > Attached is version 4 of the Issue 9613 Resolution document with the > > examples for the first half of the document. The rest will follow. > > > > All changes from version 3 are changed tracked. > > > > Donald Subject: RE: [SBVR FTF] RE: issue 9613 -- Checkpoint Definition of Remaining Problems Date: Thu, 14 Sep 2006 17:33:26 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SBVR FTF] RE: issue 9613 -- Checkpoint Definition of Remaining Problems thread-index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3ADj942cABDEckQ From: "Baisley, Donald E" To: X-OriginalArrivalTime: 15 Sep 2006 00:33:27.0759 (UTC) FILETIME=[8FCAB5F0:01C6D85E] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k8F0VQhC004953 ISO uses the verb "create" in defining "concept" and uses "make up" in defining "intension". I cannot imagine that "create" was intended to mean something different than "make up" here. The diagram on page 20 of ISO 1087 shows the direct relationship between concept and intension. SBVR has fact types that relate a concept to a characteristic it incorporates (something in its intension) and to an essential characteristic (something indispensable to understanding). SBVR further has a dubious fact type that relates a concept to a delimiting characteristic. That fact type should be removed or at least be replaced by a fact type relating a definition to a delimiting characteristic, because a characteristic is in that delimiting role when used in a definition, not with respect to the concept itself which might be defined in multiple different ways, each having different delimiting characteristics. See ISO's definition of 'intensional definition' to see this use 'delimiting characteristic'. With respect to Donald's bottom line problem: 1. Two concepts are the same concept if they incorporate exactly the same characteristics. That means they have the same intension -- they are created by the same unique combination of characteristics. 2. If a concept incorporates one more or one less characteristic than another concept, then it is a different concept. If the only difference is incorporating more, then it specializes the other concept. If the only difference is incorporating less, then it generalizes the other concept. SBVR also has a clear, formal definition of what it means for two concepts (including characteristics) to be co-extensive, which is useful when doing semantic integration where possibly different concepts are effectively the same. Note that most characteristics do not appear in vocabularies, but they can be expressed using vocabularies. E.g. a characteristic of a binary fact type is that it has exactly two roles. But we don't have "... has exactly two roles" in a vocabulary. Rather, we have the forms of expression and designations in a vocabulary that are used to construct "... has exactly two roles". Some fact types relate meaning to meaning and some relate meaning to representation. Everywhere Donald wants to talk about what is explicit, he must be relating to representation. Regards, Don -----Original Message----- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Wednesday, September 13, 2006 9:08 AM To: sbvr-ftf@omg.org Subject: RE: [SBVR FTF] RE: issue 9613 -- Checkpoint Definition of Remaining Problems Keri, You asked that I provide a sharply focused definition of the problems remaining under Issue 9613. There is one key problem with several contributing-cause problems. The bottom line problem is that SBVR does not yet provide an adequate objective set of criteria and accompanying language which can serve as the basis for a reasonable discussion among members of the same semantic community (or members of different semantic communities who need to identify equivalent concepts) that will regularly result in a adequate level of agreement as to whether or not: - two concepts are the same concept, or - incorporating one more or one less characteristic into a concept makes it a different concept. This is an absolutely critical problem. The whole claim of SBVR to provide the semantics (meaning) of business vocabulary and business rules stands or falls depending on whether or not this problem is solved. We know that the meaning of business rule statements and definitions is based on the meanings that are verb concepts. We also know that the meanings that are verb concepts are based on the meanings that are noun concepts. Thus the ability to consistently distinguish meanings that are noun concepts is the cornerstone of the whole edifice. The contributing-cause problems are as follows. 1. "'Concept' incorporates 'characteristic'" is ambiguous with respect to the relationship between the characteristics in the intension that makes up a concept that are part of each essential characteristic set that creates the concept, and those that are not. Since there can be many characteristics in the intension (necessary characterisitc set) of a concept that are not, and do not need to be made, explicit in an SBVR vocabulary, "'concept' incorporates 'characteristic'" is additionally ambiguous for the above purposes. Using this SBVR verb concept without the additional language and criteria below gives a false sense of adequacy. - It might be better not to have this fact type so this ambiguity cannot be inadvertently introduced. Otherwise we need a necessity something like "any characterisitc incorporated into a concept must be either in each essential characterisitc set that creates the concept or implied by any essential characteristic set that it is not in". 2. The only sound basis for defining (meaning, not representation) concepts is a set of essential (necessary & sufficient) characteristics. This is what creates the concept. If two sets of essential characteristics are equivalent, the two concepts they create are the same concept. - This requires (some binary/ternary form of): - "'characteristic' is essential to 'concept'" - 'essential characterisitc' - "'characterisitc set' sufficiently defines 'concept'" - 'essential characteristic set'. - these SBVR verb concepts must make it clear that it is the set (of essential characteristics) that 'creates' the concept, while necessary characteristics 'make up' a concept individually. - In addition there must be an unambiguous way to identify all the essential characteristics in a concept's essential characterisitc set from the concept's intensional definition and the intensional definitions of all its more general concepts using the more general concept and delimiting characteristics represented by the intensional definition. - In addition determining the equivalence of two essential characterisitc sets requires the ability to assert the equivalence between two characteristics and between a characteristic and a set of characteristics. This is provided in "Issue9613-v5.doc" by: - characteristic1 is equivalent to characteristic2 - characteristic is equivalent to characteristic set - essential characteristic set1 is equivalent to essential characteristic set2 - equivalent set of essential characteristic sets NOTE: There is nothing here that says a tool must be able to do this, but we must have the vocabulary and criteria so that people can do it. If tools do it, so much the better, but it does not need to be required as a tool function by SBVR. 3. The characteristics that are made explicit in an intension in an SBVR vocabulary and that are not in a given essential characteristic set must be able to be implied from that essential characterisitc set plus the other concepts in the semantic community's body of shared meanings related to the concept. Otherwise they cannot be in the intension of the concept. - This requires the ability to ask the question "Is each explicit characteristic that is incorporated into a concept and that is not part of each given essential characterisitc set implied by that essential characteristic set and related concepts in the body of shared meanings?" and to get a consistent answer from members of the semantic community. - to document the assessment that a characteristic can be implied, or simply assert that, the following is required: - 'implied characteristic' - 'essential characteristic set' sufficiently defining 'concept' implies 'characteristic'" (or some other form of this) NOTE: This provides the ability to assess that even though the explicit characteristics in the intensions of two concepts that have equivalent essential characterisitc set are different, the concepts are still equivalent because it can be shown that the explicit implied characteristics in one are also implied in the other. Again no one is saying this must be automated, but it must be possible for people to do consistently or SBVR is without foundation. 4. There is currently an incomplete and therefore ambiguous connection between 'necessity' (proposition represented by 'necessity statements' in SBVR SE; 'proposition that another proposition is a necessity'), and 'essential characteristic sets' and/or 'implied characteristics'. Without knowing whether a given 'necessity' is intended to specify an 'essential characteristic set' or an 'implied characterisitc' for a given concept, it is not possible to determine what the concept is and whether its intension is correct (i.e. characteristics not in an essential characteristic set are implied by it). This is true for all the concepts that a given 'necessity' applies to. - Need a required way to specify that each 'necessity', for each concept it applies to, either provides the specification for an essential characteristic set or that it does not. If the 'necessity' does not provide the specification for an essential characterisitc set, it must meet the requirements above of being a characteristic implied from each of the essential characteristic sets that create any of the concepts that the 'necessity' applies to. How this is expressed in an SBVR vocabulary must be unambiguous. Currently "Issue9613-v5.doc" uses: - "'structural rule' is equivalent to 'intensional definition'" (should be 'essential characterisitc set', not 'intensional definition) - "'structural rule' is equivalent to 'implied characteristic'" 5. The relationships between 'definition' (both intensional and extensional) and 'semantic formulation' (both 'necessity' and 'closed projection') and the 'intension' and 'extension' of a concept in some cases seem to be wrong and other cases missing. - The connections between 'intensional definition', 'necessity' logical formulation (structural rule), 'essential characteristic set' and 'concept' are missing (as discussed above). - The connection between 'definition', 'closed projection' and 'concept' seems ambiguous, and maybe incorrect, as 'closed projection' is usually associated with 'extension' and not directly with 'concept'. Also associating 'closed projection' with 'definition' in general (vs. intensional or extensional definition) seems strange. - The connection between 'extensional definition', some kind of semantic formulation, and extension seemns to be missing. Until we have a resolution to Issue 9613 that solves all these problems and any others that become evident while agreeing the solution, we are not finished with Issue 9613. It is my belief that, aside from SBVR technical errors, "Issue9613-v5.doc" comes very close to solving all these problems without any extra baggage. Discussion of that document and your diagram "ViewFor9613.1-2-3 (v.1).jpg" against this set of problems should bring us to the best adequate solution. Donald > -----Original Message----- > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > Sent: 26 August 2006 13:39 > To: sbvr-ftf@omg.org > Subject: RE: [SBVR FTF] RE: issue 9613 -- Draft Issue Resolution v5 - > SIMPLIFIED > > > Attached is the updated Issue 9316 Resolution with an accompanying working > diagram as promised. > > The major changes are: > > 1. Moved to Clause 10 as formal logic definitions > > - sufficient characteristic as 'sufficient' > - necessary characteristic as 'necessary' > > 2. Dropped > > - sufficient characteristic set > - essential characteristic set corresponds to sufficient > characteristic set > - intensional definition defines concept > - structural rule applies to concept > > 3. Changed from category to role in fact type: > > - essential characteristic > - essential characteristic set > - implied characteristic > > 4. Replaced 'intension' in the definition of concept with 'essential > characteristic set' based on > > - what Ed Barkmeyer said in Aug. 11 telecon about essential > characteristic sets defining concepts (classes)in OWL > > - consultation with the ISO terminology people > > 5. Clarified the definition of implied characteristic to exclude any > characteristic that is part of the essential characteristic set which > implies the implied characteristic. > > 5. Made 'intension' the combination of 'essential characteristic set' > and > implied characteristic set' and changed "intension creates concept" to > "intension makes up concept" > > 6. Dropped 'concept incorporates characteristic' as it is now redundant > because it is covered by "characteristic is essential to concept" + > "essential characteristic set sufficiently defining concept implies > implied > characteristic" and by "intension makes up concept" > > I believe I've dealt with all the input I've received except for the > examples. > > Donald > > > > -----Original Message----- > > From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] > > Sent: 16 August 2006 14:30 > > To: 'sbvr-ftf@omg.org' > > Subject: [SBVR FTF] RE: issue 9613 -- Issue Resolution v4 - Examples > > Partly Complete > > > > > > Attached is version 4 of the Issue 9613 Resolution document with the > > examples for the first half of the document. The rest will follow. > > > > All changes from version 3 are changed tracked. > > > > Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 05 Sep 2006 07:16:32 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- point-2 equivocation in 'define' From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-2 equivocation in 'define' Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAMAI3yMAyTG3EA== Donald, Attached is a discussion document for fixing the Issue's point involving 'define'. ~ Keri file: Issue9613.2 (v.1).doc Issue9613.2 (v.1).doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 06 Sep 2006 10:10:22 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- point-3 improve linkage between 'intensional definition' and a concept's characteristic set From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-3 improve linkage between 'intensional definition' and a concept's characteristic set Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAMAI3yMBAY6C0A== Donald, Attached is a discussion document for this Issue's point that involves the desire to improve the linkage between a concept's 'intensional definition' (i.e., expression) and that concept's corresponding essential characteristic set (on the 'meaning' side). ~ Keri file: Issue9613.3 (v.1).doc Issue9613.3 (v.1).doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 06 Sep 2006 10:43:39 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension Thread-Index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAMAI3yMBArgV3Q== All, (but, in particular, Don & Ed), I am working through the FTF notes on 'necessary characteristic' and have come across what appear to be some conflicting statements. I will use a sketch (attached), drawn from examples in Ed's note of 6/21, for my questions. In this sketch we see that the concept 'woman' incorporates the characteristics of being a person (i.e., the more general concept) and being female. But is the (possibility of) giving birth also considered to be a characteristic that the concept 'woman' incorporates? Thanks, ~ Keri file: ViewFor9613.4 (v.1).jpg ViewFor9613.4 (v.1).jpg User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 06 Sep 2006 19:59:12 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension From: John and Keri To: Ed Barkmeyer , Don Baisley , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension Thread-Index: AcbSKZh21vHJwj4cEduX5QARJM+Cgg== Thanks, Don and Ed, for your answers. Please ignore my rephrasing as "has the possibility of giving birth", Ed. You were right in your original interpretation of the case I presented and the simple thing I am asking about -- which is what you recap in your 3rd sentence: > ... From this > model, "gives birth to 0 or more persons" is a property of all Women (or at > least all women who are in the universe of discourse). That is what I anticipated that I would hear from you, Ed. And it is how I have been interpreting 'property' and the corresponding notion of 'characteristic' that is incorporated into the concept 'woman' (in this universe of discourse/vocabulary). But I suspect that not all agree with this. And I think this is one of our core communication disconnects that is blocking progress on this Issue. So, to the others: Can we go with Ed's position? ... that in this model, "gives birth to 0 or more persons" is a property of all Women? ... that there is a corresponding characteristic that is the abstraction of this property that is incorporated into the concept 'woman'? Frankly, I can live with (learn to live with) the answer going either way. What I need to hear is what we decide to agree on. Then (whichever interpretation is given), I have some follow-on questions. Thanks again, ~ Keri On 9/6/06 4:39 PM, "Ed Barkmeyer" wrote: > Keri wrote: > >> In this sketch we see that the concept 'woman' incorporates the >> characteristics of being a person (i.e., the more general concept) and being >> female. >> >> But is the (possibility of) giving birth also considered to be a >> characteristic that the concept 'woman' incorporates? > > Maybe. The model shows a fact-type whose domain is Woman, and that fact-type > was important enough to the vocabulary that it appears in it. From this > model, "gives birth to 0 or more persons" is a property of all Women (or at > least all women who are in the universe of discourse). On the other hand, the > fact-type ostensibly states a possibility, not a necessity. As Keri rephrased > it, "has the possibility of giving birth" is a different fact-type! That > fact-type states a necessity and is a characteristic. To rephrase Don's > response, "has the possibility of giving birth" would probably eliminate women > over 60 from the category named Woman. > > Minimum cardinality 0, at least in UML, is problematic. A minimum cardinality > of 1 states some kind of "necessity", and may therefore participate > importantly in the intension of the classification. A minimum cardinality of > zero may state either a "required possibility" (which is a necessity, and > therefore a characteristic) or just a fact-type that may involve members of > that class in that role (a possibility). It is not clear therefore, whether > such a UML construct models an SBVR "possibility" or a "necessity", and those > meanings are quite different. > > I know modelers who treat cardinality zero as a required possibility, and they > would create subcategories of Woman for women who do and do not have that > possibility. Others, including me, treat cardinality 0 relationships as > possibilities that may not actually be possible for certain members of the > class. I might even define a subcategory (by name or by characteristics) in > which I constrain that cardinality to be zero. > > That said, it is only a weakness in UML. In SBVR SE, we can distinguish > Every Woman must be able to give birth to one or more Persons > from > A Woman may give birth to zero or more Persons > > Note also that in UML, Keri's model may state a different necessity: > The implementation of class Woman must support the relationship "gives birth > to" to zero or more instances of the implementation of class Person. > That interpretation eliminates the ambiguity without stating any clear > interpretation at the "business level". > > -Ed User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 07 Sep 2006 10:29:16 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension From: John and Keri To: Ed Barkmeyer , Don Baisley CC: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension Thread-Index: AcbSoyR4YsXgjz6WEduP3AARJM+Cgg== Don & Ed, Yes, indeed. I am using this example to ask the more general question about fact types (which we all understand to be interpreted as nonconstraining unless/until constrained). How are these unconstrained fact types to be considered as part of our 'characteristics' puzzle? I am hearing two different positions. In Ed's note of 6/21 (which Donald is drawing on in our exploration of 'necessary & sufficient'), Ed gave the example of an X having given birth to some person as conveying a "sufficient characteristic" for the concept 'woman'. If we take this interpretation it would appear that an actuality can be seen as being about a thing having a property ... and, through that, there must be a characteristic that abstracts that property (and that characteristic is incorporated into/by the concept that has the extension in which the 'thing' appears). Pick any unconstrained fact type in our model and we could work the same trick. Having an actuality can convey a 'sufficient' characteristic. For example, in our own SBVR model: if we found something in a population that had a level of enforcement, that would be sufficient to let us know that the thing was an operative business rule, since only operative business rules can have a level of enforcement. Etc., etc., etc. Is this what we want 'sufficient characteristic' to mean? ~ Keri On 9/7/06 9:59 AM, "Baisley, Donald E" wrote: > Hi Keri, > > The range "0 or more" is a nonconstraining range. Yes, a woman gives > birth to zero or more persons. Also, a person gives birth to zero or > more persons. I don't see any point in talking about a characteristic > that is applicable to everything. Its like saying a characteristic of a > number is that the number "is one or is not one". The same could be > said for anything. A thing "is one or is not one". It's pointless. > > Enjoy, > Don On 9/7/06 8:59 AM, "Ed Barkmeyer" wrote: > Keri wrote: > >>> ... From this >>> model, "gives birth to 0 or more persons" is a property of all Women (or at >>> least all women who are in the universe of discourse). >> >> That is what I anticipated that I would hear from you, Ed. And it is how I >> have been interpreting 'property' and the corresponding notion of >> 'characteristic' that is incorporated into the concept 'woman' (in this >> universe of discourse/vocabulary). > > I was a bit sloppy in that statement. The property of Woman is that there is > a role in the fact-type Woman gives-birth-to Person that a Woman may fill, and > that only a Woman may fill. The given cardinality (0..*) says that not every > woman actually fills that role in a corresponding actuality. > > SBVR uses the term "characteristic" fairly carefully. What I tried to say was > that it is not clear what *unary* characteristic corresponds to the (binary) > "Woman gives-birth-to Person" fact-type, because the fact-type states a > Possibility, not a Necessity. But I now think it is clear what the > characteristic is. The important distinction is between having an applicable > characteristic -- a proposition that can be true or false -- and requiring > that characteristic to evaluate to True for a given Woman. > > Going any further in precision in this area gets us into distinctions in > logical formulations. Put in "logic" terms, Woman gives-birth-to Person has > two variables: ?Woman and ?Person. A characteristic has only one variable: > ?Woman. To create a characteristic you have to 'bind' the ?Person variable > somehow. > > Looking at the fact-type and ignoring the cardinality, we can bind ?Person > with an existential qualifier: > gives-birth-characteristic(?Woman) == > (Exists ?Person)gives-birth-to(?Woman, ?Person) > I.e. the characteristic is: There exists some Person such that this Woman > gives birth to that Person. But this characteristic is evaluated by > actuality. It is true for a given Woman if some such Person exists (now), and > false otherwise. And if we require that characteristic to be true, it says > the cardinality is at least 1, and that is not what is modeled. > > The alternative characteristic is the "possibility": > gives-birth-characteristic(?Woman) == > (possibility)(Exists ?Person)gives-birth-to(?Woman, ?Person) > if you use (possibility) as a modal operator, or > gives-birth-characteristic(?Woman) == > IsPossible( '(Exists ?Person)gives-birth-to(?Woman, ?Person)' ) > if you use modal categories (where the apostrophes signify the "mention" of > the existential proposition). > This says gives-birth-characteristic is True if it is possible that the Woman > gives birth to a Person, and False if it is not possible. This is the > characteristic Keri offered, and I believe this is the characteristic of Woman > that is implied by the model. > > This latter is a characteristic that is applicable to all Women. It might > equally well be called "Woman is-fertile". The characteristic doesn't say > that all Women are fertile, it says that it is meaningful to ask for any given > Woman whether she is fertile. And that characteristic can serve as a > differentiator for two subclasses of Woman -- FertileWoman and InfertileWoman > -- depending on the answer to that question, i.e. depending on the truth value > of that proposition. > > But when we talk about "essential characteristics" and "necessities", we are > not talking about the *applicability* of the characteristic, we are talking > about its *truth value*. And we have to be very careful to get our wording > right. In the same way: is-female is a characteristic applicable to all > Persons, but is-female(?Person)=True is an essential characteristic of Woman. > > -Ed > > P.S. Don, Terry: In consequence of my having looked a bit further at modal > categories, I want to revise my position on the "proposition is an obligation" > issue. More on this later. User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 07 Sep 2006 11:41:20 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension Thread-Index: AcbSoyR4YsXgjz6WEduP3AARJM+CggAAjh+wAAH2NPc= Don, I understand what you say. But you have also changed the model and thereby the question. Back to my point. Building on Ed's oft-quoted note and its example of a 'sufficient characteristic', we are understanding that the existence of an actuality in the extension comes back to reflect a characteristic that is part of the concept's intension but also is not a necessary characteristic -- sufficient but not necessary. And yet we have also said that all characteristics that are incorporated into/by a concept (i.e., the concept's intension) includes only characteristics that are 'necessary' -- indeed, that there are no incorporated characteristics for a concept other than 'necessary'. It is that confusion that I'm attempting to get sorted out. ~ Keri On 9/7/06 10:51 AM, "Baisley, Donald E" wrote: > Keri, > > If there is a structural rule that only a woman can give birth to a > person, then it is a characteristic incorporated into the concept 'human > birth' that it is given by a woman. But the structural rule adds no > characteristic to the intension of the concept 'woman'. No additional > characteristic is incorporated into the concept 'woman'. But the rule > does imply that a thing that gives birth to a person is a woman and a > person and an animal, etc. > > Think of it this way: The rule says something that is true about all > human births, not about all women. > > Enjoy, > Don Subject: RE: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension Date: Wed, 6 Sep 2006 15:45:53 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension thread-index: AcaW9nGutQ6tHeq/Skeo5n/RxI2gogjZe7WQAFQ+/1ABQVDOUAAhPbxgAfUXa3AAbr1ZUAACg7qxAMAI3yMBArgV3QAKVQ9w From: "Baisley, Donald E" To: "John and Keri" , "SBVR-FTF" X-OriginalArrivalTime: 06 Sep 2006 22:45:54.0238 (UTC) FILETIME=[35E38DE0:01C6D206] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k86Mied6020759 "... possibly gives birth" is not a characteristic incorporated into the concept 'woman'. If it was, then it would necessarily be incorporated into every concept that specializes 'woman' (e.g. 'nonbirthing woman' defined as "woman that does not give birth"). Enjoy, Don -----Original Message----- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Wednesday, September 06, 2006 10:44 AM To: SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension All, (but, in particular, Don & Ed), I am working through the FTF notes on 'necessary characteristic' and have come across what appear to be some conflicting statements. I will use a sketch (attached), drawn from examples in Ed's note of 6/21, for my questions. In this sketch we see that the concept 'woman' incorporates the characteristics of being a person (i.e., the more general concept) and being female. But is the (possibility of) giving birth also considered to be a characteristic that the concept 'woman' incorporates? Thanks, ~ Keri file: ViewFor9613.4 (v.1).jpg Date: Wed, 06 Sep 2006 19:39:26 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: John and Keri CC: SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Keri wrote: In this sketch we see that the concept 'woman' incorporates the characteristics of being a person (i.e., the more general concept) and being female. But is the (possibility of) giving birth also considered to be a characteristic that the concept 'woman' incorporates? Maybe. The model shows a fact-type whose domain is Woman, and that fact-type was important enough to the vocabulary that it appears in it. From this model, "gives birth to 0 or more persons" is a property of all Women (or at least all women who are in the universe of discourse). On the other hand, the fact-type ostensibly states a possibility, not a necessity. As Keri rephrased it, "has the possibility of giving birth" is a different fact-type! That fact-type states a necessity and is a characteristic. To rephrase Don's response, "has the possibility of giving birth" would probably eliminate women over 60 from the category named Woman. Minimum cardinality 0, at least in UML, is problematic. A minimum cardinality of 1 states some kind of "necessity", and may therefore participate importantly in the intension of the classification. A minimum cardinality of zero may state either a "required possibility" (which is a necessity, and therefore a characteristic) or just a fact-type that may involve members of that class in that role (a possibility). It is not clear therefore, whether such a UML construct models an SBVR "possibility" or a "necessity", and those meanings are quite different. I know modelers who treat cardinality zero as a required possibility, and they would create subcategories of Woman for women who do and do not have that possibility. Others, including me, treat cardinality 0 relationships as possibilities that may not actually be possible for certain members of the class. I might even define a subcategory (by name or by characteristics) in which I constrain that cardinality to be zero. That said, it is only a weakness in UML. In SBVR SE, we can distinguish Every Woman must be able to give birth to one or more Persons from A Woman may give birth to zero or more Persons Note also that in UML, Keri's model may state a different necessity: The implementation of class Woman must support the relationship "gives birth to" to zero or more instances of the implementation of class Person. That interpretation eliminates the ambiguity without stating any clear interpretation at the "business level". -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Thu, 07 Sep 2006 11:59:31 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: John and Keri CC: SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Keri wrote: ... From this model, "gives birth to 0 or more persons" is a property of all Women (or at least all women who are in the universe of discourse). That is what I anticipated that I would hear from you, Ed. And it is how I have been interpreting 'property' and the corresponding notion of 'characteristic' that is incorporated into the concept 'woman' (in this universe of discourse/vocabulary). I was a bit sloppy in that statement. The property of Woman is that there is a role in the fact-type Woman gives-birth-to Person that a Woman may fill, and that only a Woman may fill. The given cardinality (0..*) says that not every woman actually fills that role in a corresponding actuality. SBVR uses the term "characteristic" fairly carefully. What I tried to say was that it is not clear what *unary* characteristic corresponds to the (binary) "Woman gives-birth-to Person" fact-type, because the fact-type states a Possibility, not a Necessity. But I now think it is clear what the characteristic is. The important distinction is between having an applicable characteristic -- a proposition that can be true or false -- and requiring that characteristic to evaluate to True for a given Woman. Going any further in precision in this area gets us into distinctions in logical formulations. Put in "logic" terms, Woman gives-birth-to Person has two variables: ?Woman and ?Person. A characteristic has only one variable: ?Woman. To create a characteristic you have to 'bind' the ?Person variable somehow. Looking at the fact-type and ignoring the cardinality, we can bind ?Person with an existential qualifier: gives-birth-characteristic(?Woman) == (Exists ?Person)gives-birth-to(?Woman, ?Person) I.e. the characteristic is: There exists some Person such that this Woman gives birth to that Person. But this characteristic is evaluated by actuality. It is true for a given Woman if some such Person exists (now), and false otherwise. And if we require that characteristic to be true, it says the cardinality is at least 1, and that is not what is modeled. The alternative characteristic is the "possibility": gives-birth-characteristic(?Woman) == (possibility)(Exists ?Person)gives-birth-to(?Woman, ?Person) if you use (possibility) as a modal operator, or gives-birth-characteristic(?Woman) == IsPossible( '(Exists ?Person)gives-birth-to(?Woman, ?Person)' ) if you use modal categories (where the apostrophes signify the "mention" of the existential proposition). This says gives-birth-characteristic is True if it is possible that the Woman gives birth to a Person, and False if it is not possible. This is the characteristic Keri offered, and I believe this is the characteristic of Woman that is implied by the model. This latter is a characteristic that is applicable to all Women. It might equally well be called "Woman is-fertile". The characteristic doesn't say that all Women are fertile, it says that it is meaningful to ask for any given Woman whether she is fertile. And that characteristic can serve as a differentiator for two subclasses of Woman -- FertileWoman and InfertileWoman -- depending on the answer to that question, i.e. depending on the truth value of that proposition. But when we talk about "essential characteristics" and "necessities", we are not talking about the *applicability* of the characteristic, we are talking about its *truth value*. And we have to be very careful to get our wording right. In the same way: is-female is a characteristic applicable to all Persons, but is-female(?Person)=True is an essential characteristic of Woman. -Ed P.S. Don, Terry: In consequence of my having looked a bit further at modal categories, I want to revise my position on the "proposition is an obligation" issue. More on this later. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: RE: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension Date: Thu, 7 Sep 2006 09:59:32 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension thread-index: AcbSKZh21vHJwj4cEduX5QARJM+CggAdIL9Q From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 07 Sep 2006 16:59:33.0384 (UTC) FILETIME=[FDF2A080:01C6D29E] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k87GvnJN031463 Hi Keri, The range "0 or more" is a nonconstraining range. Yes, a woman gives birth to zero or more persons. Also, a person gives birth to zero or more persons. I don't see any point in talking about a characteristic that is applicable to everything. Its like saying a characteristic of a number is that the number "is one or is not one". The same could be said for anything. A thing "is one or is not one". It's pointless. Enjoy, Don -----Original Message----- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Wednesday, September 06, 2006 7:59 PM To: Ed Barkmeyer; Baisley, Donald E; SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's'unnecessary' characteristics relate to the concept's intension Thanks, Don and Ed, for your answers. Please ignore my rephrasing as "has the possibility of giving birth", Ed. You were right in your original interpretation of the case I presented and the simple thing I am asking about -- which is what you recap in your 3rd sentence: > ... From this > model, "gives birth to 0 or more persons" is a property of all Women (or at > least all women who are in the universe of discourse). That is what I anticipated that I would hear from you, Ed. And it is how I have been interpreting 'property' and the corresponding notion of 'characteristic' that is incorporated into the concept 'woman' (in this universe of discourse/vocabulary). But I suspect that not all agree with this. And I think this is one of our core communication disconnects that is blocking progress on this Issue. So, to the others: Can we go with Ed's position? ... that in this model, "gives birth to 0 or more persons" is a property of all Women? ... that there is a corresponding characteristic that is the abstraction of this property that is incorporated into the concept 'woman'? Frankly, I can live with (learn to live with) the answer going either way. What I need to hear is what we decide to agree on. Then (whichever interpretation is given), I have some follow-on questions. Thanks again, ~ Keri On 9/6/06 4:39 PM, "Ed Barkmeyer" wrote: > Keri wrote: > >> In this sketch we see that the concept 'woman' incorporates the >> characteristics of being a person (i.e., the more general concept) and being >> female. >> >> But is the (possibility of) giving birth also considered to be a >> characteristic that the concept 'woman' incorporates? > > Maybe. The model shows a fact-type whose domain is Woman, and that fact-type > was important enough to the vocabulary that it appears in it. From this > model, "gives birth to 0 or more persons" is a property of all Women (or at > least all women who are in the universe of discourse). On the other hand, the > fact-type ostensibly states a possibility, not a necessity. As Keri rephrased > it, "has the possibility of giving birth" is a different fact-type! That > fact-type states a necessity and is a characteristic. To rephrase Don's > response, "has the possibility of giving birth" would probably eliminate women > over 60 from the category named Woman. > > Minimum cardinality 0, at least in UML, is problematic. A minimum cardinality > of 1 states some kind of "necessity", and may therefore participate > importantly in the intension of the classification. A minimum cardinality of > zero may state either a "required possibility" (which is a necessity, and > therefore a characteristic) or just a fact-type that may involve members of > that class in that role (a possibility). It is not clear therefore, whether > such a UML construct models an SBVR "possibility" or a "necessity", and those > meanings are quite different. > > I know modelers who treat cardinality zero as a required possibility, and they > would create subcategories of Woman for women who do and do not have that > possibility. Others, including me, treat cardinality 0 relationships as > possibilities that may not actually be possible for certain members of the > class. I might even define a subcategory (by name or by characteristics) in > which I constrain that cardinality to be zero. > > That said, it is only a weakness in UML. In SBVR SE, we can distinguish > Every Woman must be able to give birth to one or more Persons > from > A Woman may give birth to zero or more Persons > > Note also that in UML, Keri's model may state a different necessity: > The implementation of class Woman must support the relationship "gives birth > to" to zero or more instances of the implementation of class Person. > That interpretation eliminates the ambiguity without stating any clear > interpretation at the "business level". > > -Ed Subject: RE: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension Date: Thu, 7 Sep 2006 10:51:17 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension thread-index: AcbSoyR4YsXgjz6WEduP3AARJM+CggAAjh+w From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 07 Sep 2006 17:51:18.0013 (UTC) FILETIME=[38736AD0:01C6D2A6] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k87HnYQQ032335 Keri, If there is a structural rule that only a woman can give birth to a person, then it is a characteristic incorporated into the concept 'human birth' that it is given by a woman. But the structural rule adds no characteristic to the intension of the concept 'woman'. No additional characteristic is incorporated into the concept 'woman'. But the rule does imply that a thing that gives birth to a person is a woman and a person and an animal, etc. Think of it this way: The rule says something that is true about all human births, not about all women. Enjoy, Don -----Original Message----- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Thursday, September 07, 2006 10:29 AM To: Ed Barkmeyer; Baisley, Donald E Cc: SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension Don & Ed, Yes, indeed. I am using this example to ask the more general question about fact types (which we all understand to be interpreted as nonconstraining unless/until constrained). How are these unconstrained fact types to be considered as part of our 'characteristics' puzzle? I am hearing two different positions. In Ed's note of 6/21 (which Donald is drawing on in our exploration of 'necessary & sufficient'), Ed gave the example of an X having given birth to some person as conveying a "sufficient characteristic" for the concept 'woman'. If we take this interpretation it would appear that an actuality can be seen as being about a thing having a property ... and, through that, there must be a characteristic that abstracts that property (and that characteristic is incorporated into/by the concept that has the extension in which the 'thing' appears). Pick any unconstrained fact type in our model and we could work the same trick. Having an actuality can convey a 'sufficient' characteristic. For example, in our own SBVR model: if we found something in a population that had a level of enforcement, that would be sufficient to let us know that the thing was an operative business rule, since only operative business rules can have a level of enforcement. Etc., etc., etc. Is this what we want 'sufficient characteristic' to mean? ~ Keri On 9/7/06 9:59 AM, "Baisley, Donald E" wrote: > Hi Keri, > > The range "0 or more" is a nonconstraining range. Yes, a woman gives > birth to zero or more persons. Also, a person gives birth to zero or > more persons. I don't see any point in talking about a characteristic > that is applicable to everything. Its like saying a characteristic of a > number is that the number "is one or is not one". The same could be > said for anything. A thing "is one or is not one". It's pointless. > > Enjoy, > Don On 9/7/06 8:59 AM, "Ed Barkmeyer" wrote: > Keri wrote: > >>> ... From this >>> model, "gives birth to 0 or more persons" is a property of all Women (or at >>> least all women who are in the universe of discourse). >> >> That is what I anticipated that I would hear from you, Ed. And it is how I >> have been interpreting 'property' and the corresponding notion of >> 'characteristic' that is incorporated into the concept 'woman' (in this >> universe of discourse/vocabulary). > > I was a bit sloppy in that statement. The property of Woman is that there is > a role in the fact-type Woman gives-birth-to Person that a Woman may fill, and > that only a Woman may fill. The given cardinality (0..*) says that not every > woman actually fills that role in a corresponding actuality. > > SBVR uses the term "characteristic" fairly carefully. What I tried to say was > that it is not clear what *unary* characteristic corresponds to the (binary) > "Woman gives-birth-to Person" fact-type, because the fact-type states a > Possibility, not a Necessity. But I now think it is clear what the > characteristic is. The important distinction is between having an applicable > characteristic -- a proposition that can be true or false -- and requiring > that characteristic to evaluate to True for a given Woman. > > Going any further in precision in this area gets us into distinctions in > logical formulations. Put in "logic" terms, Woman gives-birth-to Person has > two variables: ?Woman and ?Person. A characteristic has only one variable: > ?Woman. To create a characteristic you have to 'bind' the ?Person variable > somehow. > > Looking at the fact-type and ignoring the cardinality, we can bind ?Person > with an existential qualifier: > gives-birth-characteristic(?Woman) == > (Exists ?Person)gives-birth-to(?Woman, ?Person) > I.e. the characteristic is: There exists some Person such that this Woman > gives birth to that Person. But this characteristic is evaluated by > actuality. It is true for a given Woman if some such Person exists (now), and > false otherwise. And if we require that characteristic to be true, it says > the cardinality is at least 1, and that is not what is modeled. > > The alternative characteristic is the "possibility": > gives-birth-characteristic(?Woman) == > (possibility)(Exists ?Person)gives-birth-to(?Woman, ?Person) > if you use (possibility) as a modal operator, or > gives-birth-characteristic(?Woman) == > IsPossible( '(Exists ?Person)gives-birth-to(?Woman, ?Person)' ) > if you use modal categories (where the apostrophes signify the "mention" of > the existential proposition). > This says gives-birth-characteristic is True if it is possible that the Woman > gives birth to a Person, and False if it is not possible. This is the > characteristic Keri offered, and I believe this is the characteristic of Woman > that is implied by the model. > > This latter is a characteristic that is applicable to all Women. It might > equally well be called "Woman is-fertile". The characteristic doesn't say > that all Women are fertile, it says that it is meaningful to ask for any given > Woman whether she is fertile. And that characteristic can serve as a > differentiator for two subclasses of Woman -- FertileWoman and InfertileWoman > -- depending on the answer to that question, i.e. depending on the truth value > of that proposition. > > But when we talk about "essential characteristics" and "necessities", we are > not talking about the *applicability* of the characteristic, we are talking > about its *truth value*. And we have to be very careful to get our wording > right. In the same way: is-female is a characteristic applicable to all > Persons, but is-female(?Person)=True is an essential characteristic of Woman. > > -Ed > > P.S. Don, Terry: In consequence of my having looked a bit further at modal > categories, I want to revise my position on the "proposition is an obligation" > issue. More on this later. Date: Thu, 07 Sep 2006 14:56:58 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Baisley, Donald E" CC: SBVR-FTF Subject: Re: [SBVR FTF] RE: issue 9613 -- point-4 How a concept's 'unnecessary' characteristics relate to the concept's intension X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Baisley, Donald E wrote: The range "0 or more" is a nonconstraining range. Yes, a woman gives birth to zero or more persons. Also, a person gives birth to zero or more persons. I don't see any point in talking about a characteristic that is applicable to everything. Well, we do it all the time, except usually we constrain its domain to some concept. Defining a fact-type role to admit instances of a concept (to have that concept as/in its domain) effectively defines a "characteristic" of that concept, regardless of cardinality. If there were no point in talking about it, we wouldn't define the fact-type at all. Of course, defining an optional property doesn't define a characteristic that is useful in the definition of the concept. Such things are all "implied characteristics" of that concept. But, of course, it may still be useful in the definition of some more specialized concept in which that fact-type relationship is required or prohibited. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 08 Sep 2006 07:29:56 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- point-5 Align with ISO's terminology From: John and Keri To: Ed Barkmeyer CC: SBVR-FTF , Don Baisley , Terry Halpin Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-5 Align with ISO's terminology Thread-Index: AcbTU0Fsf8QvhD9GEduWdQARJM+Cgg== >>> Keri wrote: >> For example, in our own SBVR model: if we found something in a population >> that had a level of enforcement, that would be sufficient to let us know >> that the thing was an operative business rule, since only operative business >> rules can have a level of enforcement. Etc., etc., etc. >> >> Is this what we want 'sufficient characteristic' to mean? >> On 9/7/06 12:23 PM, "Ed Barkmeyer" replied: > Sufficient characteristics are important to mathematicians, but the only > sufficient characteristics that are important to us are the ones that are also > necessary characteristics. Ah, I had missed that! This is very clarifying. I was trying to make sense of how our (the SBVR) view had 'sufficient characteristic' as anything other than a subset of 'necessary characteristic'. This now makes sense. > The point of my writeup was to distinguish: > characteristic implies instance of concept : sufficient characteristic > instance of concept implies characteristic : necessary characteristic > Once you have both ideas, > essential characteristic = characteristic that is necessary and sufficient I did some googling on 'necessary and sufficient' and have found (no surprise to you I'd imagine) that this topic -- in mathematics, logic, philosophy -- is popular. (I've included some amusing/enlightening links at the end of this note). And I also noted that it is a controversial topic, in the sense of providing 'practice exercises' to challenge students and problems for academics to exchange papers on. For example, on the Stanford site, it says (in part): "Like other fundamental concepts, the concepts of necessary and sufficient conditions cannot be readily specified in other terms. This article shows how elusive the quest is for a definition of the terms "necessary" and "sufficient"..." Therefore, I wonder if we are wise to push this attempt to align our SBVR terminology with these notions from math/logic/philosophy? Why did we decide (did we consciously decide??) to move from simply adopting, and clarifying as needed, the ISO notions of 'essential characteristic', 'delimiting characteristic', et al.? I've attached a screen shot of the relevant page from the ISO standard and it would appear that it already provides the rich set of concepts & terms that we are seeking to use and build on. Of course, I cannot know the thinking of the ISO folks, but I'd bet there is a reason that they avoided using 'necessary' and 'sufficient' when they picked their terms ... and we would be wise to follow their lead. However, if there is some need to add in an alignment with the notions of "necessary and sufficient" then I propose that that work be handed off to Terry (& Pat? & you, Ed??), because it is something beyond our 'business' focus to grapple with. (Also, note that the meaning of 'essential characteristic' that your reply above presents appears to have moved us to use that term for what ISO terms 'delimiting characteristic' so that also would be confusing. regards, Keri Some links on "necessary and sufficient": http://plato.stanford.edu/entries/necessary-sufficient/ http://www.sfu.ca/philosophy/swartz/conditions1.htm http://en.wikipedia.org/wiki/Sufficient User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 11 Sep 2006 06:06:32 -0700 Subject: Re: [SBVR FTF] RE: issue 9613 -- point-5 Align with ISO's terminology From: John and Keri To: Ed Barkmeyer , SBVR-FTF Thread-Topic: [SBVR FTF] RE: issue 9613 -- point-5 Align with ISO's terminology Thread-Index: AcbVoxoLWKJUWEGWEdu6hQARJM+Cgg== Ed, Thanks for taking the time to write this up. No apologies are needed 'for tone'. We're all fairly well frustrated with the time/energy this is taking but we are (hopefully) close to capturing this in some useful improvements as SBVR entries. And to that end, I spent some weekend time studying what you replied on Friday, and I didn't spot any major inconsistencies with the set of write-ups I sent out last week, under points '1', '2', and '3' -- at least as a foundation for Wednesday's discussion. (I compiled a composite view as I worked through your note and have attached that diagram) The one bit of difficulty I had was in interpreting your use of 'defines' and 'definition'. For example, you stated > And "defined by" is the interpretation we are giving to "created by", > I think. I prefer to avoid use of "defined by" for relating elements on the 'left' side of the picture if we can, even in our informal exchanges. Certainly a Definition (written piece) can be used to 'create' a concept (element of meaning) in a discovery sense, but under this topic we are, I think, exploring how a Definition is written up (after the fact) to express some set of elements that exist and are related together on the left side. Therefore, I prefer the "makes up" terminology ("intension makes up concept") over either "creates/created by" or "defines". In summary, we have a view that reflects the concept's essential characteristic set (set of the concept's necessary & sufficient characteristics), and the concept having a definition that expresses (represents) that set. A concept could have multiples of such sets (and, thus, multiple definitions written up). And that is not to be confused with the characteristic set that is the intension that 'makes up' the concept. ~ Keri On 9/8/06 4:16 PM, "Ed Barkmeyer" wrote: >> Keri wrote: >> I did some googling on 'necessary and sufficient' and have found ... >> that it is a controversial topic, ... > > Great Caesar's ghost! The Internet is like the Pierian spring "where shallow > drafts intoxicate the brain". > >> For example, on the Stanford >> site, it says (in part): "Like other fundamental concepts, the concepts of >> necessary and sufficient conditions cannot be readily specified in other >> terms. This article shows how elusive the quest is for a definition of the >> terms "necessary" and "sufficient"..." > > Yes, like other FUNDAMENTAL CONCEPTS, you can't write definitions for these > things that aren't circular! You can't do this for Concept or Meaning either! > > They wouldn't be FUNDAMENTAL CONCEPTS of mathematics if they were really > "controversial". > >> Therefore, I wonder if we are wise to push this attempt to align our SBVR >> terminology with these notions from math/logic/philosophy? > > OK. Let's remove all of the following for the same reason: Concept, Meaning, > Object, Definition, Fact-type, Actuality... Can I stop now? > >> Why did we >> decide (did we consciously decide??) to move from simply adopting, and >> clarifying as needed, the ISO notions of 'essential characteristic', >> 'delimiting characteristic', et al.? > > We didn't. What we did decide is that we need to decide what characteristics > are included in a Definition, which is not covered in the ISO diagram, and > whether there are Necessities and Structural Rules that are not included in > the Definition. > >> I've attached a screen shot of the relevant page from the ISO standard and >> it would appear that it already provides the rich set of concepts & terms >> that we are seeking to use and build on. Of course, I cannot know the >> thinking of the ISO folks, but I'd bet there is a reason that they avoided >> using 'necessary' and 'sufficient' when they picked their terms ... and we >> would be wise to follow their lead. > > Note that the ISO terminology says that a Concept is a "unit of knowledge" > (undefined term) "created by" a 'set of characteristics' and has an Intension > which is a 'set of characteristics' that "make up" the Concept. It doesn't > say whether those are the same set, and that seems to be exactly the issue of > what goes in the Definition. And "defined by" is the interpretation we are > giving to "created by", I think. Note also that the ISO terminology says an > Essential Characteristic is a characteristic that is "indispensable to > understanding a Concept", which does not specify any clear relationship to the > set of characteristics that "create" or "make up" the Concept. So the rich > set of concepts and terms contains a rich set of ambiguities, and following > their lead will make SBVR just as ambiguous. > > What logicians have done with this set of ideas for 2400 years is to define > "create a Concept" and "indispensable to understanding a concept" as a set of > reasoning rules. That is where "necessary characteristics" and "sufficient > characteristics" came from. A set of characteristics is sufficient for a > Concept if every object that has all those properties satisfies the Concept, > and a set is necessary if every object in the extension has all those > properties. Those statements are testable (unlike "create", "make up" and > "understand"), and every time science/mathematics finds a borderline case, it > goes back to first principles, asking exactly what the 'set of > characteristics' should be. > > A set of characteristics that is both necessary and sufficient can be said to > "create the concept" and to either BE or IMPLY its Intension. We can define > the Intension to be the set of characteristics used to create the Concept. > But in some larger sense, that set need not be all of its Intension -- they > can imply other important characteristics that are also part of the Intension, > as understood in the speech community. The set of characteristics that "makes > up" the Concept may be all of the properties that are important to the speech > community, not just the minimum set used to define it unambiguously. So we > could instead define the Intension to be the set of all characteristics > understood to be part of the concept (to "create" it) in the speech community, > not just the miniumum set used to "define" it. > > And whether a given characteristic is "essential to understanding the Concept" > is subjective -- understanding is done by individuals. The same Concept can > be "created by" (defined by) more than one set of necessary and sufficient > characteristics, and it may be that a given individual can only "understand" > the concept if it is defined in terms of a set of characteristics s/he > understands. Donald's discussion with Gerhard Budin suggests that "essential > characteristic" means one of the (necessary and sufficient) set used to > "create the concept". > > Further, "define" is an act that associates a "term"/"sign" with a "meaning". > A Concept is a Meaning. An Intension is a Meaning. So the Definition of a > "term" (not a Concept) is the association of a specific set of "necessary and > sufficient" characteristics with that term, thus identifying a Concept. Does > that Definition also "create" the Concept? If it does, then the Intension of > the Concept may be larger than the set of characteristics used to "create" it. > > What all of this means is that we do need to improve on the definitions in ISO > 1087-1, because they don't answer any of these questions! We need to > characterize the 'set of characteristics' used to "create the Concept" and to > decide whether 'set of characteristics creates 'concept' and 'set of > characteristics defines (term that identifies) concept' are Synonymous Forms. > Technically, I see no reason why the ideas of necessary and sufficient sets > of characteristics could not be covered within the definition of the term > 'essential characteristic'. But defining the extra terms makes it much easier > to write that definition in bite-size chunks. > >> However, if there is some need to add in an alignment with the notions of >> "necessary and sufficient" then I propose that that work be handed off to >> Terry (& Pat? & you, Ed??), because it is something beyond our 'business' >> focus to grapple with. > > Then why are you grappling with it? > >> (Also, note that the meaning of 'essential characteristic' that your reply >> above presents appears to have moved us to use that term for what ISO terms >> 'delimiting characteristic' so that also would be confusing. > > That is probably because I misspoke. I used "characteristic" as a synonym for > "unary fact type" and in SBVR that is not correct. The subtlety perpetrated > by some part of the SBVR gang is that the term "characteristic" is reserved > for unary fact types that are "essential characteristics" of some Concept (as > defined). (ISO 1087's definition of 'characteristic', per your attachment, > does not make that distinction.) It follows that some of them are the > delimiting characteristics of subtypes. > > Woman can-give-birth-to-some-person is like Person smokes: it is a unary fact > type that is defined for all Women resp. Persons. It can be true or false for > a given Woman resp. Person, so it is probably not an essential or delimiting > characteristic. (It could still be in the Intension.) When we write "Smoker > is Person who smokes" we mean Person such that thatPerson.smokes is True, and > that is a delimiting characteristic, based on the unary fact-type Person > smokes. > > Using 'unary fact type' should avoid the "appearance of moving us" to > confusing 'characteristics' with 'delimiting characteristics' (while ISO > apparently thought the word 'delimiting' would accomplish that). > > -Ed > > P.S. Keri, I would apologize for my tone here, but this has cost me a lot of > time that might better have been spent on making a contribution to the > standard. And now I have no further time this week. ViewFor9613.1-2-3 (v.1).jpg Date: Fri, 08 Sep 2006 19:16:25 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: John and Keri CC: SBVR-FTF , Don Baisley , Terry Halpin Subject: Re: [SBVR FTF] RE: issue 9613 -- point-5 Align with ISO's terminology X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Keri wrote: I did some googling on 'necessary and sufficient' and have found ... that it is a controversial topic, ... Great Caesar's ghost! The Internet is like the Pierian spring "where shallow drafts intoxicate the brain". For example, on the Stanford site, it says (in part): "Like other fundamental concepts, the concepts of necessary and sufficient conditions cannot be readily specified in other terms. This article shows how elusive the quest is for a definition of the terms "necessary" and "sufficient"..." Yes, like other FUNDAMENTAL CONCEPTS, you can't write definitions for these things that aren't circular! You can't do this for Concept or Meaning either! They wouldn't be FUNDAMENTAL CONCEPTS of mathematics if they were really "controversial". Therefore, I wonder if we are wise to push this attempt to align our SBVR terminology with these notions from math/logic/philosophy? OK. Let's remove all of the following for the same reason: Concept, Meaning, Object, Definition, Fact-type, Actuality... Can I stop now? Why did we decide (did we consciously decide??) to move from simply adopting, and clarifying as needed, the ISO notions of 'essential characteristic', 'delimiting characteristic', et al.? We didn't. What we did decide is that we need to decide what characteristics are included in a Definition, which is not covered in the ISO diagram, and whether there are Necessities and Structural Rules that are not included in the Definition. I've attached a screen shot of the relevant page from the ISO standard and it would appear that it already provides the rich set of concepts & terms that we are seeking to use and build on. Of course, I cannot know the thinking of the ISO folks, but I'd bet there is a reason that they avoided using 'necessary' and 'sufficient' when they picked their terms ... and we would be wise to follow their lead. Note that the ISO terminology says that a Concept is a "unit of knowledge" (undefined term) "created by" a 'set of characteristics' and has an Intension which is a 'set of characteristics' that "make up" the Concept. It doesn't say whether those are the same set, and that seems to be exactly the issue of what goes in the Definition. And "defined by" is the interpretation we are giving to "created by", I think. Note also that the ISO terminology says an Essential Characteristic is a characteristic that is "indispensable to understanding a Concept", which does not specify any clear relationship to the set of characteristics that "create" or "make up" the Concept. So the rich set of concepts and terms contains a rich set of ambiguities, and following their lead will make SBVR just as ambiguous. What logicians have done with this set of ideas for 2400 years is to define "create a Concept" and "indispensable to understanding a concept" as a set of reasoning rules. That is where "necessary characteristics" and "sufficient characteristics" came from. A set of characteristics is sufficient for a Concept if every object that has all those properties satisfies the Concept, and a set is necessary if every object in the extension has all those properties. Those statements are testable (unlike "create", "make up" and "understand"), and every time science/mathematics finds a borderline case, it goes back to first principles, asking exactly wha