Issue 15623: "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" (sbvr-rtf) Source: (, ) Nature: Clarification Severity: Significant Summary: The concept in SBVR Clause 8.1.1 defined as: “concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities” has as its preferred term the signifier “fact type” This signifier, “fact type,” badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, “fact type,” is used as the term for a quite difference concept in Clause 10; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove “fact type” as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier “actuality type” as that is what the definition is defining. Resolution: Revised Text: Actions taken: September 22, 2010: received issue Discussion: End of Annotations:===== m -r issue15623 m: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. Donald Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Date: Wed, 22 Sep 2010 13:41:54 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" thread-index: ActZ2y7h5k5JnNZxR0OpjOv0AVpv3QAbRH9QAAA4FWc= From: "Sjir Nijssen" To: "Donald Chapin" , Cc: Dear all, See my comments below between [[ ]] Kind regards Sjir -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Wed 9/22/2010 1:21 PM To: issues@omg.org Cc: sbvr-rtf@omg.org Subject: FW: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Re-sent. Didn.t. receive first send back. -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10 [[Sjir: this is a major misunderstanding in my view; I assert that it is impossible to validate the contents of clause 8 if the concepts of fact and fact type are removed from Clause 8. May I expect that the proponents of dropping fact type will soon propose to stop testing computer programs?]] is removed from; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. [[Sjir: the confusion between actuality and state of affairs is another problem of concern; the fact that the great majority of systems work with state of affairs seems to be neglected. This is in my opinion an example of anti-marketing tactics as practised by some SBVR proponents.]] ; [[Sjir: needless to say that I will vote against dropping fact type from 8.1.1.]] Donald Date: Wed, 22 Sep 2010 12:21:57 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Donald Chapin CC: "sbvr-rtf@omg.org" Subject: Re: FW: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o8MGM2Oa026130 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1285777327.54448@Muqz6n3dzhbgveflXa+34g X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov I understand Donald's point, but the term 'fact type' is well-established in SBVR and in other literature. The distinction between 'actualities' and 'facts' is between a thing and a conceptualization of the thing. And we note, for example, that a 'fact type form' is a template for the expression of the conceptualization -- it has no clear relationship to actualities. In a similar way, SBVR uses 'thing' and 'individual concept' to distinguish a thing from a conceptualization of it, but SBVR uses 'object type' (or even worse, 'noun concept') to refer to a category of things. If we employ Donald's strict view of vocabulary construction, we should speak of 'thing type'. It would have been perfectly valid for SBVR to adopt the view that it deals only with conceptualizations -- facts and conceptual individuals, instead of actualities and things -- but SBVR as adopted didn't do that. Further, the term 'fact type' is not used in formal logic texts at all. Logicians refer to 'relation' and 'predicate', and the Description Logic terms are 'class(ifier)' and 'property type'. So any use of 'fact type' in clause 10 is inappropriate to the nominal scope of Clause 10. This suggests that that part of Donald's issue is just yet another clause 10 issue. I see no value in wholesale replacement of the term for the fundamental 'fact type' concept in SBVR. Such a change can only confuse existing implmentors and users, and break all the existing exchange forms. Its only purpose is to meet some pedagogical standard, and it proposes the introduction of a term no one has ever used. This concern would have been appropriate during the drafting of the specification, but it is much too late now. I suggest we close this issue with no change. -Ed Donald Chapin wrote: Re-sent. Didn.t. receive first send back. ------------------------------------------------------------------------ *From:* Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] *Sent:* 21 September 2010 18:21 *To:* 'issues@omg.org' *Cc:* 'sbvr-rtf@omg.org' *Subject:* New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. Donald -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C9A48FF.0084, actions=TAG From: "Donald Chapin" To: "'Sjir Nijssen'" Cc: Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Date: Wed, 22 Sep 2010 14:20:47 -0400 X-Mailer: Microsoft Office Outlook 11 thread-index: ActZ2y7h5k5JnNZxR0OpjOv0AVpv3QAbRH9QAAA4FWcADl7iAA== X-Junkmail-Status: score=35/50, host=c2bthomr04.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0209.4C9A491C.016E,ss=1,fgs=0, ip=12.157.84.42, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=multiengine X-Junkmail-IWF: false Sjir, This is not a proposal to drop [the concept currently called] fact type from 8.1.1. It is a proposal to remove an ambiguity, by keeping the definition (which is the authority in SBVR) and changing the term. Currently we have two concepts, both referenced by the term .fact type., with different definitions. For SBVR to be consistent, we need to resolve the ambiguity. SBVR provides two options: Keep the same term for both, and qualify each with a context, e.g. 'fact type (clause 8)' and 'fact type (clause 10)'. Give them different terms. Since the 8.1.1 definition says .... whose instances are all actualities., it seems reasonable to give it the term .actuality type., and leave the term .fact type. for the clause 10 definition. What we can.t do is leave things as they are - go to the AB with a revised SBVR that includes an ambiguity that we know about, and could have fixed, but didn.t. Donald -------------------------------------------------------------------------------- From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: 22 September 2010 07:42 To: Donald Chapin; issues@omg.org Cc: sbvr-rtf@omg.org Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Dear all, See my comments below between [[ ]] Kind regards Sjir -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Wed 9/22/2010 1:21 PM To: issues@omg.org Cc: sbvr-rtf@omg.org Subject: FW: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Re-sent. Didn.t. receive first send back. -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10 [[Sjir: this is a major misunderstanding in my view; I assert that it is impossible to validate the contents of clause 8 if the concepts of fact and fact type are removed from Clause 8. May I expect that the proponents of dropping fact type will soon propose to stop testing computer programs?]] is removed from; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. [[Sjir: the confusion between actuality and state of affairs is another problem of concern; the fact that the great majority of systems work with state of affairs seems to be neglected. This is in my opinion an example of anti-marketing tactics as practised by some SBVR proponents.]] ; [[Sjir: needless to say that I will vote against dropping fact type from 8.1.1.]] Donald Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Date: Wed, 22 Sep 2010 21:10:01 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" thread-index: ActZ2y7h5k5JnNZxR0OpjOv0AVpv3QAbRH9QAAA4FWcADl7iAAABySd6 From: "Sjir Nijssen" To: "Donald Chapin" Cc: Dear Donald, Thank you for the answer below. Could we adopt a rule in our discussions that we include for each concept we discuss at least two examples? In that case I may understand the difference. The concept fact type is represented in Clause 8 as a type construct, hence it can be populated or instantiated. Could you please give me two (instantiated) examples of that fact type construct of Clause 8? Thanks for your time and kind regards Sjir -------------------------------------------------------------------------------- Van: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Verzonden: wo 22-9-2010 20:20 Aan: Sjir Nijssen CC: sbvr-rtf@omg.org Onderwerp: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Sjir, This is not a proposal to drop [the concept currently called] fact type from 8.1.1. It is a proposal to remove an ambiguity, by keeping the definition (which is the authority in SBVR) and changing the term. Currently we have two concepts, both referenced by the term .fact type., with different definitions. For SBVR to be consistent, we need to resolve the ambiguity. SBVR provides two options: Keep the same term for both, and qualify each with a context, e.g. 'fact type (clause 8)' and 'fact type (clause 10)'. Give them different terms. Since the 8.1.1 definition says .... whose instances are all actualities., it seems reasonable to give it the term .actuality type., and leave the term .fact type. for the clause 10 definition. What we can.t do is leave things as they are - go to the AB with a revised SBVR that includes an ambiguity that we know about, and could have fixed, but didn.t. Donald -------------------------------------------------------------------------------- From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: 22 September 2010 07:42 To: Donald Chapin; issues@omg.org Cc: sbvr-rtf@omg.org Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Dear all, See my comments below between [[ ]] Kind regards Sjir -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Wed 9/22/2010 1:21 PM To: issues@omg.org Cc: sbvr-rtf@omg.org Subject: FW: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Re-sent. Didn.t. receive first send back. -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10 [[Sjir: this is a major misunderstanding in my view; I assert that it is impossible to validate the contents of clause 8 if the concepts of fact and fact type are removed from Clause 8. May I expect that the proponents of dropping fact type will soon propose to stop testing computer programs?]] is removed from; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. [[Sjir: the confusion between actuality and state of affairs is another problem of concern; the fact that the great majority of systems work with state of affairs seems to be neglected. This is in my opinion an example of anti-marketing tactics as practised by some SBVR proponents.]] ; [[Sjir: needless to say that I will vote against dropping fact type from 8.1.1.]] Donald X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1009220183 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-22_10:2010-09-22,2010-09-22,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 22 Sep 2010 13:12:26 -0700 Subject: Re: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" From: keri To: Donald Chapin Cc: SBVR RTF Thread-topic: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Thread-index: ActZ2y7h5k5JnNZxR0OpjOv0AVpv3QAbRH9QAAA4FWcADl7iAAAD9zCS On 9/22/10 11:20 AM, "Donald Chapin" wrote: ... resolve the ambiguity. SBVR provides two options: Keep the same term for both, and qualify each with a context, e.g. 'fact type (clause 8)' and 'fact type (clause 10)'. This arose because, in the early days of our SBVR work, we noted that 'fact' had two senses (was for two concepts) in SBVR. And the resolution was to retain 'fact' for one sense and term the other as 'actuality'. Following your suggestion above we could go back to having SBVR reflect both senses of 'fact' using that term, each with a qualifying context. Changing 'fact type' in this one entry does not address all the other uses of 'fact type' in other concepts: fact type form, fact type form, fact type reading, fact type role (which, BTW, is missing from the Index), etc. It would be better (fewer changes, less disruption) to capture the history of the original fact/actuality split and the resulting terminology. Perhaps 'fact' could be made a Synonym (with context) for 'actuality', along with some historical notes. ~ Keri X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=0001.0A0B0301.4C9AA736.0047, actions=TAG From: "Donald Chapin" To: "'Sjir Nijssen'" Cc: Subject: FW: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Date: Wed, 22 Sep 2010 21:02:46 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActZ2y7h5k5JnNZxR0OpjOv0AVpv3QAbRH9QAAA4FWcADl7iAAABySd6AAGd5RAACqeq8A== X-Junkmail: UCE(51) X-Junkmail-Status: score=51/50, host=c2beaomr03.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0209.4C9AA744.0188,ss=1,fgs=0, ip=24.218.111.94, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=multiengine X-Junkmail-IWF: false Resent. First attempt failed. -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2010 19:54 To: 'Sjir Nijssen' Cc: 'sbvr-rtf@omg.org' Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Dear Sjir, In SBVR Clauses 8, 9, 11 & 12 we do not use the language .can be populated. or .can be instantiated.. Rather we say .totality of objects [every thing] to which a concept corresponds. (definition of .extension. in Clause 8.5). Two examples to which the SBVR Clause 8 fact type concept .person buys car. corresponds would be: - the actual physical activity of buying of a particular physical made-of-metal-and-plastic BMW by the flesh and blood Sjir Nijssen - the actual physical activity of buying of a particular physical made-of-metal-and-plastic Buick by the flesh and blood Donald Chapin These examples are the real physical activity of buying, and not facts (propositions taken to be true), movies, photos or textual descriptions about the buyings. Donald -------------------------------------------------------------------------------- From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: 22 September 2010 15:10 To: Donald Chapin Cc: sbvr-rtf@omg.org Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Dear Donald, Thank you for the answer below. Could we adopt a rule in our discussions that we include for each concept we discuss at least two examples? In that case I may understand the difference. The concept fact type is represented in Clause 8 as a type construct, hence it can be populated or instantiated. Could you please give me two (instantiated) examples of that fact type construct of Clause 8? Thanks for your time and kind regards Sjir -------------------------------------------------------------------------------- Van: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Verzonden: wo 22-9-2010 20:20 Aan: Sjir Nijssen CC: sbvr-rtf@omg.org Onderwerp: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Sjir, This is not a proposal to drop [the concept currently called] fact type from 8.1.1. It is a proposal to remove an ambiguity, by keeping the definition (which is the authority in SBVR) and changing the term. Currently we have two concepts, both referenced by the term .fact type., with different definitions. For SBVR to be consistent, we need to resolve the ambiguity. SBVR provides two options: Keep the same term for both, and qualify each with a context, e.g. 'fact type (clause 8)' and 'fact type (clause 10)'. Give them different terms. Since the 8.1.1 definition says .... whose instances are all actualities., it seems reasonable to give it the term .actuality type., and leave the term .fact type. for the clause 10 definition. What we can.t do is leave things as they are - go to the AB with a revised SBVR that includes an ambiguity that we know about, and could have fixed, but didn.t. Donald -------------------------------------------------------------------------------- From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: 22 September 2010 07:42 To: Donald Chapin; issues@omg.org Cc: sbvr-rtf@omg.org Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Dear all, See my comments below between [[ ]] Kind regards Sjir -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Wed 9/22/2010 1:21 PM To: issues@omg.org Cc: sbvr-rtf@omg.org Subject: FW: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Re-sent. Didn.t. receive first send back. -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10 [[Sjir: this is a major misunderstanding in my view; I assert that it is impossible to validate the contents of clause 8 if the concepts of fact and fact type are removed from Clause 8. May I expect that the proponents of dropping fact type will soon propose to stop testing computer programs?]] is removed from; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. [[Sjir: the confusion between actuality and state of affairs is another problem of concern; the fact that the great majority of systems work with state of affairs seems to be neglected. This is in my opinion an example of anti-marketing tactics as practised by some SBVR proponents.]] ; [[Sjir: needless to say that I will vote against dropping fact type from 8.1.1.]] Donald Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" 2010-09-23-1133 Date: Thu, 23 Sep 2010 11:32:17 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" 2010-09-23-1133 thread-index: ActZ2y7h5k5JnNZxR0OpjOv0AVpv3QAbRH9QAAA4FWcADl7iAAABySd6AAGd5RAACqeq8AAQvkS5 From: "Sjir Nijssen" To: "Donald Chapin" Cc: Dear Donald, Thank you for the two examples given in the email below. I believe when we will systematically use illustrating examples (if only to validate our thoughts or proposals or Clauses 8, 9, 11 and 12) ) , SBVR will improve substantially and quickly. 1. You object to the use of "can be populated" and "can be instantiated" and you use the word "corresponds". To me the meaning of all three verbs is the same. Hence why would the SBVR committee refuse to use words like populated and instantiated, words that are widely used? If the SBVR committee wants SBVR to become more mainstream, then we need to use words from mainstream, of course where appropriate. 2. I would prefer to use as the first example: Context the world Sjir Nijssen (Social Security Number 1516120877 of The Netherlands) bought his Legend (with Vehicle Identification Number 38-TJ-NN, also of The Netherlands,) on 28 September 2006. You are invited to add your example. May I suggest an experiment: let us give your two examples and my two examples to a representative set of business people and ask them which representation they prefer and why? 3. What to think of the following: Linus Pauling was awarded the Nobel Prize in Chemistry in 1954. Linus Pauling was awarde the Nobel Peace Prize in 1962. Luc Montagnier was awarded the Nobel Prize in Medicine in 2008. My assertion: The set of 3 elements above is at the same time an actuality and a state of affairs! I look forward to your reaction. Kind regards Sjir -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Thu 9/23/2010 3:02 AM To: Sjir Nijssen Cc: sbvr-rtf@omg.org Subject: FW: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Resent. First attempt failed. -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2010 19:54 To: 'Sjir Nijssen' Cc: 'sbvr-rtf@omg.org' Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Dear Sjir, In SBVR Clauses 8, 9, 11 & 12 we do not use the language .can be populated. or .can be instantiated.. Rather we say .totality of objects [every thing] to which a concept corresponds. (definition of .extension. in Clause 8.5). Two examples to which the SBVR Clause 8 fact type concept .person buys car. corresponds would be: - the actual physical activity of buying of a particular physical made-of-metal-and-plastic BMW by the flesh and blood Sjir Nijssen - the actual physical activity of buying of a particular physical made-of-metal-and-plastic Buick by the flesh and blood Donald Chapin These examples are the real physical activity of buying, and not facts (propositions taken to be true), movies, photos or textual descriptions about the buyings. Donald -------------------------------------------------------------------------------- From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: 22 September 2010 15:10 To: Donald Chapin Cc: sbvr-rtf@omg.org Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Dear Donald, Thank you for the answer below. Could we adopt a rule in our discussions that we include for each concept we discuss at least two examples? In that case I may understand the difference. The concept fact type is represented in Clause 8 as a type construct, hence it can be populated or instantiated. Could you please give me two (instantiated) examples of that fact type construct of Clause 8? Thanks for your time and kind regards Sjir -------------------------------------------------------------------------------- Van: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Verzonden: wo 22-9-2010 20:20 Aan: Sjir Nijssen CC: sbvr-rtf@omg.org Onderwerp: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Sjir, This is not a proposal to drop [the concept currently called] fact type from 8.1.1. It is a proposal to remove an ambiguity, by keeping the definition (which is the authority in SBVR) and changing the term. Currently we have two concepts, both referenced by the term .fact type., with different definitions. For SBVR to be consistent, we need to resolve the ambiguity. SBVR provides two options: Keep the same term for both, and qualify each with a context, e.g. 'fact type (clause 8)' and 'fact type (clause 10)'. Give them different terms. Since the 8.1.1 definition says .... whose instances are all actualities., it seems reasonable to give it the term .actuality type., and leave the term .fact type. for the clause 10 definition. What we can.t do is leave things as they are - go to the AB with a revised SBVR that includes an ambiguity that we know about, and could have fixed, but didn.t. Donald -------------------------------------------------------------------------------- From: Sjir Nijssen [mailto:sjir.nijssen@pna-group.nl] Sent: 22 September 2010 07:42 To: Donald Chapin; issues@omg.org Cc: sbvr-rtf@omg.org Subject: RE: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Dear all, See my comments below between [[ ]] Kind regards Sjir -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Wed 9/22/2010 1:21 PM To: issues@omg.org Cc: sbvr-rtf@omg.org Subject: FW: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Re-sent. Didn.t. receive first send back. -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10 [[Sjir: this is a major misunderstanding in my view; I assert that it is impossible to validate the contents of clause 8 if the concepts of fact and fact type are removed from Clause 8. May I expect that the proponents of dropping fact type will soon propose to stop testing computer programs?]] is removed from; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. [[Sjir: the confusion between actuality and state of affairs is another problem of concern; the fact that the great majority of systems work with state of affairs seems to be neglected. This is in my opinion an example of anti-marketing tactics as practised by some SBVR proponents.]] ; [[Sjir: needless to say that I will vote against dropping fact type from 8.1.1.]] X-SpamScore: -29 X-BigFish: PS-29(z21cILz9371Kc85fh62a3K10e3Kzz1202hzz8275bh8275dhz31h2a8h668h839h34h) X-Forefront-Antispam-Report: CIP:207.46.4.139;KIP:(null);UIP:(null);IPV:SKI;H:SN2PRD0302HT002.namprd03.prod.outlook.com;R:internal;EFV:INT From: Don Baisley To: Donald Chapin , "sbvr-rtf@omg.org" Subject: RE: issue 15623 & 14843-- SBVR RTF issue Thread-Topic: issue 15623 & 14843-- SBVR RTF issue Thread-Index: AcyftSp9JStpEP2GSZmQz2FeTdoRTwAa1WgQ Date: Fri, 11 Nov 2011 03:19:54 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.104.188.194] X-OrganizationHeadersPreserved: SN2PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%BUSINESSSEMANTICS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%OMG.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com I reviewed the draft resolution to 15623. I made some edits and added a couple of notes in the attached document. Best regards, Don From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Thursday, November 10, 2011 6:30 AM To: sbvr-rtf@omg.org Subject: RE: issue 15623 & 14843-- SBVR RTF issue Attached is a revised draft resolution for Issues 15623 & 14843 updated as per agreement in Wednesday.s telecon for release to Ballot in tomorrow.s telecon. From: Juergen Boldt [mailto:juergen@omg.org] Sent: 06 October 2010 21:20 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15623 -- SBVR RTF issue -------------------------------------------------------------------------------- From: Donald Chapin [ mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. Donald Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Draft Resolution for SBVR Issue 15623 (2011-11-10-1916).doc To: sbvr-rtf@omg.org Subject: RE: issue 15623 & 14843-- SBVR RTF issue X-KeepSent: FB1F7E5C:C4EC0501-85257945:004ADCC9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Fri, 11 Nov 2011 08:46:01 -0500 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 11/11/2011 08:46:03, Serialize complete at 11/11/2011 08:46:03 x-cbid: 11111113-5806-0000-0000-000003903078 Personally, I think that defining a mapping between (for example) "general concept" and "type of individual" adds complexity and potential for further confusion. I realize that this mapping is built into the way SBVR is constructed -- and I think it is a significant negative aspect of SBVR. Maybe there is nothing that can be done about this but we should all realize that it makes SBVR quite suspect to the logicians of the world. A few questions about these changes: Why does this propose to delete this text from the eighth paragraph of clause 10? "Formal statements of rules may be transformed into logical formulations that are used for exchange with other rules-based software tools. Informal statements of rules may be exchanged as un-interpreted comments." There is a reference to "ISO 1086" that should be to "1087". Is it legitimate to take this to ballot without the updated figures? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: Donald Chapin , "sbvr-rtf@omg.org" Date: 11/10/2011 10:34 PM Subject: RE: issue 15623 & 14843-- SBVR RTF issue -------------------------------------------------------------------------------- I reviewed the draft resolution to 15623. I made some edits and added a couple of notes in the attached document. Best regards, Don From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Thursday, November 10, 2011 6:30 AM To: sbvr-rtf@omg.org Subject: RE: issue 15623 & 14843-- SBVR RTF issue Attached is a revised draft resolution for Issues 15623 & 14843 updated as per agreement in Wednesdayâs telecon for release to Ballot in tomorrowâs telecon. From: Juergen Boldt [mailto:juergen@omg.org] Sent: 06 October 2010 21:20 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15623 -- SBVR RTF issue -------------------------------------------------------------------------------- From: Donald Chapin [ mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: âThe Signifier âFact Typeâ Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replacedâ Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: âconcept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualitiesâ has as its preferred term the signifier âfact typeâ This signifier, âfact type,â badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, âfact type,â is used as the term for a quite difference concept in Clause 10; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove âfact typeâ as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier âactuality typeâ as that is what the definition is defining. Donald Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org [attachment "Draft Resolution for SBVR Issue 15623 (2011-11-10-1916).doc" deleted by Mark H Linehan/Watson/IBM] From: "Donald Chapin" To: Subject: RE: issue 15623 -- SBVR RTF issue - Final Resolution Document Date: Mon, 14 Nov 2011 11:10:30 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyivgO2chntxTbdRvOpyL0/JB3Qjg== X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0302.4EC0F727.0006, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.11.14.94815:17:9.975, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, LINK_TO_IMAGE, __FRAUD_CONTACT_NUM, __STOCK_PHRASE_24, __FRAUD_CONTACT_NAME, __CP_URI_IN_BODY, __C230066_P5, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __IMGSPAM_BODY, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK, IMGSPAM_BODY X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4EC0F7E3.0066,ss=1,vtr=str,vl=0,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Final resolution for Issues 15623 & 14843 with all items in Meeting Notes from Friday (November 11th) SBVR RTF telecom completed. From: Juergen Boldt [mailto:juergen@omg.org] Sent: 06 October 2010 21:20 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15623 -- SBVR RTF issue -------------------------------------------------------------------------------- From: Donald Chapin [ mailto:Donald.Chapin@BusinessSemantics.com] Sent: 21 September 2010 18:21 To: 'issues@omg.org' Cc: 'sbvr-rtf@omg.org' Subject: New SBVR Issue -- "The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced" Specification Name: Semantics of Business Vocabulary and Business Rules Chapter/Section: 8.1.1 OMG Document number: formal/08-01-03 Version number: 1.0 Revision Date: January 2008 Page number(s): PDF page 33 Issue Being Reported: .The Signifier .Fact Type. Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced. Nature of Issue: Clarification Severity of Issue: Significant Full Description of the Issue: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10; thereby further increasing confusion in the SBVR specification. Recommended Resolution: Remove .fact type. as a term for the concept in SBVR Clause 8.1.1 that it currently represents, and replace it with the signifier .actuality type. as that is what the definition is defining. Donald Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org SBVR Issue 15623 Resolution 2011-11-14.doc Disposition: Resolved OMG Issue No: 15623 Title: The Signifier "Fact Type" Badly Misrepresents the Clause 8.1.1 Concept as Defined and Needs to be Replaced Source: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Summary: The concept in SBVR Clause 8.1.1 defined as: .concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities. has as its preferred term the signifier .fact type. This signifier, .fact type,. badly represents this concept and its definition. It is an example of bad term formation practice and is causing great confusion in the interpretation of the SBVR specification by contradicting the definition. Good term formation practice results in the best word or phrase that quickly and most reliably brings to mind the definition of the concept. In addition, this same signifier, .fact type,. is used as the term for a quite difference concept in Clause 10; thereby further increasing confusion in the SBVR specification. Merged from Issue 14843 The definition-based model specified in Clauses 8, 9, 10, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns: 1. Separation of the two different meanings of .fact type. into different models 2. Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption. The overt problem is that SBVR has two different meanings for .fact type.: 1. In Clause 8, the extension of a fact type is currently a set of actualities, (although another issue proposes that it should be changed to a set of states of affairs) 2. In Clause 10, the extension of a fact type is a set of facts (propositions taken to be true). The underlying issue is: 1. SBVR.s metamodel is defined in Clauses 8, 9, 10, 12 and 13. Its instances (domain models) are linguistic models of meanings. 2. The model defined in Clause 10 is included in the normative SBVR model to support a formal logic interpretation of SBVR.s metamodel. Its instances (domain models) are fact models. The proposed resolution is: 1. State, in introductory text in Clauses 8 and 10, that the models are different 2. Somewhere in Clause 10: a. List the major differences between the two models b. Describe informally what transformation would be needed to derive a domain fact model from a corresponding linguistic model. It is probably beyond the scope of this RTF to develop a formal specification 3. Define fact models to be closed world models. One of the reasons for raising this issue is the email discussion about Issue 14241 .Coexistence approach to SBVR. earlier this year. There, a case was made for allowing a fact model to be .closed world., to enable it to be used as the basis for business applications that will run on relational databases using SQL. There was some discussion that SBVR was not primarily intended to model business applications, but the business to be supported by these applications, and the models needed to be open world. When the two kinds of model are recognized as being different, both needs can be satisfied: . The linguistic model defined in Clauses 8, 9, 11, 12 and 13 is the semantic community.s open world model of its business. . The corresponding clause 10 fact model is the closed world model that is the basis for developing the data model and database for the required business applications. The transformations to these specifications are well-defined in both ORM and CogNIAM (the two fact modeling approaches described in Annexes of the SBVR Specification). One concern to be kept in mind is that the detail of specification in fact models (identifiers, data types, formats etc.) should not replicate capabilities already provided in other OMG specifications, especially UML and IMM. Resolution: The ambiguity referred to in this issue is that 'fact type': 1. is defined in Clause 8 as "concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities" 2. is used in Clause 10 with a different meaning - not formally defined, but used in the text with the meaning 'kind of facts e.g. .Employee works for Department.' (in parentheses in paragraph 3 of 10.1.1.2). When Terry Halpin was asked recently to clarify the Clause 10 meaning, he responded "A fact type is the set of all possible facts of interest, using "fact" in the sense that I gave you. In logical terms, a fact type corresponds to a set of one or more typed predicates, where I use 'predicate' in a semantic sense, rather than a syntactic sense (i.e. predicate reading)." In RTF discussion there has been some resistance to removing the signifier 'fact type' from either the SBVR metamodel (Clauses 8, 9, 11, 12, 13) or from Clause 10. If we follow SBVR's own guidance, the signifiers for the two meanings of 'fact type' need disambiguation, such as 'fact type (actualities)' and 'fact type (facts)'. The resolution is: 1. Remove the ambiguity from the term .fact type. and .object type. (Clause 10: . type of individual.) as currently used in Clause 8 and Clause 10 by distinguishing .verb concept. and .fact type.: a. Remove ambiguity surrounding the difference between the Clause 8 entry currently having the signifier .fact type. with the Clause 10 concept .fact type.: i. In Clause 8 remove ambiguity surrounding the .fact type. entry. ii. In Clause 10.1.2.1: create a formal definition of 'fact type'. based on Terry's input (as above); continuing to use 'fact type' as the signifier throughout Clause 10. b. Remove ambiguity surrounding the difference between the Clause 8 entry currently having the signifier .object type. with the Clause 10 concept .fact type.: i. In Clause 8: make 'general concept' the primary term and use 'general concept' in place of .object type. as the signifier throughout Clauses 1-9 and 11-13. ii. In Clause 10.1.2.1: create a formal definition of 'object type'. based on wording in Clause 10.1.1.2 for .type of individual.; continuing to use 'object type' as the signifier throughout Clause 10 in place of .type of individual.. 2. Describe the relationship between .verb concept. in Clause 8 and .fact type. in Clause 10 and between .general concept. in Clause 8 and .type of individual. in Clause 10 at an overview level of detail. Create a spin-off Issue to add a subclause to Subclause 10.1.1 to discuss to an appropriate level of detail all aspects of the relationship between the concepts in the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12 and the formal interpretation in Subclause 10.1.1, as well as removing ambiguity from Clause 10.1.1 by consistent use of terms intension, extension, fact population, and the set of all possible facts.. 3. Revise introductory text for Clause 10 and in Subclause 10.1.1.1 to make it clear that Clause 10 is not part of the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12, and has the purpose of providing formal interpretation / semantics for the concepts in SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12. 4. Create a spin-off Issue to correct the existing definitions in Clause 10.1.2.1 5. Update SBVR Scope-related Statements (un-styled use of .fact.) 6. Create a separate spin-off Issue to deal with the point about .defining that Clause 10 .fact models. are by default closed world models.. Revised Text: NOTE: To ensure the correct results, it is important that these editing instructions be applied in the sequence specified below. Clause 8 REMOVE the Synonym .general concept. from the entry for .object type. in Subclause 8.1.1 on printed page 20. REMOVE the Synonym .verb concept. from the entry for .fact type. in Subclause 8.1.1 on printed page 21. AND in the first Note in that same entry, REPLACE the words .For each instance of a fact type. with .Each instance of a verb concept is an actuality. For each instance.. And REPLACE the word .instance. at the end of that note with .actuality.. CHANGE the Synonym .unary fact type. from the entry for .characteristic. in Subclause 8.1.1 on printed page 21 to .unary verb concept.. In the first sentence in first paragraph of Clause 8.3.4 Fact Type Forms, REPLACE .stating facts, rules,. WITH .statements. REMOVE the Synonym .fact type reading. from the entry for .sentential form. in Subclause 8.3.4 on printed page 30. Replace Signifiers in Clauses 7 - 13 REPLACE every reference of the current signifier in Clauses 7, 8, 9, 11, 12 & 13; in Annexes A-H; and in the table in Subclause 10.2 WITH the new signifier for each of the following (in this sequence and keeping the style and capitalization the same on each individual replace): Current Signifier Replace With New Signifier .fact type role designation. .verb concept role designation. .fact type role. .verb concept role. .binary fact type. .binary verb concept. .unary fact type. .characteristic. .is-property-of fact type. .is-property-of verb concept. .fact type form. .verb concept wording. .fact type nominalization. .verb concept nominalization. .fact symbol. .verb symbol. .fact type. .verb concept. .an object type. .a general concept. .object type. .general concept. Clause 9 In the second sentence in the first paragraph of Clause 9 Logical Formulation of Semantics Vocabulary, REPLACE .facts, and rules. WITH .propositions and questions.. Clause 10 REPLACE the first paragraph immediately following the Clause 10 heading: This clause lists and explains foundational concepts taken from respected works on formal logics and mathematics. A mapping is then shown from the concepts of the SBVR Logical Formulation of Semantics Vocabulary to these foundational concepts. WITH: This clause lists and explains foundational concepts taken from respected works on formal logics and mathematics. A mapping is then shown from the concepts in the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12 to these foundational concepts. ADD the following paragraph after the first paragraph immediately following the Clause 10 heading: Clause 10.1 provides a formal semantics for the concepts in the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12. Clause 10.2 provides the mapping of the concepts in the SBVR Vocabularies in Clauses 7, 8, 9, 11 & 12 to ISO Common Logic and to OWL/ODM. MOVE the following headings to immediately precede the current second paragraph in Clause 10 that starts with .A conceptual model includes both ..: 10.1 Logical Foundations for SBVR 10.1.1 SBVR Formal Grounding Model Interpretation 10.1.1.1 Introduction REPLACE the current third paragraph of Clause 10: .Facts. are one of the primary building blocks of SBVR. A .Fact. is of a particular .Fact Type.. The lowest level logical unit in SBVR . an .Atomic Formulation. . is a logical formulation based directly upon a fact type, involving no logical operation. An atomic formulation may be considered as an invocation of a predicate. WITH: .Facts. are one of the primary building blocks of the formal interpretation of SBVR presented here. A .Ground Fact. is of a particular .Fact Type.. The lowest level logical unit in SBVR . an .Atomic Formulation. . is a logical formulation based directly upon a verb concept, involving no logical operation. An atomic formulation may be considered as an invocation of a predicate. REPLACE the current fourth paragraph of Clause 10: SBVR makes no distinction about how facts are known: for example, whether they are asserted as 'ground facts' or obtained by inference. Inferences can only be performed at one time within a particular fact model. SBVR does not define any kind of inference that can be made between fact models. WITH: The formal interpretation of SBVR presented here makes no distinction about how facts are known: for example, whether they are asserted as 'ground facts' or obtained by inference. Inferences can be performed within a particular fact model. The formal interpretation of SBVR presented here does not define any kind of inference that can be made between fact models. REPLACE the beginning of the fourth sentence in the current sixth paragraph of Clause 10: SBVR permits ... WITH: The formal interpretation of SBVR presented here permits . REPLACE the current seventh paragraph of Clause 10: The detailed definition of SBVR uses the vocabulary defined in SBVR . in other words, SBVR is defined in terms of itself. This inevitably makes the SBVR definition higher order, but this does not force any modeler to produce exclusively higher-order models. Models based on SBVR can be first order if that is what is desired by the modeler. WITH: The detailed definition of SBVR uses the vocabulary defined in SBVR . in other words, SBVR is defined in terms of itself. This inevitably makes the SBVR vocabularies higher order, but this does not force any modeler to produce exclusively higher-order models. The formal interpretation of SBVR presented here can be used to produce first order interpretations for SBVR vocabularies if that is what is desired by the modeler. REPLACE the current eighth paragraph of Clause 10: The SBVR (Semantics of Business Vocabulary and Business Rules) initiative is intended to capture business facts and business rules that may be expressed either informally or formally. Business rule expressions are classified as formal only if they are expressed purely in terms of fact types in the pre-declared schema for the business domain, as well as certain logical/ mathematical operators, quantifiers, etc. Formal statements of rules may be transformed into logical formulations that are used for exchange with other rules-based software tools. Informal statements of rules may be exchanged as un-interpreted comments. The following discussion of business rule semantics is confined to formal statements of business rules. (A closer definition of terms is given as needed later throughout this clause.) WITH: The SBVR (Semantics of Business Vocabulary and Business Rules) vocabularies are used to describe business vocabularies and business rules that may be expressed either informally or formally. Business rule expressions are classified as formal only if they are expressed purely in terms of noun concepts and verb concepts, as well as certain logical/ mathematical operators, quantifiers, etc. The following discussion of business rule semantics is confined to formal statements of business rules. (A closer definition of terms is given as needed later throughout this clause.) REPLACE the beginning of the first sentence on the current first paragraph of Subclause 10.1.1.7: The SBVR approach supports . WITH: The formal interpretation of SBVR presented here supports . ADD the following paragraph after the first paragraph in clause 10.1.1.2: SBVR.s .general concept., .individual concept. and .verb concept. are three kinds of concept (unit of knowledge created by a unique combination of characteristics [per ISO-1087-1]). Each is a kind of meaning . respectively, the meaning of an improper noun phrase, the meaning of a proper noun and the meaning of a verb phrase in the context of a declarative sentence. Instances of verb concepts are actualities that involve things that exist in the universe of discourse. These instances are not propositions. In contrast, the logical underpinnings of these three kinds of concepts are .type of individual., singleton .type of individual., and .fact type., respectively. . General concepts logically map to types of individual. Each type of individual is a set of possible instances of the general concept according to a set of possible existential facts that can be formulated based on reference schemes. . Individual concepts logically map to singleton types of individuals. Each single type of individual has exactly one element, which is the instance of the individual concept. . Verb concepts map to fact types, each fact type being a set of possible ground facts that can be formulated based on the verb concept and that use reference schemes to identify, for each fact, each thing that fills each role. In the third paragraph in 10.1.1.2, REPLACE this: The conceptual schema declares the fact types (kinds of facts, such as .Employee works for Department.) and rules relevant to the business domain. WITH this: The conceptual schema declares the concepts, fact types (kinds of facts, such as .Employee works for Department.) and rules relevant to the business domain. In the entry for .first order type. in Clause 10.1.2 on printed page 112 CHANGE .first order instances. to .first order instances. (style problem). ADD the following entry in alphabetical order into 10.1.2 (just after .domain grammar.): fact type Definition: set of all possible facts of a given kind that, in logical terms, corresponds to a set of one or more typed predicates that are semantically interchangeable except that the order of arguments may vary Example: In prefix notation the typed predicates drives(Person, Car), isDrivenBy(Car, Person), and isaDriverOf(Person, Car) could each be used for the same fact type. ADD the following entry in alphabetical order into 10.1.2 (just after .type.): type of individual Definition: type that is a set of possible individuals; kind of individual thing, e.g. Planet, CountryCode In the new section, 10.1.2.1, REMOVE the Necessity statement from the entry for .fact type is internally closed in conceptual schema.. ADD the following at the end of Clause 10.1.2.1. fact type is elementary in conceptual schema Definition: the fact type is in the conceptual schema and cannot be decomposed into a set of two or more fact types that are in the conceptual schema and that collectively have the same meaning as the fact type Synonymous Form: conceptual schema has elementary fact type REMOVE .concept classifies thing. in the row titled .concept classifies thing. of the table in Clause 10.2 on printed page 120; REMOVE the parentheses around .concept has instance. and style it as concept has instance. Clause 11 MOVE the entry for .elementary fact type. from Clause 11.1.1.2 to 10.1.2. REMOVE the following entry from Clause 11.1.1.2: fact type is elementary in body of shared meanings Definition: within the body of shared meanings, the fact type cannot be decomposed into a set of two or more fact types that collectively have the same meaning as the fact type Synonymous Form: body of shared meanings has elementary fact type Necessity: Each elementary fact type of a body of shared meanings is in the body of shared meanings. Necessity: A fact of an elementary fact type of a body of shared meanings is not equivalent to the conjunction of two or more Facts of other fact types in the body of shared meanings. Clause 13 REPLACE every reference of the current signifier in clause13 WITH the new signifier for each of the following (in this sequence and keeping the style and capitalization of the first letter the same on each individual replace . change all occurrences, including those embedded in larger signifiers): Current Signifier Replace With New Signifier .factTypeRoleDesignation. .verbConceptRoleDesignation. .factTypeRole. .verbConceptRole. .binaryFactType. .binaryVerbConcept. .factTypeForm. .verbConceptWording. .factSymbol. .verbSymbol. .factType. .verbConcept. .objectType. .generalConcept. Figures In 8.1 REPLACE Figure 8.1 with this: In 8.1.1.1 REPLACE Figure 8.2 with this: In 8.3 REPLACE Figure 8.4 with this: In 8.3.4 REPLACE Figure 8.5 with this: In 8.3.5 REPLACE Figure 8.6 with this: In 8.4 REPLACE Figure 8.7 with this: In 9.2 REPLACE Figure 9.2 with this: In 9.2.2 REPLACE Figure 9.4 with this: In 9.3 REPLACE Figure 9.12 with this: In 11.1.1 REPLACE Figure 11.1 with this: In 11.1.5 REPLACE Figure 11.5 with this: In 11.2.1 REPLACE Figure 11.6 with this: In 12.1 REPLACE Figure 12.1 with this: In 13.2.2, REPLACE this: fact type General Concept: concept Synonym: verb concept WITH this: characteristic General Concept: verb concept Synonym: unary verb concept In 13.2.2, REPLACE the first diagram (labeled .Figure:.) with this: In 13.2.2, REPLACE the second diagram (labeled .SBVR Metamodel:.) with this: In 13.2.6, REPLACE this: fact type has fact in fact model WITH this: state of affairs involves thing in role In 13.2.6, REPLACE the first diagram (labeled .Figure:.) with this: In 13.2.6, REPLACE the second diagram (labeled .SBVR Metamodel:.) with this: In 13.4 REPLACE the figure with this: In Annex B.2 REPLACE Figure B.1 with this: Annex G In G.3.1 (3rd paragraph) -- -- REPLACE this: To avoid clutter, only one reading of a fact type is shown in the graphics. The fact type is read clockwise around the line, from participating concept, to verb phrase, to (other) participating concept. Additional readings, as useful, are provided in the Vocabulary. Figure G.4 depicts two fact types, with one reading for each. WITH this: To avoid clutter, only one wording of a verb concept is shown in the graphics. The verb concept is read clockwise around the line, from participating concept, to verb phrase, to (other) participating concept. Additional wordings, as useful, are provided in the Vocabulary. Figure G.4 depicts two verb concepts, with one wording for each. in G.3.1's Figure G.4 caption -- . REPLACE this: Figure G.4 - Reading two fact types, using .defines. as a typical verb phrase WITH this: Figure G.4 - Wording two verb concepts, using .defines. as a typical verb phrase In G.3.2, 1st paragraph, REPLACE this: Where a connection involves more than two core concepts, a simple line cannot be used to represent the fact type. In this case, the fact type is shown as * with the fact type lines radiating from it to the participating concepts. The reading is placed adjacent to the * and no verbs are written on the lines. Figure G.5 illustrates a ternary fact type and one of its readings. WITH this: Where a connection involves more than two core concepts, a simple line cannot be used to represent the verb concept. In this case, the verb concept is shown as * with the verb concept lines radiating from it to the participating concepts. The wording is placed adjacent to the * and no verbs are written on the lines. Figure G.5 illustrates a ternary verb concept and one of its wordings. In G.3.4, 1st paragraph, REPLACE this: When a noun concept is defined using objectification such that it is coextensive with a fact type it is shown as a box labeled with the primary term for the noun concept. The reading of the fact type is provided in a legend (or glossary). To aid in visually distinguishing these fact type-objectifying noun concepts from other concepts, the concept name is marked with * which provides the visual clue to look in the legend/glossary. WITH this: When a noun concept is defined using objectification such that it is coextensive with a verb concept it is shown as a box labeled with the primary term for the noun concept. The wording of the verb concept is provided in a legend (or glossary). To aid in visually distinguishing these verb concept-objectifying noun concepts from other concepts, the concept name is marked with * which provides the visual clue to look in the legend/glossary. Annex H In H.3.1, 1st two paragraphs, REPLACE this: The fact type form of a binary fact type, other than one using .has., is shown as an association (a line between rectangles). If there is another fact type form for the fact type that reads in the opposite direction, only the active form is needed if the other form is the normal passive form for the same verb. Alternatively, both forms can be shown, one above the line and the other below. Either the .clockwise reading rule. or a solid triangle as an arrow can be used to show the direction of reading. Figure H.4 illustrates three alternative presentations of a binary fact type. WITH this: The verb concept wording of a binary verb concept, other than one using .has., is shown as an association (a line between rectangles). If there is another verb concept wording for the verb concept that is read in the opposite direction, only the active form of the wording is needed if the other wording is the normal passive form for the same verb. Alternatively, both wordings can be shown, one above the line and the other below. Either the .clockwise reading rule. or a solid triangle as an arrow can be used to show the direction of reading. Figure H.4 illustrates three alternative presentations of a binary verb concept. In the 1st paragraph under Figure H.5, REPLACE this: When a binary fact type.s fact type form uses .has. and there is no specialized role, the second role name is still reflected on the diagram in this consistent way (on the line adjacent to the rectangle) and .has. is not displayed. This is illustrated in Figure H.6. WITH this: When a binary verb concept.s wording uses .has. and there is no specialized role, the second role name is still reflected on the diagram in this consistent way (on the line adjacent to the rectangle) and .has. is not displayed. This is illustrated in Figure H.6. in H.3.3, 1st paragraph, REPLACE this: For fact types with more than two roles, the UML association notation is used. The primary fact type form is shown, with the placeholders underlined as shown in Figure H.7. WITH this: For verb concepts with more than two roles, the UML association notation is used. The primary verb concept wording is shown, with the placeholders underlined as shown in Figure H.7. In H.4.3 Subclause heading and 1st paragraph, REPLACE this: H.4.3 Term for a Role in a Fact Type Form When a term for a role is used in a fact type form, and that form is not an attributive form (e.g., .a has b.), then the term for the role needs to be shown. It is not shown as an association end because that would imply an attribute form (e.g., .has.). Instead, the term for the role is underlined and shown, along with the verbal part of the fact type form. WITH this: H.4.3 Term for a Role in a Verb Concept Wording When a term for a role is used in a verb concept wording, and that wording is not an attributive form (e.g., .a has b.), then the term for the role needs to be shown. It is not shown as an association end because that would imply an attribute form (e.g., .has.). Instead, the term for the role is underlined and shown, along with the verbal part of the verb concept wording. For Figure caption H.12 REPLACE this: Figure H.12- Example of a term for a role in a fact type form WITH this: Figure H.12- Example of a term for a role in a verb concept wording In H.7 2nd paragraph, REPLACE this: The diagram on the left of Figure H.16 shows the fact type forms for the partitive fact types that .body of shared meanings. is involved in... WITH this (note also that this also corrects the typo (extra punctuation) that was at the end of the sentence): The diagram on the left of Figure H.16 shows the verb concept wordings for the partitive verb concepts that .body of shared meanings. is involved in. Disposition: Resolved Donald