Issue 15124: Inconsistent use of terminology when relating facts to fact types (sbvr-rtf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type – obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A ‘Fact’ is of a particular ‘Fact Type.’ 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as “Employee works for Department”) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Resolution: Revised Text: Actions taken: March 9, 2010: received issue Discussion: End of Annotations:===== m: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don Subject: RE: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Date: Wed, 10 Mar 2010 10:38:27 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+EgAOBZsg From: "Markus Schacher" To: "Don Baisley" Cc: , X-OriginalArrivalTime: 10 Mar 2010 09:38:43.0520 (UTC) FILETIME=[7959AC00:01CAC035] Don, When I look at this from a fresh (predicate logic and/or Prolog) perspective, I have to say that I think that facts are a kind of rules and rules are a kind of fact types(!) and both are formulated using fact types. Here is why: What is the difference between the following sentences (facts, rules or whatever), all using the fact type "person works": - Markus works. - (It is obligatory that) Markus works, if it is not Sunday. - (It is permitted that) Some people work. - (It is permitted that) Some people work, (even) if it is Sunday. The deontic parts are not so relevant here, but all sentences are propositions that may be asserted, i.e. declared to be true (in some UoD). The first sentence represents an atomic formula, whereas the others represent non-atomic formulas. And I think that a rule is nothing else than a non-atomic formula declared to be true (in some UoD). Best regards, Markus -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: Mittwoch, 10. Mä 2010 03:36 To: issues@omg.org; 'SBVR RTF' (sbvr-rtf@omg.org) Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:X-MimeOLE; b=bB/eTBgwSW5kgqGWETnIwaBFxOucrSm76GC+KAPSmx57qCHyG1gZovTLgq6tvm99iHonooW7MfG6p/5DOB/JneP9wiYKxSfIKGDyp7cNuKxFtegmeK9zui2OWjI1dcLjD7Y9qz5BSOsc1E+5SJ9PGmPKsmbvPUyXDX+pLn4uF+I= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=s1024; t=1269512338; bh=z7zkF/jO2wTI3CTpaVDYowlZDYn+S3lEpZ/bieqoyhw=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:X-MimeOLE; b=VApGtsQTL268xBbIS8VWNCUnpM6eHuit3MDqKyswgDU9csbWZk81FEZq6Spgk6JLZ4hREt+rE0fEMneJVnOl+AyQSkonooi929Y52roUo75+lbWft2PppP4sq/EvN7Xy++QFSQQMTmC78gIqVnZSs3iiH5yEGUKlDzyQdrzgk/s= X-Yahoo-SMTP: ipAFRh2swBALpDiVMXIwBxwhmA51J31AV6tKcA.nNICCSy6cH9UoQMM- X-YMail-OSG: SKz9uUYVM1lM_pH98SEPStOQRrWpET4Ff2zhE_wVADmCsRvfNIztDV8Kj89SPhXs4mLHoWKTbfKjQkyOOJQ8A5HwUIZGn6FFjMawrInsgiycHWJ8aFNVqmWHvyCVBi5hd2h4bDs0DmP9OL0XGMiXSacvU50naMna5nNZv32KEvDMbzUmT1wGyMSyYDMgzqLH9MMhliWmx0NBETmhdoRHS6gcj1xmBxhhDeQR14fwU4SsWQACb1W_i5KtX3aUTZ4W8ARkd_FjMI8- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: FW: issue 15124 -- SBVR RTF issue -- Removing the Fact Instance of Fact Type Relationship in the SBVR Clause 10 Formal Interpretation Date: Thu, 25 Mar 2010 06:18:53 -0400 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrAcUEhz/AIo7adS56sYsW3EMUKvgKzHJ1gACGDCLAAEBx7YA== An assessment by Terry Halpin of Issue 15124.s proposed changes to the formal interpretation in Clause 10. Donald -------------------------------------------------------------------------------- From: Terry Halpin [mailto:terry.halpin@logicblox.com] Sent: 25 March 2010 00:58 To: Donald.Chapin@btinternet.com Cc: sjir.nijssen@pna-group.nl Subject: RE: issue 15124 -- SBVR RTF issue -- Removing the Fact Instance of Fact Type Relationship in the SBVR Clause 10 Formal Interpretation Hi Donald It.s been quite a while since I.ve carefully examined the SBVR specification. I seem to recall a discussion with Don Baisley a couple of years ago about what fact instances really are, but I can.t remember the details of that discussion. Here are some comments on Don.s statements, numbered for ease of reference. I.m copying this to Sjir, as I expect he shares your concerns. 1. .SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc.. Whether or not this is true depends on how one defines .fact. and .fact type.. Essentially, I still regard a fact to be a proposition that is taken to be true by the relevant business community, but by default I restrict this notion further so that the facts are at the ground level (where quantification and predication is over individuals, not types). Here I.m using .individual. in the logical sense to mean any (ground) thing/object (e.g. an entity or value) of interest. This lets me make a convenient distinction between (ground) facts (e.g. The Country named .Australia. is large), constraints (e.g. Each Person was born in at most one Country), and derivation rules (e.g. For each Person1 and Person2, Person1 is a grandparent of Person2 iff Person1 is a parent of some Person3 who is a parent of Person2). Here I.m using an ORM syntax where object type names start with a capital letter, but other syntaxes may be used (e.g. underline object type names). Subscripts are used to distinguish object variables of the same type. I further distinguish (ground) atomic facts (either existential or elementary) from compound/complex facts. An existential fact simply asserts the existence of an individual, e.g. There exists a Country named .Australia. (adding constraints to the name relationship to make it an injection from Country to CountryName results in a definite description, so we then have .There exists exactly one Country that has the CountryName .Australia., and that Country has at most one CountryName). An elementary fact is expressed as a predication over one or more individuals (e.g. The Politician named .Kevin Rudd. was born in the Country named .Australia.), where the fact cannot be split into (rendered as a conjunction of) two more simpler facts involving the same object types without loss of information. A compound fact is for me a conjunction of two or more facts. A fact may be (simply) asserted or derived (from other facts). In modeling, I restrict asserted facts to atomic facts. I do not assert complex facts that may include logical operators other than .and.. For example, I do not assert negations (e.g. The Politician named .Kevin Rudd. is not female) or disjunctions (e.g. The Politician named .Kevin Rudd. is intelligent or industrious). Often however, such complex facts may be derived from other facts. Elementary facts may be regarded as instances of fact types. An elementary fact type corresponds to a set of one or more typed predicates. For example, the fact expressed by the sentence .The Politician named .Kevin Rudd. governs the Country named .Australia.. is an instance of the fact type Politician governs Country. The same fact may be expressed by the sentence .The Country named .Australia. is governed by the Politician named .Kevin Rudd.. which is an instance of the same fact type, this time represented by the fact type reading .Country is governed by Politician.. If these are the only two readings for the fact type, the fact type may be specified by the following set of typed predicates {governs(Politician, Country), isGovernedBy(Country, Politician)}. Returning to Don.s statement above, if he is using .fact. to include disjunctions etc., then I agree. 2. .SBVR makes clear that instances of fact types are actualities, not facts.. I don.t remember the discussion on this, but currently I don.t see why some facts cannot be instances of fact types. For example, my discussion above treats elementary facts as instances of elementary fact types. Facts (in the sense of propositions taken to be true by the business) can be true or false, but actualities can.t be true or false (e.g. a state of affairs can happen, but can.t be true). 3. SBVR describes concepts as having instances, but not facts as having instances. If Don meant to say .fact types. here instead of .facts., then I disagree that some fact types cannot have instances. If he really meant .facts., I can.t make sense of what he is saying here. Regarding Don.s 4 suggested changes, I could accept changes 1, 2 and 4 below, and even 3 (although .and other concepts. seems nebulous), because they do not exclude the possibility of treating some facts as instances of fact types. However if somewhere else in the SBVR document this possibility is excluded, then I don.t currently agree with that prohibition. At any rate, it might be worthwhile somewhere in the SBVR document to discuss different senses of the term .fact. and make it clear when the term .fact. is used in a more restrictive sense (e.g. ground level, atomic, etc.) or a more general sense. This is all I have time for, as I have a bunch of deliverables to complete before I fly back to Australia on Sunday. I hope this has been of some help. Cheers Terry From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Wednesday, March 24, 2010 6:44 PM To: 'Terry Halpin' Subject: FW: issue 15124 -- SBVR RTF issue -- Removing the Fact Instance of Fact Type Relationship in the SBVR Clause 10 Formal Interpretation Importance: High Hi Terry, It seems to me that the integrity of the SBVR Clause 10 formal interpretation that you agreed with Pat Hayes would be broken if we were to make the change to remove the relationship of facts being instances of fact types that Don recommends below. It is very important that we maintain the integrity of our Clause 10 formal logic interpretation if we are to get the Architecture Board.s approval for SBVR 1.1. What is your assessment of the changes Don is proposing? We have an SBVR RTF meeting in 26 hours where this will be discussed. It would help greatly to have your feedback by then. Many thanks, Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 10 March 2010 11:46 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15124 -- SBVR RTF issue From: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don 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 From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: issue 15124 -- SBVR RTF issue -- Inconsistent use of terminology when relating facts to fact types Thread-Topic: issue 15124 -- SBVR RTF issue -- Inconsistent use of terminology when relating facts to fact types Thread-Index: AcrMgQL5gcj14nbzTxiQAj6iD9Gl2w== Date: Fri, 26 Mar 2010 02:01:45 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: I have read Terry.s analysis of my proposed edits that fix some inconsistent use of terminology. You can read my responses to some of Terry.s comments below. Terry.s conclusion regarding my proposed changes is this: > Regarding Don.s 4 suggested changes, I could accept changes 1, 2 and 4 below, and even 3 (although .and other > concepts. seems nebulous), because they do not exclude the possibility of treating some facts as instances of fact types. The words .and other concepts. in change 3 are used because semantic formulations involve not only fact types, but other concepts as well. For example, a quantified variable tends to range over an object type, and some bindings are to individual concepts. If people prefer to leave out .and other concepts., then that.s fine. Just say so. The changes will make SBVR consistent within itself in its use of the word .instance.. That word is used with its defined meaning hundreds of times throughout the SBVR specification. Since it was a defined term, authors had been careful and there was very little inconsistency that needed correction. That.s why the proposed resolution to this issue is small. However, it is clear from Terry.s remarks that he sometimes uses the word .instance. in a different sense. Adding that different sense with a new definition and/or signifier is out of scope for this issue. Given that Terry can accept the four changes, I move that we all decide to move forward on resolving the issue. If there is agreement, I can prepare a document. Just let me know. Thanks, Don From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Thursday, March 25, 2010 3:19 AM To: sbvr-rtf@omg.org Subject: FW: issue 15124 -- SBVR RTF issue -- Removing the Fact Instance of Fact Type Relationship in the SBVR Clause 10 Formal Interpretation An assessment by Terry Halpin of Issue 15124.s proposed changes to the formal interpretation in Clause 10. Donald -------------------------------------------------------------------------------- From: Terry Halpin [mailto:terry.halpin@logicblox.com] Sent: 25 March 2010 00:58 To: Donald.Chapin@btinternet.com Cc: sjir.nijssen@pna-group.nl Subject: RE: issue 15124 -- SBVR RTF issue -- Removing the Fact Instance of Fact Type Relationship in the SBVR Clause 10 Formal Interpretation Hi Donald It.s been quite a while since I.ve carefully examined the SBVR specification. I seem to recall a discussion with Don Baisley a couple of years ago about what fact instances really are, but I can.t remember the details of that discussion. Here are some comments on Don.s statements, numbered for ease of reference. I.m copying this to Sjir, as I expect he shares your concerns. 1. .SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc.. Whether or not this is true depends on how one defines .fact. and .fact type.. Essentially, I still regard a fact to be a proposition that is taken to be true by the relevant business community, but by default I restrict this notion further so that the facts are at the ground level (where quantification and predication is over individuals, not types). Here I.m using .individual. in the logical sense to mean any (ground) thing/object (e.g. an entity or value) of interest. This lets me make a convenient distinction between (ground) facts (e.g. The Country named .Australia. is large), constraints (e.g. Each Person was born in at most one Country), and derivation rules (e.g. For each Person1 and Person2, Person1 is a grandparent of Person2 iff Person1 is a parent of some Person3 who is a parent of Person2). Here I.m using an ORM syntax where object type names start with a capital letter, but other syntaxes may be used (e.g. underline object type names). Subscripts are used to distinguish object variables of the same type. I further distinguish (ground) atomic facts (either existential or elementary) from compound/complex facts. An existential fact simply asserts the existence of an individual, e.g. There exists a Country named .Australia. (adding constraints to the name relationship to make it an injection from Country to CountryName results in a definite description, so we then have .There exists exactly one Country that has the CountryName .Australia., and that Country has at most one CountryName). An elementary fact is expressed as a predication over one or more individuals (e.g. The Politician named .Kevin Rudd. was born in the Country named .Australia.), where the fact cannot be split into (rendered as a conjunction of) two more simpler facts involving the same object types without loss of information. A compound fact is for me a conjunction of two or more facts. A fact may be (simply) asserted or derived (from other facts). In modeling, I restrict asserted facts to atomic facts. I do not assert complex facts that may include logical operators other than .and.. For example, I do not assert negations (e.g. The Politician named .Kevin Rudd. is not female) or disjunctions (e.g. The Politician named .Kevin Rudd. is intelligent or industrious). Often however, such complex facts may be derived from other facts. Elementary facts may be regarded as instances of fact types. An elementary fact type corresponds to a set of one or more typed predicates. For example, the fact expressed by the sentence .The Politician named .Kevin Rudd. governs the Country named .Australia.. is an instance of the fact type Politician governs Country. The same fact may be expressed by the sentence .The Country named .Australia. is governed by the Politician named .Kevin Rudd.. which is an instance of the same fact type, this time represented by the fact type reading .Country is governed by Politician.. If these are the only two readings for the fact type, the fact type may be specified by the following set of typed predicates {governs(Politician, Country), isGovernedBy(Country, Politician)}. Returning to Don.s statement above, if he is using .fact. to include disjunctions etc., then I agree. [Then we agree. I use .fact. as defined by SBVR, .proposition that is taken as true.. That defined meaning does not exclude disjunctions, etc. -- Don ] 2. .SBVR makes clear that instances of fact types are actualities, not facts.. I don.t remember the discussion on this, but currently I don.t see why some facts cannot be instances of fact types. For example, my discussion above treats elementary facts as instances of elementary fact types. Facts (in the sense of propositions taken to be true by the business) can be true or false, but actualities can.t be true or false (e.g. a state of affairs can happen, but can.t be true). [Saying a fact is an .instance. of a fact type uses a different meaning of .instance. than what is defined in SBVR. SBVR.s use of .instance. is for the .corresponds to. relation that connects meanings to elements of their extensions in a universe of discourse. The other meaning of .instance., which is not part of SBVR, is about formulation. If there is a need to add to SBVR a definition for that separate meaning, that need should be addressed by a separate issue. -- Don ] 3. SBVR describes concepts as having instances, but not facts as having instances. If Don meant to say .fact types. here instead of .facts., then I disagree that some fact types cannot have instances. If he really meant .facts., I can.t make sense of what he is saying here. [Then we agree. I did not mean to say .fact types.. I meant what I said: SBVR does not describe facts as having instances (which would make no sense). That.s why we are clarifying some wording that might lead people to think otherwise. -- Don ] Regarding Don.s 4 suggested changes, I could accept changes 1, 2 and 4 below, and even 3 (although .and other concepts. seems nebulous), because they do not exclude the possibility of treating some facts as instances of fact types. However if somewhere else in the SBVR document this possibility is excluded, then I don.t currently agree with that prohibition. At any rate, it might be worthwhile somewhere in the SBVR document to discuss different senses of the term .fact. and make it clear when the term .fact. is used in a more restrictive sense (e.g. ground level, atomic, etc.) or a more general sense. [.Fact. is defined in exactly one way in SBVR. If there is a need for more restrictive concepts, those could be defined as specializations of .fact. and would need their own signifiers. But that is out of scope for this issue. -- Don ] This is all I have time for, as I have a bunch of deliverables to complete before I fly back to Australia on Sunday. I hope this has been of some help. Cheers Terry From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Wednesday, March 24, 2010 6:44 PM To: 'Terry Halpin' Subject: FW: issue 15124 -- SBVR RTF issue -- Removing the Fact Instance of Fact Type Relationship in the SBVR Clause 10 Formal Interpretation Importance: High Hi Terry, It seems to me that the integrity of the SBVR Clause 10 formal interpretation that you agreed with Pat Hayes would be broken if we were to make the change to remove the relationship of facts being instances of fact types that Don recommends below. It is very important that we maintain the integrity of our Clause 10 formal logic interpretation if we are to get the Architecture Board.s approval for SBVR 1.1. What is your assessment of the changes Don is proposing? We have an SBVR RTF meeting in 26 hours where this will be discussed. It would help greatly to have your feedback by then. Many thanks, Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 10 March 2010 11:46 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15124 -- SBVR RTF issue From: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don 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 Date: Wed, 10 Mar 2010 12:40:31 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Markus Schacher CC: "sbvr-rtf@omg.org" Subject: Re: SBVR Issue: Inconsistent use of terminology when relating facts to fact types X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o2AHeap2019634 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1268847637.66406@xeeakJjr1xmZpExDN+DKRg X-Spam-Status: No Markus wrote: Don, When I look at this from a fresh (predicate logic and/or Prolog) perspective, I have to say that I think that facts are a kind of rules and rules are a kind of fact types(!) and both are formulated using fact types. Here is why: Well, let us start by observing that a problem with Clause 10 is that it doesn't clearly take one of these views. The formal concepts are instead raised in terms of the business rules and information modeling concepts. But Markus is quite right that a 'conceptual schema' is a kind of 'fact model', and every statement in a conceptual schema or a fact model is an _assertion_ -- a statement of a proposition that is to be taken to be true. In the Nijssen/Halpin papers, a 'conceptual schema' consists solely of Necessities -- statements that are taken to be true in all possible worlds (what Sjir called 'invariants' in 1984). What is the difference between the following sentences (facts, rules or whatever), all using the fact type "person works": - Markus works. - (It is obligatory that) Markus works, if it is not Sunday. - (It is permitted that) Some people work. - (It is permitted that) Some people work, (even) if it is Sunday. The deontic parts are not so relevant here, but all sentences are propositions that may be asserted, i.e. declared to be true (in some UoD). The first sentence represents an atomic formula, whereas the others represent non-atomic formulas. And I think that a rule is nothing else than a non-atomic formula declared to be true (in some UoD). I fully agree. Operational rules -- obligations, prohibitions and permissions -- are an addition to the traditional notion of 'conceptual schema', but they have the same property. A rule is a proposition that is asserted (taken to be true) in a fact model that represents a body of guidance. We need to understand at least three ideas: 1) 'proposition is obligated to be true' is a fact type about propositions. So It is obligatory that Markus works if it is not Sunday means 'that Markus works if it is not Sunday' is obligated to be true. The rule is a fact that based on the fact type: 'proposition is obligated to be true'. It happens that clause 9 uses a formulation of this rule that is not an atomic formulation of a unary fact about a proposition nominalization, but it could. The special semantics is in the fact type. The rule is just a fact of this type. 2) Not all fact types have names and not all noun concepts have names. Every closed projection involving (role) variables can be seen a formulating a concept, and if it involves multiple variables, that concept must be a fact type. Put another way, fact types and noun concepts can both be designated by their definitions. So, the fact type: 'person' 'works on each day that is not Sunday' is the basis for Markus works, if it is not Sunday, even if it is not in the vocabulary/schema. E.g. the vocabulary entry might be: person works on day I understand that Markus was trying to formulate an implication, but from the date-time work, I had a problem with the "it" in "it is not Sunday". Perhaps a better example would be: Markus works, even when it rains. This can be seen as based on a fact type involving two roles: person, weather, viz.: person works, whether or not the weather is rain. And such a fact type will not appear in the vocabulary per se. So the general idea is valid: a fact can always be said to be an instance of a pattern (a fact type form) after we decide what things in the fact are to be considered to be playing roles. At the last meeting, however, we said that there is a kind of 'atomic fact' notion -- a fact that is formulated as an atomic formulation using a fact type defined in the conceptual schema that governs the fact model. With that notion, Markus works, even when it rains is not an atomic fact, but Markus works on each day that is not Sunday might be an atomic fact if either person works on day or state of affairs occurs at time is in the vocabulary. The latter gives rise to: the state of affairs -- that Markus works -- occurs on each day that is not Sunday 'each day that is not Sunday' designates/defines a noun concept that specializes 'time'. 3) Antoine's observation: A fact is an actuality interpreted by a fact type. We can now say that this is not quite correct, if we think 'fact type' means a fact type defined in the conceptual schema. What Antoine means is: A fact is a conceptualization of an actuality that is based on specific concepts (object types and fact types) in a concept model. Finally, note also that while we have vocabulary that turns rules into atomic formulations, we don't have a similar means of dealing with Markus's quantification: Some people work, even when it is Sunday. The logical formulation is: There exists a 'person' who 'works whether or not the day is Sunday'. I suppose one could argue that we do have a basis fact type for this as well, to wit: The cardinality of the extension of the noun concept -- person who 'works whether or not the day is Sunday' -- is greater than or equal to 1. I don't like this, for more than one reason. But in a certain sense, it is just assigning special significance to the role type* 'number that is the cardinality of the extension of (a given) concept', which is just like assigning special significance to the fact type 'proposition is obligated to be true'. -Ed *SBVR has muddled the Halpin 'role type' concept, but I have given up on trying to fix that. We can sort it out in our tools. -- 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." From: Don Baisley To: Markus Schacher CC: "sbvr-rtf@omg.org" , "issues@omg.org" Subject: RE: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+EgAOBZsgABLFCFA= Date: Wed, 10 Mar 2010 18:26:54 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Hi Markus, It is certainly true that facts and other propositions, including rules, are formulated using fact types. Many propositions are formulated using multiple fact types, combined using various sorts of semantic formulations. Also, it is possible to formulate a proposition using no fact type (E.g., There exists at least one person.). You are correct that a difference between a rule and another proposition can be nothing more than a modal operation. Either can be asserted to be a fact. Best regards, Don From: Markus Schacher [mailto:markus.schacher@knowgravity.com] Sent: Wednesday, March 10, 2010 1:38 AM To: Don Baisley Cc: sbvr-rtf@omg.org; issues@omg.org Subject: RE: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Don, When I look at this from a fresh (predicate logic and/or Prolog) perspective, I have to say that I think that facts are a kind of rules and rules are a kind of fact types(!) and both are formulated using fact types. Here is why: What is the difference between the following sentences (facts, rules or whatever), all using the fact type "person works": - Markus works. - (It is obligatory that) Markus works, if it is not Sunday. - (It is permitted that) Some people work. - (It is permitted that) Some people work, (even) if it is Sunday. The deontic parts are not so relevant here, but all sentences are propositions that may be asserted, i.e. declared to be true (in some UoD). The first sentence represents an atomic formula, whereas the others represent non-atomic formulas. And I think that a rule is nothing else than a non-atomic formula declared to be true (in some UoD). Best regards, Markus -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: Mittwoch, 10. Mä 2010 03:36 To: issues@omg.org; 'SBVR RTF' (sbvr-rtf@omg.org) Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don Subject: RE: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Date: Wed, 10 Mar 2010 22:57:34 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+EgAOBZsgABLFCFAABYDCwA== From: "Markus Schacher" To: "Don Baisley" Cc: , X-OriginalArrivalTime: 10 Mar 2010 21:57:52.0300 (UTC) FILETIME=[BB4876C0:01CAC09C] Hi Don, Actually, I realized that I've made a fatal error: I meant *facts are a kind of rules* and *rules are a kind of facts* (not fact types). Or event stronger: rules and facts are the same thing! But anyway, the whole thing is true even without any modal operators. What I meant is the following: If we have the following UoD: ========== Any car is an electric car, if that car is powered by an electric motor. Tesla is an electric car. Prius is powered by an electric motor. Hummer is driven by a gasoline engine. ========== In Prolog, this could be formulated as follows: ========== electric_car(Car) :- powered_by(Car, 'electric motor'). electric_car('Tesla'). powered_by('Prius', 'electric motor'). powered_by('Hummer', 'gasoline engine'). ========== This corresponds to the following *single* predicate logic expression: ========== FORALL X IN (electric_car(X) OR NOT powered_by(X, 'electric motor')) AND electric_car('Tesla') AND powered_by('Prius', 'electric motor') AND powered_by('Hummer', 'gasoline engine'). ========== Which is the same as: ========== FORALL X IN (electric_car(X) OR NOT powered_by(X, 'electric motor') AND electric_car('Tesla') AND powered_by('Prius', 'electric motor') AND powered_by('Hummer', 'gasoline engine')). ========== This single expression is formulated using the predicates (or fact types) electric_car/1 and powered_by/2. They could be renamed to a/1 and b/2 (e.g. for a different speech community), which would result in the following expression describing the same (or a similar?) UoD: ========== FORALL X IN (a(X) OR NOT b(X, 'electric motor') AND a('Tesla') AND b('Prius', 'electric motor') AND b('Hummer', 'gasoline engine')). ========== What are now the facts and what the rules? Best regards, Markus -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: Mittwoch, 10. Mä 2010 19:27 To: Markus Schacher Cc: sbvr-rtf@omg.org; issues@omg.org Subject: RE: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Hi Markus, It is certainly true that facts and other propositions, including rules, are formulated using fact types. Many propositions are formulated using multiple fact types, combined using various sorts of semantic formulations. Also, it is possible to formulate a proposition using no fact type (E.g., There exists at least one person.). You are correct that a difference between a rule and another proposition can be nothing more than a modal operation. Either can be asserted to be a fact. Best regards, Don From: Markus Schacher [mailto:markus.schacher@knowgravity.com] Sent: Wednesday, March 10, 2010 1:38 AM To: Don Baisley Cc: sbvr-rtf@omg.org; issues@omg.org Subject: RE: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Don, When I look at this from a fresh (predicate logic and/or Prolog) perspective, I have to say that I think that facts are a kind of rules and rules are a kind of fact types(!) and both are formulated using fact types. Here is why: What is the difference between the following sentences (facts, rules or whatever), all using the fact type "person works": - Markus works. - (It is obligatory that) Markus works, if it is not Sunday. - (It is permitted that) Some people work. - (It is permitted that) Some people work, (even) if it is Sunday. The deontic parts are not so relevant here, but all sentences are propositions that may be asserted, i.e. declared to be true (in some UoD). The first sentence represents an atomic formula, whereas the others represent non-atomic formulas. And I think that a rule is nothing else than a non-atomic formula declared to be true (in some UoD). Best regards, Markus -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: Mittwoch, 10. Mä 2010 03:36 To: issues@omg.org; 'SBVR RTF' (sbvr-rtf@omg.org) Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:In-Reply-To:Thread-Index:X-MimeOLE; b=5jMLsAPBWaj/nphI08MhCWN8CqmLnc/Q0btivxmlQu4fHVB8vSSsvkXuFYigqTj14LmXoSCjUspG7DzuibwJPQhO88r6SSZjWWBP+cFgtrza+kBFaLVOfTUUdKgyLCTRX+PchdRMQ6slaa/jSemQWN/x34IIsdaYrPrbC4NSwUI= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=s1024; t=1269437977; bh=GCFClp3u/Aw/Gwc12K7MQTT+31LAeEWm9c4kxYHK16M=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:In-Reply-To:Thread-Index:X-MimeOLE; b=I2rwirABgQvuAFyPf5NdHtppYv3ZjoduNslvnqA5KDSKGjoU2x4VwiIHbuQKJaUghMsdxuMchRgJQeVeaMhulI/KMDetk05IqeAWfFxCHl8xDYJ+le/fI7GgvCF4piGrfOsRlDEPgjMwh6P4N9lJmSliz1e3MhzG86iaatoLVWY= X-Yahoo-SMTP: ipAFRh2swBALpDiVMXIwBxwhmA51J31AV6tKcA.nNICCSy6cH9UoQMM- X-YMail-OSG: yBvEe80VM1mQJf6r4_BJX.Bus3LMvciN4s95.3z147k9v1HzeUgrqSlm1vCOrHzDjuoV.i0G8xxGUyiGZDu42k9WN6anQMJq1zswXZDgETLlDn2iz5diAL16yFdO7vsGb6w_4JuW3YSvyymK0Hy3X0y9FR9lQcZQwnMmtE1ORXZ1PMVboQ6DP3Go23GTCgGyfVvvE3VGcFplXU3JKgkZetdPT9QVYfy9Zgs87NxDaeI7jKOqRLV0zv3EzoVQbwTHl8QUgvOzK.A- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: "'Markus Schacher'" Cc: , Subject: RE: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Date: Wed, 24 Mar 2010 09:39:36 -0400 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+EgAOBZsgAsjhBDA= Markus, Whether or not .fact. and .rule. are the same concept is a different Issue from Issue 15124, which is about removing the .Fact is instance of Fact Type. relationship from Clause 10. If you would like the SBVR RTF to address your Issue, it needs to be submitted as new Issue. Thanks, Donald -------------------------------------------------------------------------------- From: Markus Schacher [mailto:markus.schacher@knowgravity.com] Sent: 10 March 2010 04:38 To: Don Baisley Cc: sbvr-rtf@omg.org; issues@omg.org Subject: RE: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Don, When I look at this from a fresh (predicate logic and/or Prolog) perspective, I have to say that I think that facts are a kind of rules and rules are a kind of fact types(!) and both are formulated using fact types. Here is why: What is the difference between the following sentences (facts, rules or whatever), all using the fact type "person works": - Markus works. - (It is obligatory that) Markus works, if it is not Sunday. - (It is permitted that) Some people work. - (It is permitted that) Some people work, (even) if it is Sunday. The deontic parts are not so relevant here, but all sentences are propositions that may be asserted, i.e. declared to be true (in some UoD). The first sentence represents an atomic formula, whereas the others represent non-atomic formulas. And I think that a rule is nothing else than a non-atomic formula declared to be true (in some UoD). Best regards, Markus -------------------------------------------------------------------------------- From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: Mittwoch, 10. Mä 2010 03:36 To: issues@omg.org; 'SBVR RTF' (sbvr-rtf@omg.org) Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: issue 15124 -- SBVR RTF issue Thread-Topic: issue 15124 -- SBVR RTF issue Thread-Index: AQHKwHICliMVKWQtGUWqJBkBdHyRt5KTxdow Date: Fri, 25 Jun 2010 20:22:29 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: We discussed part of the recommended resolution to issue 15124 in yesterday.s RTF meeting. Some changes to the rewordings were recommended, which are captured in the attached document. Also, we noted that there is inconsistency in the use of the word .population. in clause 10. I highlighted a note about the inconsistency in the attached document. We need to agree on a solution. Once agreed, we can complete the resolution. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, March 10, 2010 8:46 AM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15124 -- SBVR RTF issue From: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don 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 Issue 15124.doc OMG Issue No: 15124 Title: Inconsistent use of terminology when relating facts to fact types Source: Don Baisley Summary: It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Resolution: Fix the inconsistent use of terms while retaining the intended content. Revised Text: 1. In the third paragraph of the introduction to clause 10, REPLACE the sentence that says: A .Fact. is of a particular .Fact Type.. With this: Each .Elementary Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground facts formulated using the concepts in the schema. 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Disposition: Resolved To: sbvr-rtf@omg.org Subject: RE: issue 15124 -- SBVR RTF issue X-KeepSent: DF276B72:2ACC7A62-85257750:0046966F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Mon, 28 Jun 2010 09:36:54 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/28/2010 09:36:55, Serialize complete at 06/28/2010 09:36:55 I note that the terms "fact model population" and "domain model population" are also used in 8.5 in the note under "fact type is internally closed in conceptual schema ". We should align this note with the definition we decide for "population". "Fact" is used (instead of "actuality") in the definition of that verb concept and also in "concept is closed in conceptual schema ". Should this be addressed in another issue, or in 15124? I am certainly in favor of disentangling different meanings of "population", and I think "extension" is a well-defined term that we should use when it is appropriate. Regarding the three possible meanings of "population" -- rather than use "population" alone, how about making three terms using the pattern "xxx population". For example (following Don's numbered possibilities): (1) "fact model population", (2) "existential fact population"; (3) "elementary fact population". I think we should go further, and align the uses of the term "fact" in clause 10 with "fact" and "actuality" as used in clauses 8, 9, 11, 12. I think the idea of a mapping between clause 10 and the rest of the document is terrible -- the specification should be self-consistent throughout. I think the way to start down this path is to change "fact" to "actuality" in clause 10 where that is what is meant. Then we can see whether the remaining uses of "fact" are still inconsistent with the rest of the specification. Note that I am not suggesting changes to the meaning of clause 10, but just correcting the terms to fit the rest of the spec. I note that an "actuality" asserted in a conceptual model is also a "fact". For example, an individual concept is an actuality that the concept is in the extension of some general concept, and that actuality is taken as true. The same would be true of what should be called an "individual verb concept", meaning an individual concept that is an instance of a fact type. So some actualities are also facts. Similarly, the mere assertion of concepts and elements of guidance indicates that they are "taken as true" and hence are facts but not actualities. In other words, the relationship between facts and actualities is one of overlapping circles in a Venn diagram. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley 06/25/2010 04:22 PM To "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue We discussed part of the recommended resolution to issue 15124 in yesterdayâs RTF meeting. Some changes to the rewordings were recommended, which are captured in the attached document. Also, we noted that there is inconsistency in the use of the word âpopulationâ in clause 10. I highlighted a note about the inconsistency in the attached document. We need to agree on a solution. Once agreed, we can complete the resolution. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, March 10, 2010 8:46 AM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15124 -- SBVR RTF issue From: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A âFactâ is of a particular âFact Type.â 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as âEmployee works for Departmentâ) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don 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 "Issue 15124.doc" deleted by Mark H Linehan/Watson/IBM] From: Don Baisley To: Mark H Linehan , "sbvr-rtf@omg.org" Subject: RE: issue 15124 -- SBVR RTF issue Thread-Topic: issue 15124 -- SBVR RTF issue Thread-Index: AQHKwHICliMVKWQtGUWqJBkBdHyRt5KTxdowgAS8iwD//7nm4A== Date: Mon, 28 Jun 2010 16:41:42 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Hi Mark, I.m glad you agree on cleaning up the use of .population.. I could not make sense of your last paragraph below. Propositions are asserted, not actualities. I didn.t notice clause 10 having uses of .fact. that meant .actuality.. If you see any, please let us know. Thanks, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, June 28, 2010 6:37 AM To: sbvr-rtf@omg.org Subject: RE: issue 15124 -- SBVR RTF issue I note that the terms "fact model population" and "domain model population" are also used in 8.5 in the note under "fact type is internally closed in conceptual schema ". We should align this note with the definition we decide for "population". "Fact" is used (instead of "actuality") in the definition of that verb concept and also in "concept is closed in conceptual schema ". Should this be addressed in another issue, or in 15124? I am certainly in favor of disentangling different meanings of "population", and I think "extension" is a well-defined term that we should use when it is appropriate. Regarding the three possible meanings of "population" -- rather than use "population" alone, how about making three terms using the pattern "xxx population". For example (following Don's numbered possibilities): (1) "fact model population", (2) "existential fact population"; (3) "elementary fact population". I think we should go further, and align the uses of the term "fact" in clause 10 with "fact" and "actuality" as used in clauses 8, 9, 11, 12. I think the idea of a mapping between clause 10 and the rest of the document is terrible -- the specification should be self-consistent throughout. I think the way to start down this path is to change "fact" to "actuality" in clause 10 where that is what is meant. Then we can see whether the remaining uses of "fact" are still inconsistent with the rest of the specification. Note that I am not suggesting changes to the meaning of clause 10, but just correcting the terms to fit the rest of the spec. I note that an "actuality" asserted in a conceptual model is also a "fact". For example, an individual concept is an actuality that the concept is in the extension of some general concept, and that actuality is taken as true. The same would be true of what should be called an "individual verb concept", meaning an individual concept that is an instance of a fact type. So some actualities are also facts. Similarly, the mere assertion of concepts and elements of guidance indicates that they are "taken as true" and hence are facts but not actualities. In other words, the relationship between facts and actualities is one of overlapping circles in a Venn diagram. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley 06/25/2010 04:22 PM To "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue We discussed part of the recommended resolution to issue 15124 in yesterday.s RTF meeting. Some changes to the rewordings were recommended, which are captured in the attached document. Also, we noted that there is inconsistency in the use of the word .population. in clause 10. I highlighted a note about the inconsistency in the attached document. We need to agree on a solution. Once agreed, we can complete the resolution. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, March 10, 2010 8:46 AM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15124 -- SBVR RTF issue From: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, soome facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don 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 "Issue 15124.doc" deleted by Mark H Linehan/Watson/IBM] Subject: RE: issue 15124 -- SBVR RTF issue X-KeepSent: AD373DFA:822975AC-85257750:0063195A; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Mon, 28 Jun 2010 14:33:48 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/28/2010 14:33:48 Don, I am working from the understanding that an "actuality" is an instance of a fact type. This whole discussion must be reframed if we adopt a different understanding of "actuality". If a conceptual schema defines an individual concept, then it asserts the existence of that concept as a member of the extension of some general concept. So an individual concept is a fact (a proposition about existence and relationship to the general concept, taken to be true) and an actuality (instance of 'meaning corresponds to thing'). Taking the example from "individual concept" in 8.1.1: "The individual concept âCaliforniaâ whose one instance is an individual state in the United States of America " -- this asserts a proposition which is taken to be true (there exists a state that is "California"). From the perspective of the fact model, the extension of the concept "state" contains at least one element. There is an actuality that the concept 'state' corresponds to a thing. Regarding "actuality" in clause 10, consider the third paragraph which reads: â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 Foormulationâ . 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. 1) We know that a clause 8.1.2 "fact" may be "of" any proposition. The only sense I can make of the 2nd sentence is if I read it as "An 'actuality' is of a particular 'Fact Type'." 2) An atomic formulation, taken on its own, formulates a proposition only if the roles of the atomic formulation are filled by individual concepts or constants. For example "California is part of the United States" where 'California' and 'United States' are individual concepts. In most propositions, atomic formulations are combined with quantifications, logical operators, and modal operators. So an individual atomic formulation forms a proposition (which may be a clause 8.1.2 fact) only in rather special circumstances. Net: I think the way to make this paragraph consistent with the rest of the specification is to change 'fact' to 'actuality'. My suggestion is that we may get clarity by going through Clause 10 and deciding whether each instance of the term 'fact' means 'fact' or means 'actuality' as used in the rest of the specification. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley ---06/28/2010 01:34:25 PM---Hi Mark, Iâm glad you agree on cleaning up the use of âpopulationâ. Don Baisley 06/28/2010 12:41 PM To Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue Hi Mark, Iâm glad you agree on cleaning up the use of âpopulationâ. I could not make sense of your last paragraph below. Propositions are asserted, not actualities. I didnât notice clause 10 having uses of âfactâ that meant âactualityâ. If you see any, please let us know. Thanks, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, June 28, 2010 6:37 AM To: sbvr-rtf@omg.org Subject: RE: issue 15124 -- SBVR RTF issue I note that the terms "fact model population" and "domain model population" are also used in 8.5 in the note under "fact type is internally closed in conceptual schema ". We should align this note with the definition we decide for "population". "Fact" is used (instead of "actuality") in the definition of that verb concept and also in "concept is closed in conceptual schema ". Should this be addressed in another issue, or in 15124? I am certainly in favor of disentangling different meanings of "population", and I think "extension" is a well-defined term that we should use when it is appropriate. Regarding the three possible meanings of "population" -- rather than use "population" alone, how about making three terms using the pattern "xxx population". For example (following Don's numbered possibilities): (1) "fact model population", (2) "existential fact population"; (3) "elementary fact population". I think we should go further, and align the uses of the term "fact" in clause 10 with "fact" and "actuality" as used in clauses 8, 9, 11, 12. I think the idea of a mapping between clause 10 and the rest of the document is terrible -- the specification should be self-consistent throughout. I think the way to start down this path is to change "fact" to "actuality" in clause 10 where that is what is meant. Then we can see whether the remaining uses of "fact" are still inconsistent with the rest of the specification. Note that I am not suggesting changes to the meaning of clause 10, but just correcting the terms to fit the rest of the spec. I note that an "actuality" asserted in a conceptual model is also a "fact". For example, an individual concept is an actuality that the concept is in the extension of some general concept, and that actuality is taken as true. The same would be true of what should be called an "individual verb concept", meaning an individual concept that is an instance of a fact type. So some actualities are also facts. Similarly, the mere assertion of concepts and elements of guidance indicates that they are "taken as true" and hence are facts but not actualities. In other words, the relationship between facts and actualities is one of overlapping circles in a Venn diagram. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley 06/25/2010 04:22 PM To "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue We discussed part of the recommended resolution to issue 15124 in yesterdayâs RTF meeting. Some changes to the rewordings were recommended, which are captured in the attached document. Also, we noted that there is inconsistency in the use of the word âpopulationâ in clause 10. I highlighted a note about the inconsistency in the attached document. We need to agree on a solution. Once agreed, we can complete the resolution. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, March 10, 2010 8:46 AM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15124 -- SBVR RTF issue From: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulated using quantifiiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A âFactâ is of a particular âFact Type.â 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as âEmployee works for Departmentâ) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don 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 "Issue 15124.doc" deleted by Mark H Linehan/Watson/IBM] pic60572.gif From: Don Baisley To: Mark H Linehan , "sbvr-rtf@omg.org" Subject: RE: issue 15124 -- SBVR RTF issue Thread-Topic: issue 15124 -- SBVR RTF issue Thread-Index: AQHKwHICliMVKWQtGUWqJBkBdHyRt5KTxdowgAS8iwD//7nm4IAAmQ4A//+WqJA= Date: Mon, 28 Jun 2010 19:32:28 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Mark, The clause 10 statement, .A .Fact. is of a particular .Fact Type.., uses scare quote around .Fact. for a reason. It is talking, not about facts in general, but about an elementary fact (based on its being formulated using an atomic formulation), which should be clear from the sentence that follows it. The sentence is obviously not true about other sorts of facts. Saying .elementary fact. rather than .fact. would be more clear here. The .is of. in that sentence does not mean .is an instance of., but rather means .is formulated based on., which should also be clear from the subsequent sentence. The paragraph says nothing about actualities. I.m sure the original author of that paragraph did not intend to write that actualities are the primary building blocks of SBVR. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, June 28, 2010 11:34 AM To: sbvr-rtf@omg.org Subject: RE: issue 15124 -- SBVR RTF issue Don, I am working from the understanding that an "actuality" is an instance of a fact type. This whole discussion must be reframed if we adopt a different understanding of "actuality". If a conceptual schema defines an individual concept, then it asserts the existence of that concept as a member of the extension of some general concept. So an individual concept is a fact (a proposition about existence and relationship to the general concept, taken to be true) and an actuality (instance of 'meaning corresponds to thing'). Taking the example from "individual concept" in 8.1.1: "The individual concept .California. whose one instance is an individual state in the United States of America " -- this asserts a proposition which is taken to be true (there exists a state that is "California"). From the perspective of the fact model, the extension of the concept "state" contains at least one element. There is an actuality that the concept 'state' corresponds to a thing. Regarding "actuality" in clause 10, consider the third paragraph which reads: .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. 1) We know that a clause 8.1.2 "fact" may be "of" any proposition. The only sense I can make of the 2nd sentence is if I read it as "An 'actuality' is of a particular 'Fact Type'." 2) An atomic formulation, taken on its own, formulates a proposition only if the roles of the atomic formulation are filled by individual concepts or constants. For example "California is part of the United States" where 'California' and 'United States' are individual concepts. In most propositions, atomic formulations are combined with quantifications, logical operators, and modal operators. So an individual atomic formulation forms a proposition (which may be a clause 8.1.2 fact) only in rather special circumstances. Net: I think the way to make this paragraph consistent with the rest of the specification is to change 'fact' to 'actuality'. My suggestion is that we may get clarity by going through Clause 10 and deciding whether each instance of the term 'fact' means 'fact' or means 'actuality' as used in the rest of the specification. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley ---06/28/2010 01:34:25 PM---Hi Mark, I.m glad you agree on cleaning up the use of .population.. Don Baisley 06/28/2010 12:41 PM To Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue Hi Mark, I.m glad you agree on cleaning up the use of .population.. I could not make sense of your last paragraph below. Propositions are asserted, not actualities. I didn.t notice clause 10 having uses of .fact. that meant .actuality.. If you see any, please let us know. Thanks, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, June 28, 2010 6:37 AM To: sbvr-rtf@omg.org Subject: RE: issue 15124 -- SBVR RTF issue I note that the terms "fact model population" and "domain model population" are also used in 8.5 in the note under "fact type is internally closed in conceptual schema ". We should align this note with the definition we decide for "population". "Fact" is used (instead of "actuality") in the definition of that verb concept and also in "concept is closed in conceptual schema ". Should this be addressed in another issue, or in 15124? I am certainly in favor of disentangling different meanings of "population", and I think "extension" is a well-defined term that we should use when it is appropriate. Regarding the three possible meanings of "population" -- rather than use "population" alone, how about making three terms using the pattern "xxx population". For example (following Don's numbered possibilities): (1) "fact model population", (2) "existential fact population"; (3) "elementary fact population". I think we should go further, and align the uses of the term "fact" in clause 10 with "fact" and "actuality" as used in clauses 8, 9, 11, 12. I think the idea of a mapping between clause 10 and the rest of the document is terrible -- the specification should be self-consistent throughout. I think the way to start down this path is to change "fact" to "actuality" in clause 10 where that is what is meant. Then we can see whether the remaining uses of "fact" are still inconsistent with the rest of the specification. Note that I am not suggesting changes to the meaning of clause 10, but just correcting the terms to fit the rest of the spec. I note that an "actuality" asserted in a conceptual model is also a "fact". For example, an individual concept is an actuality that the concept is in the extension of some general concept, and that actuality is taken as true. The same would be true of what should be called an "individual verb concept", meaning an individual concept that is an instance of a fact type. So some actualities are also facts. Similarly, the mere assertion of concepts and elements of guidance indicates that they are "taken as true" and hence are facts but not actualities. In other words, the relationship between facts and actualities is one of overlapping circles in a Venn diagram. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley 06/25/2010 04:22 PM To "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue We discussed part of the recommended resolution to issue 15124 in yesterday.s RTF meeting. Some changes to the rewordings were recommended, which are captured in the attached document. Also, we noted that there is inconsistency in the use of the word .population. in clause 10. I highlighted a note about the inconsistency in the attached document. We need to agree on a solution. Once agreed, we can complete the resolution. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, March 10, 2010 8:46 AM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15124 -- SBVR RTF issue From: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . obviously, some facts are formulateed using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A .Fact. is of a particular .Fact Type.. 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as .Employee works for Department.) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don 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 "Issue 15124.doc" deleted by Mark H Linehan/Watson/IBM] To: sbvr-rtf@omg.org Subject: RE: issue 15124 -- SBVR RTF issue X-KeepSent: 7F1EB5D8:A6186A9F-85257750:006C3CC9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Mon, 28 Jun 2010 15:56:04 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/28/2010 15:56:05, Serialize complete at 06/28/2010 15:56:05 An "elementary fact" is defined at the bottom of page 87 as "a declaration that an individual has a property, or that one or more individuals participate in a relationship, where the fact cannot be split into simpler facts with the same individuals (without information loss)." The word "declaration" is unclear, but based on the following text, it appears that "elementary fact" is the same concept as "actuality" understood as "instance of fact type". So I suggest that either we use "actuality" everywhere we mean that, or we explicitly make "elementary fact" be a synonym of "actuality". Either way would help clarify the relationship between clause 10 and the rest of the specification. However, I think readers would assume that "elementary fact" means the adjective "elementary" applied to "proposition taken as true", which would be confusing and misleading. So personally, I would prefer to get rid of "elementary fact". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley 06/28/2010 03:32 PM To Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue Mark, The clause 10 statement, âA âFactâ is of a particular âFact Typeââ, uses scare quote around âFactâ for a reason. It is talking, not about facts in general, but about an elementary fact (based on its being formulated using an atomic formulation), which should be clear from the sentence that follows it. The sentence is obviously not true about other sorts of facts. Saying âelementary factâ rather than âfactâ would be more clear here. The âis ofâ in that sentence does not mean âis an instance ofâ, but rather means âis formulated based onâ, which should also be clear from the subsequent sentence. The paragraph says nothing about actualities. Iâm sure the original author of that paragraph did not intend to write that actualities are the primary building blocks of SBVR. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, June 28, 2010 11:34 AM To: sbvr-rtf@omg.org Subject: RE: issue 15124 -- SBVR RTF issue Don, I am working from the understanding that an "actuality" is an instance of a fact type. This whole discussion must be reframed if we adopt a different understanding of "actuality". If a conceptual schema defines an individual concept, then it asserts the existence of that concept as a member of the extension of some general concept. So an individual concept is a fact (a proposition about existence and relationship to the general concept, taken to be true) and an actuality (instance of 'meaning corresponds to thing'). Taking the example from "individual concept" in 8.1.1: "The individual concept âCaliforniaâ whose one instance is an individual state in the United States of America " -- this asserts a proposition which is taken to be true (there exists a state that is "California"). From the perspective of the fact model, the extension of the concept "state" contains at least one element. There is an actuality that the concept 'state' corresponds to a thing. Regarding "actuality" in clause 10, consider the third paragraph which reads: â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 logicgical formulation based directly upon a fact type, involving no logical operation. An atomic formulation may be considered as an invocation of a predicate. 1) We know that a clause 8.1.2 "fact" may be "of" any proposition. The only sense I can make of the 2nd sentence is if I read it as "An 'actuality' is of a particular 'Fact Type'." 2) An atomic formulation, taken on its own, formulates a proposition only if the roles of the atomic formulation are filled by individual concepts or constants. For example "California is part of the United States" where 'California' and 'United States' are individual concepts. In most propositions, atomic formulations are combined with quantifications, logical operators, and modal operators. So an individual atomic formulation forms a proposition (which may be a clause 8.1.2 fact) only in rather special circumstances. Net: I think the way to make this paragraph consistent with the rest of the specification is to change 'fact' to 'actuality'. My suggestion is that we may get clarity by going through Clause 10 and deciding whether each instance of the term 'fact' means 'fact' or means 'actuality' as used in the rest of the specification. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley ---06/28/2010 01:34:25 PM---Hi Mark, Iâm glad you agree on cleaning up the use of âpopulationâ. Don Baisley 06/28/2010 12:41 PM To Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue Hi Mark, Iâm glad you agree on cleaning up the use of âpopulationâ. I could not make sense of your last paragraph below. Propositions are asserted, not actualities. I didnât notice clause 10 having uses of âfactâ that meant âactualityâ. If you see any, please let us know. Thanks, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, June 28, 2010 6:37 AM To: sbvr-rtf@omg.org Subject: RE: issue 15124 -- SBVR RTF issue I note that the terms "fact model population" and "domain model population" are also used in 8.5 in the note under "fact type is internally closed in conceptual schema ". We should align this note with the definition we decide for "population". "Fact" is used (instead of "actuality") in the definition of that verb concept and also in "concept is closed in conceptual schema ". Should this be addressed in another issue, or in 15124? I am certainly in favor of disentangling different meanings of "population", and I think "extension" is a well-defined term that we should use when it is appropriate. Regarding the three possible meanings of "population" -- rather than use "population" alone, how about making three terms using the pattern "xxx population". For example (following Don's numbered possibilities): (1) "fact model population", (2) "existential fact population"; (3) "elementary fact population". I think we should go further, and align the uses of the term "fact" in clause 10 with "fact" and "actuality" as used in clauses 8, 9, 11, 12. I think the idea of a mapping between clause 10 and the rest of the document is terrible -- the specification should be self-consistent throughout. I think the way to start down this path is to change "fact" to "actuality" in clause 10 where that is what is meant. Then we can see whether the remaining uses of "fact" are still inconsistent with the rest of the specification. Note that I am not suggesting changes to the meaning of clause 10, but just correcting the terms to fit the rest of the spec. I note that an "actuality" asserted in a conceptual model is also a "fact". For example, an individual concept is an actuality that the concept is in the extension of some general concept, and that actuality is taken as true. The same would be true of what should be called an "individual verb concept", meaning an individual concept that is an instance of a fact type. So some actualities are also facts. Similarly, the mere assertion of concepts and elements of guidance indicates that they are "taken as true" and hence are facts but not actualities. In other words, the relationship between facts and actualities is one of overlapping circles in a Venn diagram. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley 06/25/2010 04:22 PM To "sbvr-rtf@omg.org" cc Subject RE: issue 15124 -- SBVR RTF issue We discussed part of the recommended resolution to issue 15124 in yesterdayâs RTF meeting. Some changes to the rewordings were recommended, which are captured in the attached document. Also, we noted that there is inconsistency in the use of the word âpopulationâ in clause 10. I highlighted a note about the inconsistency in the attached document. We need to agree on a solution. Once agreed, we can complete the resolution. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, March 10, 2010 8:46 AM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15124 -- SBVR RTF issue From: Don Baisley To: "issues@omg.org" , "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Topic: SBVR Issue: Inconsistent use of terminology when relating facts to fact types Thread-Index: Acq/+niZQe590yTETWKiIB91QE9+Eg== Date: Wed, 10 Mar 2010 02:36:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: SBVR Issue Inconsistent use of terminology when relating facts to fact types It has been noted that there are a few places in clause 10 where the relationship between facts and fact types are described using inconsistent language. SBVR makes clear that not every fact is of a particular fact type . oobviously, some facts are formulated using quantifiers, logical operators, etc. SBVR makes clear that instances of fact types are actualities, not facts. SBVR describes concepts as having instances, but not facts as having instances. A few places in clause 10 can be lead to confusion in this regard. They are listed below with recommended rewordings. Thanks go to Mark Linehan who graciously went through clause 10 last September and located these places. Recommended changes: 1. In the third paragraph of the introduction to clause 10, REMOVE the sentence that says: A âFactâ is of a particular âFact Type.â 2. REPLACE the third paragraph of 10.1.1.2, which says 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 fact types (such as âEmployee works for Departmentâ) and rules relevant to the business domain. 3. In the last paragraph of page 89 (in 10.1.1.2) there is a sentence that says: The fact model includes both the conceptual schema and the ground fact population (set of fact instances that instantiate the fact types in the schema). REPLACE it with this: The fact model includes both the conceptual schema and the ground fact population (set of facts that are formulated using the fact types and other concepts in the schema). 4. Just above figure 10.1 on page 90 there is the following sentence. Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (instances of domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. REPLACE it with this: Figure 10-1 provides a simplified picture of this situation, indicating that the fact model of sentences expressing population facts (formulated using domain-specific fact types) is a varset (variable-set) whose population at any given time is a set of facts. Best regards, Don 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 "Issue 15124.doc" deleted by Mark H Linehan/Watson/IBM]