Issue 13139: Clean up and Complete Vocabulary for Clause 10.1.1 (sbvr-rtf) Source: Business Semantics Ltd. (Mr. Donald R. Chapin, Donald.Chapin(at)BusinessSemantics.com) Nature: Uncategorized Issue Severity: Summary: SBVR Issue -- Clean up and Complete Vocabulary for Clause 10.1.1 (Was Issues 11296-1a and 11303-b) (Part of Separating 11296 & 11303 into Manageable Pieces)Please see attached Word document for Issue details. This SBVR spin-off Issue is a part of a package of three proposed Issue resolutions: - the proposed resolution of this spin-off Issue which will be posted when it has a number; - the proposed resolution to Issue 12540; and - the proposed resolution of the Issue 12540 spin-off Issue which will be posted when it has a number. Resolution: Revised Text: Actions taken: December 4, 2008: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 04 Dec 2008 14:09:25 -0500 To: issues@omg.org, sbvr-rtf@omg.org From: Juergen Boldt Subject: issue 13139 -- SBVR RTF issue DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MimeOLE:Thread-Index; b=xR6aFu7/zz0jFMs0XifWHVf+EIhmxYcMyuOMSEyuQxP5cLpDt9+dgrTj/AfYv3yPiknu5W88UneaMv8qx0boQu5WGR8wy8Cz7ISk4ohOrHRp/FnV0SRaLMUmbrXIA3h/rql3J0gyFSO14SZHAiqVT9b6w9tNulDclKnORdMQ6U8= ; X-YMail-OSG: WDPViToVM1m602l2LEx7iiUkhLvcq.k9rGSmuuMGTtam9D60BXWJ3a_1uA2tNahes64Nk2K94_hI0KqZGNN4QyKnWy0q7RfCm7ZTgLpjkCdf4YAhVf2O14nlDWZi1mr5F3E- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Clean up and Complete Vocabulary for Clause 10.1.1 (Was Issues 11296-1a and 11303-b) (Part of Separating 11296 & 11303 into Manageable Pieces) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEjrWkDiuyTTWSyOb2309QM9nqQ== All . Please see attached Word document for Issue details. This SBVR spin-off Issue is a part of a package of three proposed Issue resolutions: - the proposed resolution of this spin-off Issue which will be posted when it has a number; - the proposed resolution to Issue 12540; and - the proposed resolution of the Issue 12540 spin-off Issue which will be posted when it has a number. Donald Issue nnnnn -- Clean up and Complete Vocabulary for Clause 10.1.1 (Was Issues 11296-1a and 11303-b)2.doc SBVR Container Diagram for Proposed Issue nnnnn (Clean up and Complete Vocabulary for Clause 10.1.1) Resolution 2008-12-042.ppt 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" Date: Thu, 11 Dec 2008 10:54:15 -0800 Subject: RE: issue 13139 -- SBVR RTF issue Thread-Topic: issue 13139 -- SBVR RTF issue Thread-Index: AclWQ+MeHBeWsFYdSU+X0bq/sVPsigAslkzwAOKM43AAT+HhQA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US After this morning.s discussion on this issue, I recommend that Donald try to get Terry Halpin, Pat Hayes and others with a strong formal logics orientation to write a proposed resolution. For an current use of undefined or poorly defined terms in clause 10, they should have the option of either giving clear definitions or clarifying the text where the terms were used, perhaps by using other terms that are defined. They should have a goal of simplifying rather than complicating clause 10. This is an RTF, so any changes proposed should be aimed at specific, well stated problems. The general assertion that something .has several errors.. What exactly is misstated and how is it wrong? Or where is there a contradiction? I am particularly interested in knowing what is misstated in 8.5, especially since its suggested replacement is so much more confusing and complicated. .fact. should certainly not be removed from clause 8. The removal of the 8.5 material seems to be troublesome to some of us, so even thought it would not bother me personally to see it move to clause 10, I respect that it is important to at least Mark and Ron. It might well be important to Terry and/or Sjir, but I don.t know. Don From: Don Baisley Sent: Wednesday, December 10, 2008 9:42 PM To: sbvr-rtf@omg.org Subject: RE: issue 13139 -- SBVR RTF issue I suppose I.ll trust Terry or others to check whether the bulk of the proposed resolution is correct and relevant, but I see some issues which I list below. I hope the end result gets an OK from Pat Hayes -- I.m not a logician, but what I see makes me nervous. The new material does not have the definitive nature I.m used to seeing in descriptions of formal logics or mathematics, but I.ll let others decide on that. Who is .we. in the definition of .business domain.. Why does .instance. have a new meaning in clause 10 that is completely different than our long standing meaning in clause 8? If you use Wikipedia as a source, should you give a date or some way of making a definite reference? Why can.t a ground fact be a metafact? And what is a metafact? A fact about facts? I don.t see that defined or explained. Is it right that if someone has a nonelementary fact type, then he doesn.t get to have any ground facts for it? The new definitions seem to say so. What is meant by .simpler. in the definition of .elementary ground fact.? I can split a fact AdultFemalePerson(y) into Person(y), Adult(y), Female(t), which seem to be simpler facts to me. But AdultFemalePerson(y) is the same fact as Woman(y). I don.t know what is meant by .simpler.. In the new example for 13.2.6, be sure the placeholders in the example fact type form are underlined. Regards, Don From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Friday, December 05, 2008 8:33 AM To: sbvr-rtf@omg.org Subject: RE: issue 13139 -- SBVR RTF issue All -- Attached is a proposed resolution for Issue 13139 for discussion at next Thursday's face to face SBVR RTF meeting. Feedback from Terry Halpin is included in this proposed Issue resolution. Also attached is a changed-tracked version of what was Clause 8.5 and is now Clause 10.1.3 as revised by this Issue 13139 resolution. This proposed Issue resolution is a part of a package of three proposed Issue resolutions: 12540, 13138 & 13139. Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, December 04, 2008 7:09 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13139 -- SBVR RTF issue From: "Donald Chapin" To: , Subject: SBVR Issue -- Clean up and Complete Vocabulary for Clause 10.1.1 (Was Issues 11296-1a and 11303-b) (Part of Separating 11296 & 11303 into Manageable Pieces) Date: Thu, 4 Dec 2008 13:15:42 -0000 All . Please see attached Word document for Issue details. This SBVR spin-off Issue is a part of a package of three proposed Issue resolutions: - the proposed resolution of this spin-off Issue which will be posted when it has a number; - the proposed resolution to Issue 12540; and - the proposed resolution of the Issue 12540 spin-off Issue which will be posted when it has a number. Donald DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:In-Reply-To:X-MIMEOLE:Thread-Index; b=wAijcfYbt7eOcg6hDf8WmCVtDVmB2EO3tTXgdq8iRSJFF74RS7q0VH/OLm0lq4At6Hf4nj5bSCi5X3i7ux7snPVnHd0uVpwlKBze4x9hRDR48KOLZxcT5it8ndrnspuj3h2Y/9GUq/0B913zWsY34D1YDblE4akvS9D/AcRudTE= ; X-YMail-OSG: JTaa6VQVM1mCDCn.3Db1kniG0d0lXNE1T6Me1ydJ_lTW9j7L2hbhKtihAahYWjr2QSTZpDjrkXAJN_lH_xBrIXWjPADoWeETeFeeurHqS6nM3WZ5hv6baEMb5tohlqUOhfXqM.oVAJnHVlA8DFvpa.dBn1ONXqwPezXoWwQu3iCaB7vC_U1cA4tsfHurK7bteOzRmgU- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: RE: issue 13139 -- SBVR RTF issue Date: Fri, 5 Dec 2008 16:33:05 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWQ+MeHBeWsFYdSU+X0bq/sVPsigAslkzw All -- Attached is a proposed resolution for Issue 13139 for discussion at next Thursday's face to face SBVR RTF meeting. Feedback from Terry Halpin is included in this proposed Issue resolution. Also attached is a changed-tracked version of what was Clause 8.5 and is now Clause 10.1.3 as revised by this Issue 13139 resolution. This proposed Issue resolution is a part of a package of three proposed Issue resolutions: 12540, 13138 & 13139. Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, December 04, 2008 7:09 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13139 -- SBVR RTF issue From: "Donald Chapin" To: , Subject: SBVR Issue -- Clean up and Complete Vocabulary for Clause 10.1.1 (Was Issues 11296-1a and 11303-b) (Part of Separating 11296 & 11303 into Manageable Pieces) Date: Thu, 4 Dec 2008 13:15:42 -0000 All . Please see attached Word document for Issue details. This SBVR spin-off Issue is a part of a package of three proposed Issue resolutions: - the proposed resolution of this spin-off Issue which will be posted when it has a number; - the proposed resolution to Issue 12540; and - the proposed resolution of the Issue 12540 spin-off Issue which will be posted when it has a number. Donald Proposed Issue 13139 (Clean up and Complete Vocabulary for Clause 10.1.1) Resolution 2008-12-05.doc SBVR Clauses 10-1-3 (was 8-5) as Revised by Issue 13139 Resolution WITH CHANGE TRACKING 2008-12-05.doc DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MimeOLE:Thread-Index; b=Sj1/tpNO1Nqi4ucT2CotgNe6mD07ErsQ0GLdIvGm06asmVX26JtlLCLihw760rqv9RBC0+v3BtJnwL86V27jpeulj7S786xsdhp7j5wNUeBczqGLrjdaop9EBuG7b8WEFrpEphDXH0t9XtcKrOWjGu/dsKDzLZdohwVmdkl/X1Q= ; X-YMail-OSG: pZ410bIVM1n28OBlb87XimRwMQTHKPTaQHa61aR_kBV0daGyWU2FNVczQSEmm.wme7IpKgVskS89j9GqG6tXnz7aLKvX1E7fKVFBkrUmD2SNIOjiSsNd8DRcLMj8sPL5wDn95EiU7a_0enxaO0pXE.uTvRSvHcqM89KPrf9QnPkDsN_3RTWhfJTXukQ- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: [SBVR-RTF] -- Issue 13139 -- FW: Can You Review the Change-Tracked Vocabulary for Your SBVR Clause 10.1.1 Formal Semantics Text? Date: Wed, 10 Dec 2008 16:36:25 -0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWFPIdUw7bx0NQT8CnUmQ8x7GSawAOMrdwATWniIA= For Your Information . regarding problems with Clause 8.5 -------------------------------------------------------------------------------- From: On Thursday, December 04, 2008 12:46 PM Terry Halpin wrote: Subject: RE: Can You Review the Change-Tracked Vocabulary for Your SBVR Clause 10.1.1 Formal Semantics Text? Hi Donald s several errors, so it is good to have it removed. . Cheers Terry From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Thursday, December 04, 2008 6:34 AM To: Terry Halpin Cc: john.hall@modelsys.com Subject: Can You Review the Change-Tracked Vocabulary for Your SBVR Clause 10.1.1 Formal Semantics Text? Importance: High Hi Terry, Could you review the attached change-tracked document to see if it is an accurate vocabulary for the terms that you used, as you used them, in the text for the SBVR formal semantics that you wrote in Clause 10.1.1? I need this as soon as you can do it. There.s nothing in it that.s not in Clause 10.1.1 as far as I know . so it should be quick for you. I spent hours (days) trawling your SBVR Clause 10.1.1 text to create a faithful and accurate vocabulary for it (and nothing else) to resolve two pending SBVR sub-Issues (11296-1a and 11303-b). I.ve also attached the Issue Resolution with the editing instructions, but there.s no need to look at that as the change tracked document is the exact outcome of those editing instructions. As soon as you let me know that there are no significant problems in the change-tracked document and/or send me any corrections necessary to align it with the wording and intent of Clause 10.1.1, I need to post the editing instructions on the SBVR RTF email. Many Thanks, Donald Subject: comments on proposed resolutions for issues 12540+13138+13139 To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 10 Dec 2008 16:27:42 -0500 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/10/2008 16:27:40 I reviewed these proposed resolutions in detail, and have the following comments. I tried to put these roughly in the order of importance to me: * This set of resolutions doesn't solve one basic problem: there are two different "container" designs in SBVR. One is the conceptual schema/fact model set of ideas that are proposed to be moved to clause 10, and the other is the combination of the various "body of ..." containers, plus "terminological dictionary" and "vocabulary" and "rulebook" that are proposed to be moved to clause 8. Nor does this set of resolutions explain how these two designs relate to each other; it just relegates the conceptual schema/fact model approach to secondary status in clause 10. I think what we really need is to get to one design that is simple and explainable. I like the idea that a "terminological dictionary" is a view over various stuff, and I think we should think of more of these container ideas that way. I think I would prefer a design that leaves conceptual schema/fact model in clause 8 and redefines the clause 11 containers as "views" over the relevant stuff. Plus move "vocabulary" (as a "view") to clause 8 to make that clause standalone and support the "vocabulary namespace" concept in clause 8. * I don't understand the distinction between "ownership container" ("... a place for each SBVR metamodel element to reside ...") and "packaging container" ("... to package selected SBVR metamodel elements in various ways ..."). Why do we need both of these? Could we simplify by getting rid of one or the other? I note that NONE of the "ownership containers" (body of shared meanings, body of shared concepts, rulebook) are mentioned in clause 13. * How do we include individual concepts ("existential ground facts") and "elementary ground facts" in the clause 8 containers? Moving "fact model" to clause 10 and putting "fact model population" only in clause 10 means there's no way to include such "ground facts" in a model that is based on clause 8. * The clause 8.5 fact types supporting open versus closed world semantics cannot be moved to clause 10, because we need to be able to express these ideas in SBVR-based vocabularies. But these ideas are dependent upon the concept "conceptual schema", which thus also needs to remain in clause 8. Or the open/closed world fact types have to be reworked completely. I think this point is fatal to the idea of moving "conceptual schema" to clause 10. * I think its a mistake to change "fact model is based on conceptual schema" to "fact model population is based on conceptual schema". Adding the latter may be ok. But the former is still needed to express the relationship between SBVR-based models and the SBVR metamodel. For example, EU-Rent is a fact model that is based on the SBVR conceptual schema. * Resolution 13139 point 5.1 proposes to change the existing text from "An exchange document ... shall be an XML document that represents a 'fact model' ..." to say instead that an exchange document "... represents a fact model population". I think this is wrong. An exchange model needs to be able to include both a conceptual schema and a fact model population. (I didn't review the rest of these 5.1 changes in detail.) * I don't understand the utility of "body of shared concepts" that has nouns and fact types but not definitions or definitional elements of guidance. Taken on their own, without even designations, the nouns + fact types have little semantic meaning. In the xml file, an object type is represented as (for example) "". A fact type entry would identify the roles of the fact type but little else. In summary, a body of shared concepts contains so little information, that it is not very useful as a container. * It seems to me that formal Definitions and Definitional Elements of Guidance are almost the same idea. Given an instance, one has to consider both the relevant Definitions and the relevant Necessities to decide whether the instance meets the criteria to be considered an instance of a particular general concept. Clause 2.1 supports this point. So why are Definitions (or at least the logical formulations of formal definitions) not in the same container as Definitional Elements of Guidance? To put it another way, aren't Definitions as much "shared guidance" as Definitional Elements of Guidance? * I don't see much value in "body of shared guidance". What scenario would make people interested in this particular container? * I see a proposal (parts 12 and 13) to permit designations and fact type forms to be directly included in vocabularies, without using vocabulary namespaces. What is the motivation for this? What is the meaning of a designation that is in a vocabulary but not the associated vocabulary namespace? Why add this complexity? * It seems to me that the concept "rulebook" is misnamed if it contains designations and fact type forms and notes (etc.) in addition to guidance statements. * I think we should have a named concept for the outer container show in Donald's charts -- the one called "Body of Shared Meanings 1 + Body of Shared Representations in Related Speech Communities". * I think we should have a container that includes Behavioral Elements of Guidance and Behavioral Guidance Statements -- a way to package both the meaning and the representation aspects of behavioral rules. Such a package is what one might want to map to a runtime rule engine. * Resolution 13139 proposes to remove the definitions of "antecedent", "consequent", and "implication" because "they are not used". But these are in fact used in clause 9.2.5. "Integer" is defined in clause 8.7. "Logical variable" is equivalent to "variable" in the rest of the spec. "Unbound variable" is elsewhere called "free variable", but "free variable" itself is not defined (which is a problem). * What is the purpose of clause 10.1.2, anyway? There's no introductory paragraph or other text that explains why this clause exists at all. * What is the motivation for the new definition of "conceptual schema". Is it to innumerate the things that are included in a conceptual schema? * What does the term "meta fact" mean in the definition for "ground fact": "fact that is not a meta fact ....". Saying that a "ground fact" is not makes for a definition with no useful semantic content. Also, there is a circular definition among "ground fact", "elementary ground fact", and "existential ground fact". * Why do we need both the terms "individual" and "instance"? Can't they be synonyms? Also, note that we already have the term "instance" in clause 8.6. * Rather than define a new concept "type of individual", why not make this term a synonym of an existing concept, such as "object type". That would link this aspect to the main part of the SBVR spec. * Why rename "fact type" to "ground fact type" in various existing SBVR fact types? * This definition does not make sense to me: "the ground fact type role is a part played by an individual in a ground fact". Does this mean that we can't have ground fact type roles if they don't participate in a ground fact? That can't be right! * The definition of "ground fact type role" should be stylized and should be based on the existing SBVR "fact type has role". If we need this concept at all. * I note the following text in green at the bottom right-hand corner of two of Donald's diagrams: "Note: One body of shared meanings often must map to more than one fact model to stay within first-order or restricted higher-order predicate logic." Why? * It seems to me that Donald's colored diagram is very useful, and should be included somewhere in the specification. Perhaps a new section A.5.4? * How do namespaces interact with the containers discussed in these proposed resolutions? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion Thread-Topic: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion Thread-Index: AcrLn5NDEUI997+sQ+++lfQ4KvlN1AA3evYg Date: Fri, 26 Mar 2010 03:20:11 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Here are some comments on the clause 10.1.3 material proposed for issue 13139. conceptual schema Adding a new concept with the signifier .conceptual schema. to clause 10 has problems: 1. Clause 10.1.2 says that .conceptual schema. is ORM.s synonym for .domain grammar.. So 10.1.3 would be adding a third sense for this signifier. 2. The purpose of describing .conceptual schema. in clause 10 is because it is in clause 8: Clause 10 is supposed to give a formal underpinning to clauses 8 and 9. Use of .conceptual schema. in 10.1.1 is all about describing the clause 8 concept for the purpose of giving a formal underpinning. .conceptual schema. is not part of that formal underpinning, so it doesn.t need to be defined in clause 10. 3. The proposed 10.1.3 definition appears to be a collection of things said informally about conceptual schemas in 10.1.3. Some of those informal statements are overgeneralizations, so putting them in a definition overly restrictive. I see no reason to think that the proposed 10.1.3 definition has any advantage for SBVR over the clause 8 definition. FL The use of FL in 10.1.3 seems strange. FL was meant to say there was a formal logic interpretation to be found in clause 10. formal fact model This appears to be a newly made up concept. I don.t find the term used anywhere in SBVR. Perhaps we should be adding .knowledge base. to clause 10.1.2. formal fact model includes fact model population I would expect a formal fact model to include something formal (e.g., wwfs for some domain grammar). fact model population This definition is inconsistent with usage in 10.1.1 which uses pop(I) and pop(F) to define fact model populations for both object types and fact types. E.g., pop(Employee) gives a set of employees and pop(Employee drives car) gives a set of (employee, car) pairs. I find that current clause 10 wording troublesome, because it indicates that the individuals themselves are in the populations rather than references that identify them. But that is a separate issue conceptual schema is role of body of shared meanings in formal fact model fact model population is role of body of shared meanings in formal fact model These new fact types just come out of the blue. They do not appear to be used anywhere in 10.1.1. So the claim that the proposed 10.1.3 concepts come from 10.1.1 is apparently false. ground fact existential ground fact elementary ground fact This circle of definitions excludes meta facts (undefined), so apparently it excludes facts about proposition, so apparently, it is not useful for SBVR defined in terms of itself. type of individual This is a set of possible individuals? But what is an individual? How is that not defined? I assume it excludes sets? If it does, then we have an interesting problem that our formal underpinning does not handle sets. Overall, the proposed 10.1.3 does not address the general problem with clause 10, which is that it does not define a clear mapping of clauses 8 and 9 to formal logics. I am looking for a mapping that leads to domain grammar, knowledge base and wwfs. These are terms already used in clause 10. Let.s focus on making the mapping from clause 8 and 9 concepts to those formal logics concepts clear. It makes no sense to invent clause 10 alternatives to the clause 8 concepts and then continue to ignore the need for clarifying and completing the mapping from our clause 8 and 9 concepts. All the best, Don From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Wednesday, March 24, 2010 3:16 PM To: sbvr-rtf@omg.org Subject: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald 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=BoiDpqk6+XKFg/R9LGPbAgcCfTq319K4zDe56Ef7PVLTMzpoE3dr6y7WwquWMDkPzCoJjmNqaD8hG//1f65ltf/5orzjSJA37d4UK/9VYog7JNQHD2HD4Yqqygd/m54LmSj/+rA8sbZ5xltbNIl1FEUNl4xL8sACsoQvoli7Lmc= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=s1024; t=1269468963; bh=zO7GwbvBWMjUA1EzSmsrqzd0YFwRuD3vOxyOMFnA/Fw=; 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=12P3olT/bYEyZfx2zb043piIw6fOZ+6lGhXkEoSX1PkvEp5txRN0IQqy5ZnqA2ARULTgn0JlBG3vM67D5SxCpMWUrnGjdNOeLSr5B0dZ6XnoYTBW9SVsFakChnRPZ0nQ+4HEkBvEXZFE0Fa9o9OyEqa4E9pC89qVmytolXKsbpI= X-Yahoo-SMTP: ipAFRh2swBALpDiVMXIwBxwhmA51J31AV6tKcA.nNICCSy6cH9UoQMM- X-YMail-OSG: hbW4j4wVM1lDByUiEjlmrsiYkRlSDYaP7vF2K9DO1qgjiIjgzzMCtj3rIvKfcidyHgGVRNKGw7Vh8Y1r5yhSqcTEx7XoFsJ.6JEDlxZypMXdsKmUSp7o4akTght53FubflMQb_9asXvlrLFCP2f_vVxapBqPrmEdE4ftkiCGWXiR6YIQIk9aJnC0cJH.ncJU7XUZRBR3HQ-- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion Date: Wed, 24 Mar 2010 18:16:00 -0400 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrLn5NDEUI997+sQ+++lfQ4KvlN1A== Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1009230186 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-23_12:2010-09-23,2010-09-23,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 23 Sep 2010 14:12:23 -0700 Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion From: keri To: "Donald R. Chapin" , SBVR RTF Thread-topic: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion Thread-index: AcrLn5NDEUI997+sQ+++lfQ4KvlN1CPxHCej All, In today's discussion it was stated that a copy of Donald's extracted glossary would be more useful if presented in alpha order. Attached is a sorted version (and with SBVR caption-styling applied). Keri On 3/24/10 12:16 PM, "Donald Chapin" wrote: Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald Issue 13139 SBVR Clauses 10-1-3 as created 2008-12-12 (sorted).doc 10.1.3. Formal Logic Fact-based Model Containers This subclause formalizes the definition of the foundation fact-based model concepts that are presented in Clause 10.1.1 to which foundation meaning-based concepts in Clause 8, 9, 11 & 12 must be mapped to receive their formal interpretation. The content of this subclause is taken from Clause 10.1, is entirely consistent with it, and uses the Clause 10.1.1 language. conceptual schema Definition: component of one or more formal fact models that includes a generic component that is common to all conceptual schemas and contains relevant axioms from logic and mathematics, and a domain-specific component that contains the type of individual definitions and declarations of the ground fact types, and static constraints and derivation rules relevant to the specific business domain. conceptual schema includes derivation rule Definition: the derivation rule determines how fact model populations can be derived or inferred from other fact model populations that are based on the conceptual schema Synonymous Form: derivation rule is in conceptual schema conceptual schema includes ground fact type Definition: the ground fact type is used to define ground facts in fact model populations based on the conceptual schema Synonymous Form: ground fact type is in conceptual schema Necessity: Each ground fact type role of each ground fact type that is in a conceptual schema is in the conceptual schema. conceptual schema includes ground fact type role Definition: the ground fact type role is a part played by an individual in a ground fact Synonymous Form: ground fact type role is in conceptual schema conceptual schema includes static constraint Definition: the static constraint determines something possible, necessary, permissible, or obligatory in each possible world that can be modeled based on the conceptual schema Synonymous Form: static constraint is in conceptual schema conceptual schema includes type of individual Definition: the type of individual is used to classify the kinds of individuals that participate in ground facts Synonymous Form: type of individual is in conceptual schema conceptual schema is role of body of shared meanings in formal fact model Definition: the body of meanings is used by the formal fact model as its conceptual schema Synonymous Form: body of meanings plays role as conceptual schema in formal fact model derivation rule Definition: rule that indicates how the population of a fact type may be derived from the populations of one or more fact types or how a type of individual may be defined in terms of other types of individuals and fact types elementary ground fact Definition: ground fact that declares 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 existential ground fact Definition: ground fact that asserts the existence of an individual fact model population Definition: set of ground facts that instantiate the ground fact types in the conceptual schema fact model population includes ground fact Definition: the ground fact corresponds to an actuality in the possible world modeled by the formal fact model Synonymous Form: ground fact is in fact model population fact model population is based on conceptual schema Definition: the conceptual schema provides the type of individual definitions and declarations of the ground fact types, static constraints and derivation rules for the fact model population Synonymous Form: conceptual schema defines fact model population fact model population is role of body of shared meanings in formal fact model Definition: the body of meanings is used by the formal fact model as its fact model population Synonymous Form: body of meanigs plays role as fact model population in formal fact model formal fact model Definition: structure intended to describe a business domain composed of a conceptual schema and a fact model population that contains a set of sentences at any point in time that collectively express the conceptual schema and the fact model population of the domain-specific ground fact types in the conceptual schema Note: Each necessity of the conceptual schema is satisfied by a fact model population, but obligations are not necessarily satisfied. Note: The formal fact model may be fully automated (as in, say, a database system), manual (as in, say, a paper record system), or semi-automated. The knowledge may even be stored in human memory (belonging to the business domain experts who may be collectively regarded as the authoritative source of those business facts that are of interest). However, the knowledge must ultimately be expressible by sentences communicated between humans. formal fact model includes conceptual schema Definition: the conceptual schema is used by the formal fact model to define and constrain the fact model populations Synonymous Form: conceptual schema is in formal fact model formal fact model includes fact model population Definition: the fact model population is used by the formal fact model to contain ground facts for ground fact types that are in the conceptual schema Synonymous Form: fact model population is in formal fact model ground fact Definition: fact that is not a meta fact and that is either an existential ground fact or an elementary ground fact ground fact type Definition: kind of existential ground facts or elementary ground facts ground fact type has ground fact in fact model population Definition: the ground fact is in the fact model population and the ground fact corresponds to an instance of the corresponding verb concept ground fact type is closed in conceptual schema Definition: in each fact model population based on the conceptual schema, the entire extension of the ground fact type is given in the ground facts included in the fact model population Necessity: Each ground fact type that is closed in a conceptual schema is in the conceptual schema. Note: A ground fact type can be closed in one conceptual schema and not in another. For example, consider a corporate customer of EU-Rent that adopts several of EU-Rent.s concepts. The corporate customer.s conceptual schema might have the ground fact type .rental includes rental period. as not closed because the customer is not aware of all the rental periods of all rentals,, but EU-Rent.s conceptual schema has the ground fact type as closed. ground fact type is internally closed in conceptual schema Definition: in each fact model population based on the conceptual schema, for each instance of the ground fact type, the fact model population includes a corresponding fact if, for each thing filling any of the fact type.s roles in the instance, the fact model population also includes a fact of the existence of that thing Synonymous Form: ground fact type is semi-closed in conceptual schema Necessity: Each ground fact type that is semi-closed in a conceptual schema is in the conceptual schema. Note: Open world semantics are assumed by default, but closure may be explicitly asserted for any ground fact type, on an individual basis, to declare that each fact model population agrees with that of the corresponding verb concept.s extension in the actual business domain. Semi-closure is with respect to the fact model population of the types of individuals playing aground fact type role in the ground fact type. In other words, if the things participating in a fact are known within a model, then the fact is also known within that model. ground fact type role Definition: part played in a ground fact type static constraint Definition: rule that defines bounds, borders, or limits on fact populations and that imposes a restriction on what fact populations are possible or permitted, for each state of the formal fact model taken individually type of individual Definition: set of possible individuals type of individual is closed in conceptual schema Definition: in each fact model population based on the conceptual schema, the entire extension of the type of individual is given in the facts included in the fact model population Necessity: Each type of individual that is closed in a conceptual schema is in the conceptual schema. Note: A type of individual can be closed in one conceptual schema and not in another. For example, consider a corporate customer of EU-Rent that adopts several of EU-Rent.s concepts. The corporate customer.s conceptual schema might have the type of individual .rental. as not closed because the customer is not aware of all rentals, but EU-Rent.s conceptual schema has the type of individual as closed. type of individual plays part as ground fact type role Definition: the ground fact type role is a part played by exactly one type of individual From: "Donald Chapin" To: "'keri'" , "'Donald R. Chapin'" , "'SBVR RTF'" Subject: RE: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion Date: Fri, 24 Sep 2010 04:52:43 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrLn5NDEUI997+sQ+++lfQ4KvlN1CPxHCejABhYIwA= X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4C9C66D9.0063, actions=TAG X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4C9C66E8.02AD,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Thanks, Keri. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 23 September 2010 17:12 To: Donald R. Chapin; SBVR RTF Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion All, In today's discussion it was stated that a copy of Donald's extracted glossary would be more useful if presented in alpha order. Attached is a sorted version (and with SBVR caption-styling applied). Keri On 3/24/10 12:16 PM, "Donald Chapin" wrote: Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion X-KeepSent: B64F593D:25C089BE-852577A8:004E7880; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Fri, 24 Sep 2010 10:18:13 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 09/24/2010 10:18:18 I embedded my comments directly in this version: (See attached file: Issue 13139 SBVR Clauses 10-1-3 as created 2008-12-12 (sorted) MHL.doc) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri ---09/23/2010 05:19:09 PM---All, In today's discussion it was stated that a copy of Donald's extracted From: keri To: "Donald R. Chapin" , SBVR RTF Date: 09/23/2010 05:19 PM Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion -------------------------------------------------------------------------------- All, In today's discussion it was stated that a copy of Donald's extracted glossary would be more useful if presented in alpha order. Attached is a sorted version (and with SBVR caption-styling applied). Keri On 3/24/10 12:16 PM, "Donald Chapin" wrote: Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald [attachment "Issue 13139 SBVR Clauses 10-1-3 as created 2008-12-12 (sorted).doc" deleted by Mark H Linehan/Watson/IBM] Issue 13139 SBVR Clauses 10-1-3 as created 2008-12-12 (sorted) MHL.doc From: Don Baisley To: SBVR RTF Subject: RE: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion Thread-Topic: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion Thread-Index: AcrLn5NDEUI997+sQ+++lfQ4KvlN1CPxHCejAQXrqEA= Date: Wed, 29 Sep 2010 02:16:53 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] I reviewed the proposed terminology. Much of it comes from nowhere . terms not currently used in SBVR. However, in some cases the material reveals places where words in 10.1.1 have been used inconsistently. I have made comments on the entries in the attached document. Best regards, Don From: keri [mailto:keri_ah@mac.com] Sent: Thursday, September 23, 2010 2:12 PM To: Donald R. Chapin; SBVR RTF Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion All, In today's discussion it was stated that a copy of Donald's extracted glossary would be more useful if presented in alpha order. Attached is a sorted version (and with SBVR caption-styling applied). Keri On 3/24/10 12:16 PM, "Donald Chapin" wrote: Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald Content-Type: application/msword; name="Issue 13139 SBVR Clauses 10-1-3 as created 2008-12-12 (sorted).doc" Content-Description: Issue 13139 SBVR Clauses 10-1-3 as created 2008-12-12 (sorted).doc Content-Disposition: attachment; filename="Issue 13139 SBVR Clauses 10-1-3" as created 2008-12-12 (sorted).doc"; size=86528; creation-date="Wed, 29 Sep 2010 00:54:27 GMT"; modification-date="Wed, 29 Sep 2010 02:15:28 GMT" Issue 13139 SBVR Clauses 10-1-3 X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: I9hHoLAVM1ltHbyAW.AuuxTJs3SQAFGPDrRqn9A5qzFN0QX igPDRDBX8ZMH2Zjn6k3rXtB75NtX2TXrnYWFvz38U9lFglUPaXLL8i8AZLbn kxSZJhbfJM0SN7ZycBD.rA1s1hY2TA1zpEBdTHEeA7HavTnoLfUJr_A2RE63 3zj3TYAVpZlSl8V2cexfLjR4dZsTgBfLmllV7uyE4vxmckhqv99YK9q.FqE8 XeTP3D9EA2FwfJl1alQ5n84_DcZdiNRwHFkFlnWzTLXVuRe8GyiQhh1Ruv2v 61vaujYfWaw-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Oct 2010 11:16:02 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments All, In preparation for Friday's discussion, I am recirculating my summary write-up from Tuesday Aug 24 along with comments since that time inserted like this. Earlier discussion including the original post-Minneapolis write-up can be found after that. Ron ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All, We've made good progress on this important issue (too). I would like to get the discussion re-kindled, and move toward a resolution. Here is a quick summary of recent discussion. * I think it's clear we are missing an crucial concept and signifier in Clause 11. I called it ABC in the post-Minneapolis discussion. It's clear to me that ABC is *not* "fact model" as used in the ORM community and elsewhere. This conflation has been causing significant difficulty. * From a Clause 11, business-facing perspective, the concept and signifier "body of shared concepts" is not exactly on-target. Note: This is primarily because alethic elements of guidance can be recognized as separate from concepts in Clause 11. * "Concept system" and its definition should be adopted from ISO for ABC. At 09:05 AM 8/24/2010, Mark H Linehan wrote: What bothers me about this is this is the addition of another "organizing concept" when I think clauses 11 & 12 already have too many: vocabulary, business vocabulary, terminological dictionary, body of shared concepts, body of shared meanings, body of shared guidance, rulebook. Plus we have "conceptual schema" and "fact model". I think we shouldn't add more such concepts without rationalizing the ones we already have. ME: Mark, It's a good point. I don't disagree. But how do we do that? New issue? At 09:05 AM 8/24/2010, Mark H Linehan wrote: I think "concept system" could replace (or become the primary term for) the existing "body of shared meanings" because I think the latter is only intended to include definitional (not behavioral) guidance. ME: I don't disagree. For Clause 11 and 12 purposes (only), I don't really see a need for a term that covers *all* meanings in a semantic community. For *business-facing* purposes, there are concepts and there are elements of guidance. Business people don't abstract elements of guidances into 'meanings'. That seems wonky to me. Over-abstraction for business people. As far as they would go would be to recognize (or not be perturbed by) definitional elements of guidance being part of a concept system. It's a very good point, actually. Clause 11 really needs to stay focused on its purpose and perspective. * I proposed the following additional Clause-11-centric definition for ABC: "set of concepts along with definitional elements of guidance created and structured as a basis for articulating business communications in a consistent manner". (Note: An ABC does not include behavioral elements of guidance.) At 09:05 AM 8/24/2010, Mark H Linehan wrote I think the word "articulating" is wrong in an additional definition for "concept system". I could agree with ".... structured as a basis for conceptualizing business communications ...". ME: "Conceptualize business communications" doesn't sound right. A business communication isn't really 'conceptualized' ... it's ... well ... articulated. Otherwise, there's no way to get your concepts across. How about [NEW]: "set of concepts along with definitional elements of guidance created and structured to organize understanding of the business and to serve as a basis for consistent communication" * I said, "Let's not be coy about the important thing we're getting at here." As soon as you recognize "(a basis for) articulating" in the definition of ABC, it puts a whole new light on the matter. Therefore I proposed "verbal model" and/or "verbalization model" as synonyms. (These are what I use.) MARK LINEHAN [At 01:20 PM 8/24/2010]: Regarding "how about "verbal model" or "verbalization model" as a synonym(s) for "business vocabulary" -- I think these terms would work better for "vocabulary". "Business vocabulary" is just a "vocabulary" with the distinguishing characteristic that it is "under business jurisdiction". ME: I agree. Ron P.S. Important parts of the post-Minneapolis discussion can be found in the e-mails below. At 05:14 PM 6/30/2010, Ronald G. Ross wrote: At 02:51 PM 6/30/2010, Mark H Linehan wrote: Ron, I had not realized that you want to use "articulate" as part of the definition of "ABC". If you use "articulate" then I think you are talking about representations, not meanings. In which case, we already have "terminological dictionary". Here's what the latest version of the definition says: a set of concepts along with definitional elements of guidance, created and structured as a basis for articulating business communications in a consistent manner It says "... as a basis for ...". A concept system *does* provide a 'basis for' articulating in a consistent manner ... a very fundamental basis ... even across multiple languages. (And what other purpose does it serve??) I suggest we add "individual verb concept" to SBVR. Then any concept defined along the lines of "set of concepts ..." should include "individual verb concepts". That completely avoids the issue of whether they are "predefined". I don't have an opinion about that. And who cares whether another individual verb concept is added to an ABC after the ABC is defined. If the District of Columbia ever becomes a state and thus we add "United States includes District of Columbia" then that concept is now part of the concept system. (If a business cares about when states are included in the United States then it should have a verb concept with 3 roles such as "United States includes Hawaii after August 21 1959".) This is not really an engineering question. Businesses must be aware that they generally need to develop or adopt some concept system(s) in order to start in business. It doesn't just suddenly 'happen'. And it's the special part of the they must coordinate and administer going forth as a matter of continuing governance. It's not just your everyday mountain of ground facts. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---06/30/2010 03:17:34 PM---At 01:05 PM 6/30/2010, Mark H Linehan wrote: "Ronald G. Ross" 06/30/2010 03:13 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 01:05 PM 6/30/2010, Mark H Linehan wrote: Ron, I think what you are trying to achieve with 'ABC' is what 'body of shared concepts' should be. If we get 'ABC' defined properly, then I think we could drop the existing 'body of shared concepts'. Then maybe we could agree that "body of shared concepts" is the right signifier for 'ABC'. From my point of view, alethic rules help structure concepts. Whether you think of alethic rules as simply making explicit what is implicit in concept definitions, or as supplementing/extending definitions, they are part of the concept structure and hence belong as part of "body of shared meanings". Consider that you can't make effective use of concepts if you do not know the alethic rules that apply to them. I think this point applies even more to 'concept system', considering the use of the word "structured" in the ISO definition. Mark, I mostly agree with your points. A couple of things: * I don't know if anyone feels strongly about the current definition of "body of shared concepts"(?). *Maybe* that concept is useful to someone as-is. I don't see how it could be without alethic elements of guidance, but that's just my opinion. * From a business-facing Clause 11 point of view, it is possible to have separate alethic elements of guidance. Elements of guidance are propositions, not concepts. So personally, I don't think the signifier "body of shared concepts" quite makes it (again, strictly from a Clause 11, business-facing perspective). I like ISO's "concept system" a little better. I like *structured concept system* more. Most of all, I like "verbal model" or "verbalization model". Let's not be coy about the important thing we're getting at here. As soon as you recognize "articulate" in the definition of ABC, it puts a whole new light on the matter. Regarding "ground facts" -- when I design a set of concepts, I sometimes want to include "individual verb concepts". For example, in concepts about the United States, I might have "United States includes New York" (where "United States" and "New York" are individual concepts). I think this example is a "ground fact" that is predefined as part of an "ABC". The business utility of this example "ABC" partially depends upon such "ground facts". I absolutely agree. Businesses have lots of 'pre-defined' or 'pre-definable' ground facts like that in their concept systems. The problem for the definition of ABC is what is meant by "pre-defined" or "pre-definable". "Pre-" relative to *what*?? In the definition of ABC, I want to avoid that whole question. When you design/develop a concept system, the emphasis is on creating that portion of structured vocabulary that will enable you to *articulate* all (or most) of the business communications (including business rules) you'll need. I *that* is the key observation about what ABC is. IOW, it's a lot more than just a "body". Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/29/2010 05:21 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments At 02:28 PM 6/29/2010, Mark H Linehan wrote: Oops. The last paragraph should read '(On a related topic, I think that we should try to draw "conceptual schema" closer to "body of shared meanings".) ' BTW, I think it is an error that 'body of shared concepts' does not include alethic rules. "Body of shared concepts" is a Clause 11 (business-facing) construct. No matter what SBVR does 'internally' with alethic elements of guidance, from a Clause 11 perspective, rules defined separately from definitions (e.g., necessities) are not concepts, they are ... rules. So allowing "body of shared **concepts**" to include **non**-concepts doesn't make sense to me. What's the point of sharing concepts among a semantic community without sharing the definitions and alethic rules for those concepts? (Definitions are on the expression side.) I agree ... that's why we need "ABC" and a better definition for "vocabulary". Why exactly *do* we need "body of shared concepts" in Clause 11? It's not quite the right concept. But I suppose someone might want it, so I haven't suggested eliminating it. But some thought ought to be given to that. The key is always remembering that Clause 11 must be looked at from the business-facing point of view. What do *business people* need to see, and how at that level will *they* necessarily see it. They *can* see necessities separate from definitions. Doesn't have to be done that way (although SBVR does it that way often), but it *can* be. If we changed 'body of shared concepts' to allow those then (a) maybe it would satisfy 13835, and (b) it would make sense to say that "terminological dictionary expresses body of shared concepts" -- instead of "body of shared meanings". I don't understand what Ron means about ABC excluding "any ground facts you couldn't specify in advance of "day one of business operations"." When you design a concept system, you don't directly address groundnoR .suoivbo ebyaM .yas ot gniyrt m'I lla s'tahT .tey deneppah t'nsah tI .321 redro secalp ZYX remotsuc taht wonk t'nac uoY .meht wonk *t'nac* uoy os ,tey noitarepo ni t'nsi ssenisub ehT .tey wonk t'nod uoy stcaf (Thanks to Ron for pointing out my typo.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Mark H Linehan/Watson/IBM@IBMUS 06/28/2010 09:48 AM To sbvr-rtf@omg.org cc Subject Re: [issue 13835 - "Fact Model"] Re: issue 13139 comments Ron, On the representation side, isn't "terminological dictionary" what you want? I note that "terminological dictionary expresses body of shared meanings " but from the Note under "terminological dictionary" it appears that should exclude the deontic rules. Perhaps if we define your concept "ABC" then we should say that "terminological dictionary expresses ABC ". (On a related topic, I think that we should try to draw "conceptual schema" closer to "conceptual schema".) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/25/2010 07:54 PM Here is the original message (in easier to read form) from 6/25/2010. All, While memory is fresh, let me follow-up on yesterday's discussion in Minneapolis re the agenda item: Issue 13835 Use of the Signifier "Fact Model". I've now done some background research. Actually, there has been significant previous discussion of this topic, but largely under Issue 13139. (Unfortunately, I was unable to locate those e-mails in real time during the meeting itself.) The following analysis (organized into 10 key points) is longish, but aggregates everything into a single message for discussion and (my) future reference. Feedback welcome. 1. I believe Issue 13835 could really be called: Why won't "conceptual schema" or "fact model" as currently defined in SBVR work for Clause 11? To say it another way: What is the missing term for Clause 11? 2. This issue is a critical one. Like "rulebook", the missing term in Clause 11 represents a fundamental notion is *positioning* the purpose of SBVR from a business-facing point of view. Although not necessarily critical for software engineering(?), such positioning is absolutely central in establishing the appropriate market niche / mindset for SBVR itself. 3. It is increasingly clear that the missing concept should be one that *distinguishes* the business-facing side (and value-add purpose) of SBVR from the notion of "fact model" e.g., as in the ORM community. 4. To provide the widest possible umbrella as a standard, SBVR should accommodate that current understanding of "fact model" without change as much as humanly possible. (I believe it does.) SBVR should in no way 'step on' that pre-existing term. To do that was never our intention, of course, but we might have done that unknowingly. 5. Let's call the concept needed in Clause 11 'ABC'. What would an ABC look like? An ABC would ... * have all the noun concepts and verb concepts (including individual concepts) you would need (to pre-define or adopt) in order to start in business tomorrow ("day one of business operations"). * thereafter, include any extensions to that necessary set of concepts based evolving business needs. * primarily include elementary fact types. An ABC would *not* include ... * any deontic elements of guidance whatsoever. * any ground facts you couldn't specify in advance of "day one of business operations". 6. The reason that "conceptual schema" doesn't work for ABC in Clause 11 is the following: conceptual schema FL Definition: combination of concepts and facts (with semantic formulations that define them) of what is possible, necessary, permissible, and obligatory in each possible world "Conceptual schema" includes deontic elements of guidance. It also treats what business people would call "rules" as "facts". That produces a completely unacceptable conflation of business-facing ideas. Business people simply don't say things like, "It's a fact there's a rule that ...". 7. The reason that "fact model" doesn't work for ABC in Clause 11 is the following: fact model FL Definition: combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations using only the concepts of the conceptual schema) "Fact model" also includes deontic elements of guidance. It again treats what business people would call "rules" as "facts". (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 8. The reasons that "body of shared meaning" and "body of shared meaning" don't work for ABC in Clause 11 are the following: body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community "Body of shared meanings" includes deontic elements of guidance. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) body of shared concepts Definition: all of the concepts within a body of shared meanings "Body of shared concepts" excludes all elements of guidance defined separately from definitions, including alethic ones. But definitional rules are most certainly involved in establishing a viable ABC. (In addition, it would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts.) 9. What can ABC be called? ISO has the term "concept system". 3.2.11 concept system system of concepts set of concepts (3.2.1) structured according to the relations among them "Concept system" seems to be close to ABC. Since ISO did not consider rules, I think we can feel free to maintain that definitional rules would be covered by the definition. Possible objections: * The ISO definition doesn't seem friendly to unary fact types (" ... relations among them"). * It might be argued that the ISO definition would encompass ground facts created after "day one of business operations", as well as any and all non-elementary facts(?). (It's is not clear to me whether this is so.) 10. What does SBVR clause 11 really aim at? What signifier(s) best capture(a) the essence of ABC? "verbal model" or "verbalization model" - A major, indeed distinctive, goal of SBVR is to enable the expression of business rule statements and other forms of business communication is such manner that their full semantics can be captured and coordinated. We should emphasize SBVR's unique achievement in that regard by selecting an appropriate signifier, one that incidentally distinguishes ABC from "fact model" (and other 'structural' deliverables such as class diagrams and data models). For the past year or so, I have been using "verbal model" or "verbalization model" in my presentations for that purpose. They work well for that purpose. MWUD ["verbal"]: 2 a : of or relating to words : consisting in or having to do with words ["verbalize"]: 2 : to state something in words : make a verbal statement Note: If "concept system" is adopted from ISO, "verbal model" and/or "verbalization model" should be synonyms. "structured business vocabulary" - Clearly, that's what SBVR itself is -- SBVR has been described as a vocabulary for developing vocabularies. Like ISO (refer to the definition of "concept system"), we need to emphasize that Clause 11 is about creating a special kind of vocabulary, one that is *structured* (i.e., has verb concepts, etc.). Note: "Structured business vocabulary" encompasses representation of meanings, not just meanings per se (i.e., it does not align with "concept system" in that regard). The current definition of "vocabulary" in SBVR is: vocabulary Definition: set of designations and fact type forms primarily drawn from a single language to express concepts within a body of shared meanings "Structured business vocabulary" can probably be defined as a synonym of "vocabulary". It's usefulness is that people don't normally think of fact type forms being in a vocabulary, yet that is a central, distinguishing characteristic of SBVR (i.e., to serve to support models for verbalization of business rules, etc.). Ron Date: Thu, 07 Oct 2010 21:07:42 +0100 From: John Hall User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 To: Don Baisley CC: SBVR RTF Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion X-Mailcore-Auth: 4600872 X-Mailcore-Domain: 13170 Hello all, I understand from Donald that he is annotating Don.s comments with his notes on the Clause 10 definitions, and he plans to distribute that soon. As a separate exercise, I have been looking at SBVR.s formal logic interpretation (based on ORM and Terry.s thesis) from the perspective of defining the transformation from the SBVR metamodel (Clauses 8, 9, 11 and 12) to Clause 10. I.ve summarized my work to date in the attached note. If others are interested, I.m happy to put this into the SBVR pot. If not, I will continue to develop this for my own work. Cheers, John On 29/09/2010 03:16, Don Baisley wrote: I reviewed the proposed terminology. Much of it comes from nowhere . terms not currently used in SBVR. However, in some cases the material reveals places where words in 10.1.1 have been used inconsistently. I have made comments on the entries in the attached document. Best regards, Don From: keri [mailto:keri_ah@mac.com] Sent: Thursday, September 23, 2010 2:12 PM To: Donald R. Chapin; SBVR RTF Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion All, In today's discussion it was stated that a copy of Donald's extracted glossary would be more useful if presented in alpha order. Attached is a sorted version (and with SBVR caption-styling applied). Keri On 3/24/10 12:16 PM, "Donald Chapin" wrote: Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald --------------------------------------------------------------------------------------------------- Text inserted by Panda GP 2010: This message has NOT been classified as spam. If it is unsolicited mail (spam), click on the following link to reclassify it: It is spam! --------------------------------------------------------------------------------------------------- SBVR 13139 note JH [20101007].doc Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion X-KeepSent: 00848F42:9DE88A16-852577B5:0071A7BC; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Thu, 7 Oct 2010 16:57:28 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/07/2010 16:57:30 John, I'm not sure what you mean by a "transformation to clause 10". May I suggest that you add to the introduction of this paper a discussion of (a) what the objectives of this transformation are; (b) what this transformation might look like. Is it an algorithm? Is it 2-way or 1-way? What criteria would we use to judge success or failure? I understand that SBVR is grounded on Terry's thesis but I wonder if that's the right place to put our effort considering that it is not a standard. An alternative that is on my mind is ISO Common Logic, because (a) it is a standard; (b) advocates claim that it is small, and fully covers first-order logic. (But they do acknowledge the need for extensions -- proposed in something called IKL -- for objectification and modalities.) We have limited resources to work this problem. How many of us -- or the rest of the modeling world -- want to become expert in ORM or Terry's thesis? Maybe the right answer is an SBVR v2 that is based on something like Common Logic rather than Terry's thesis. The data-oriented perspective of Terry's thesis is a particular reason to be skeptical about it. As you rightly note, SBVR's deontic rules are about behavior, not data. I think trying to understand deontic rules as data constraints is very limiting. Better to understand them as business process constraints. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com John Hall ---10/07/2010 04:10:13 PM--- Hello all, I understand from Donald that he is annotating Don's comments with his From: John Hall To: Don Baisley Cc: SBVR RTF Date: 10/07/2010 04:10 PM Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion -------------------------------------------------------------------------------- Hello all, I understand from Donald that he is annotating Donâs comments with his notes on the Clause 10 definitions, and he plans to distribute that soon. As a separate exercise, I have been looking at SBVRâs formal logic interpretation (based on ORM and Terryâs thesis) from the perspective of defining the transformation from the SBVR metamodel (Clauses 8, 9, 11 and 12) to Clause 10. Iâve summarized my work to date in the attached note. If others are interested, Iâm happy to put this into the SBVR pot. If not, I will continue to develop this for my own work. Cheers, John On 29/09/2010 03:16, Don Baisley wrote: I reviewed the proposed terminology. Much of it comes from nowhere . terms not currently used in SBVR.. However, in some cases the material reveals places where words in 10.1.1 have been used inconsistently. I have made comments on the entries in the attached document. Best regards, Don From: keri [mailto:keri_ah@mac.com] Sent: Thursday, September 23, 2010 2:12 PM To: Donald R. Chapin; SBVR RTF Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion All, In today's discussion it was stated that a copy of Donald's extracted glossary would be more useful if presented in alpha order. Attached is a sorted version (and with SBVR caption-styling applied). Keri On 3/24/10 12:16 PM, "Donald Chapin" wrote: Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald --------------------------------------------------------------------------------------------------- Text inserted by Panda GP 2010: This message has NOT been classified as spam. If it is unsolicited mail (spam), click on the following link to reclassify it: It is spam! --------------------------------------------------------------------------------------------------- [attachment "SBVR 13139 note JH [20101007].doc" deleted by Mark H Linehan/Watson/IBM] Date: Fri, 08 Oct 2010 10:32:55 +0100 From: John Hall User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 To: Mark H Linehan , SBVR RTF Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion X-Mailcore-Auth: 4600872 X-Mailcore-Domain: 13170 Mark, Partial responses in-line, John On 07/10/2010 21:57, Mark H Linehan wrote: John, I'm not sure what you mean by a "transformation to clause 10". [JH] I hoped I had demonstrated this with the examples from Clause 10. We claim to have a formal logic interpretation of SBVR, but its basis is the FOL proofs in Terry's thesis that underpin Clause 10. The problem is that Clause 10 is about ORM. We don't have an explicit relationship between the SBVR metamodel (Clauses 8, 9, 11, 12) and Clause 10. We do have some semantically equivalent constructs, such as: Clause 10 derivation rule: Each FemaleAustralian is a Person who was born in Country .Australia. and has Gender .Female. SBVR BOSM intensional definition for object type: female Australian Definition: person who was born in Australia and is female May I suggest that you add to the introduction of this paper a discussion of (a) what the objectives of this transformation are; [JH] I started defining these correspondences so that I could demonstrate that what we say in a BOSM (or much of it) can be transformed into its equivalent in Clause 10, and does have the claimed formal logic interpretation. (b) what this transformation might look like. Is it an algorithm? [JH] I currently visualize it as a set of mappings and transformations - BOSM construct to Clause 10 construct, as in the example above. I don't expect all of them to be simple mappings. I also expect that I (or we) will not get a complete set in this RTF, but I hope that a Pareto principle will apply. The more difficult cases would probably be assigned to an issue for SBVR 1.2. I don't expect a fully-automatable algorithm. Some transformations will require decisions about how the business requirements will be supported by the data model. Is it 2-way or 1-way? [JH] I am looking at BOSM - ORM. A reverse approach ought to be feasible - but it would produce a BOSM only for those aspects of the business that are represented in a relational data model What criteria would we use to judge success or failure? [JH] Not sure yet of objective criteria, but completeness of some BOSM examples would be a good start I understand that SBVR is grounded on Terry's thesis but I wonder if that's the right place to put our effort considering that it is not a standard. [JH] The formal logic interpretation of SBVR is based on Terry's thesis. We are constrained by the OMG RTF process. We have two choices: Leave Clause 10 as is, and report back that we don't have a formal logic interpretation that is demonstrable from BOSM to FOL Fix as much of Clause 10 as we can and group the unresolved parts into an issue for SBVR 1.2 What we can't do is switch horses as part of an RTF An alternative that is on my mind is ISO Common Logic, because (a) it is a standard; (b) advocates claim that it is small, and fully covers first-order logic. (But they do acknowledge the need for extensions -- proposed in something called IKL -- for objectification and modalities.) [JH] Of course, you could start this. But it would have to be via an RFP for a new version of SBVR - it can't be done in this RTF. [BTW: my personal preference would be DMN/PRR/RIF/OWL2 rather than CL] We have limited resources to work this problem. [JH] So, what would be your proposal for finishing the formal logic interpretation part of this RTF? How many of us -- or the rest of the modeling world -- want to become expert in ORM or Terry's thesis? [JH] We don't have to become expert in Terry's thesis. The reason the BRT chose the ORM solution is that Terry's thesis is a respected piece of academic work. The relationship between Clause 10 and the thesis is trusted (subject to a little tidying of Terry's language in Clause 10, which Donald and Don are working on). We can take it as true that valid models built from Clause 10 constructs have valid formal logic interpretations. What we need is to understand the relationship between BOSM and Clause 10. My suggestion is to do it by semantic construct, rather than concept by concept. Maybe the right answer is an SBVR v2 that is based on something like Common Logic rather than Terry's thesis. [JH] I would be happy to participate - but it won't happen quickly The data-oriented perspective of Terry's thesis is a particular reason to be skeptical about it. As you rightly note, SBVR's deontic rules are about behavior, not data. I think trying to understand deontic rules as data constraints is very limiting. Better to understand them as business process constraints. [JH] I agree that this is an important point. It may be that the Clause 10 basis for formal logic interpretation is only static - concepts and alethic rules (something like this has been discussed in other issues). The deontic rules might be better addressed via a new RFP to integrate SBVR and BPMN, which has been discussed in BMI. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com John Hall ---10/07/2010 04:10:13 PM--- Hello all, I understand from Donald that he is annotating Don's comments with his From: John Hall To: Don Baisley Cc: SBVR RTF Date: 10/07/2010 04:10 PM Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion -------------------------------------------------------------------------------- Hello all, I understand from Donald that he is annotating Don.s comments with his notes on the Clause 10 definitions, and he plans to distribute that soon. As a separate exercise, I have been looking at SBVR.s formal logic interpretation (based on ORM and Terry.s thesis) from the perspective of defining the transformation from the SBVR metamodel (Clauses 8, 9, 11 and 12) to Clause 10. I.ve summarized my work to date in the attached note. If others are interested, I.m happy to put this into the SBVR pot. If not, I will continue to develop this for my own work. Cheers, John On 29/09/2010 03:16, Don Baisley wrote: I reviewed the proposed terminology. Much of it comes from nowhere . terms not currently used in SBVR. However, in some cases the material reveals places where words in 10.1.1 have been used inconsistently. I have made comments on the entries in the attached document. Best regards, Don From: keri [mailto:keri_ah@mac.com] Sent: Thursday, September 23, 2010 2:12 PM To: Donald R. Chapin; SBVR RTF Subject: Re: [SBVR-RTF] -- Issue 13139 -- Clause 10.1.3 Vocabulary as Used In Clause 10.1.1 Resulting from last RTF Discussion All, In today's discussion it was stated that a copy of Donald's extracted glossary would be more useful if presented in alpha order. Attached is a sorted version (and with SBVR caption-styling applied). Keri On 3/24/10 12:16 PM, "Donald Chapin" wrote: Attached is the Clause 10.1.3 vocabulary as used in Clause 10.1.1 as discussed at the December 11, 2008 SBVR RTF and updated the next day to reflect the discussion. Donald --------------------------------------------------------------------------------------------------- Text inserted by Panda GP 2010: This message has NOT been classified as spam. If it is unsolicited mail (spam), click on the following link to reclassify it: It is spam! --------------------------------------------------------------------------------------------------- [attachment "SBVR 13139 note JH [20101007].doc" deleted by Mark H Linehan/Watson/IBM] --------------------------------------------------------------------------------------------------- Text inserted by Panda GP 2010: This message has NOT been classified as spam. If it is unsolicited mail (spam), click on the following link to reclassify it: It is spam! --------------------------------------------------------------------------------------------------- From: "Donald Chapin" To: Subject: [SBVR-RTF] -- Revised Issue 13139 Terminology for SBVR Clause 10.1.1 Date: Thu, 9 Dec 2010 04:41:33 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcuXnmbbAIwc5eTDQYuUZ0CtXxn+FQ== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4D00CE81.0168, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4D00CF22.00C8,ss=1,vtr=str,vl=0,pt=DBB_65837,fgs=0, ip=69.181.136.151, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false All . Attached is the December 2008 proposed resolution for Issue 13139 with the following changes: - sorted alphabetically by Keri at the team.s request - with comments by Don Baisley - with disambiguating term changes removed and replaced by the original terms as they appear in Clause 10.1.1 as these are a separate Issue outside the scope of this Issue -- which is to merely provide a vocabulary for Clause 10.1.1 as it appears in SBVR 1.0 with the original meanings that made for a consistent and cohesive formal interpretation. - the first part of the posting of the source evidence that was used to create this vocabulary from the wording in Clause 10.1.1. It is hoped that with the disambiguating term changes removed that it will be necessary to provide such source evidence to the team only on an exception basis. Also attached is an email written by Terry Halpin in December 2008 when this proposed solution was first prepared stating that this represents the meaning of the terms as written in Clause 10.1.1. There are 2-3 small fixes that he pointed out. Any concerns about what Clause 10.1.1 currently says need to be raised in separate Issues. This is Issue is just to provide a vocabulary for Clause 10.1.1 as it stands in the formal published SBVR 1.0 specification. Donald Issue 13139 SBVR Clauses 10-1-3 as created 2008-12-12 (sorted) with Don B's Notes + Removal of Disambiguating Term Changes.doc Received: from 69.27.21.247 (EHLO mail.neumont.edu) (69.27.21.247) by mta833.mail.ukl.yahoo.com with SMTP; Thu, 04 Dec 2008 20:45:59 +0000 From: "Terry Halpin" To: Cc: References: <6520E8F7DE564535BA8A081B2EACBE83@DonaldChapin> Subject: RE: Can You Review the Change-Tracked Vocabulary for Your SBVR Clause 10.1.1 Formal Semantics Text? Date: Thu, 4 Dec 2008 12:45:55 -0800 Message-ID: <94B0B6D99C23814183603495006136930239B2AD@northfacemail2.northface.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01CB975B.5C3004A0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWFPIdUw7bx0NQT8CnUmQ8x7GSawAOMrdw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Originating-IP: [69.27.21.247] In-Reply-To: <6520E8F7DE564535BA8A081B2EACBE83@DonaldChapin> X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message x-apparently-to: donald.chapin@btinternet.com via 217.146.188.138; Thu, 04 Dec 2008 20:46:00 +0000 Hi Donald I am swamped with work and also still recovering from a nasty flu, so this will be brief. Overall the 10.1.3 document looks basically OK. The deleted Figure 8.8 has several errors, so it is good to have it removed. Here are some remaining issues. The following definition is problematic. The intent is simply to classify the kinds of individuals that participate in facts. conceptual schema includes type of individual FL Definition: the type of individual is used to define parts that individuals play in ground facts in fact model populations based on the conceptual schema The following definition is awkward. Suggest shorten it to .A ground fact type role is a part played by an individual in a ground fact.. conceptual schema includes ground fact type role FL Definition: the ground fact type role is a part played by a individuals of a type of individual in ground facts in a fact model populations based on the conceptual schema The following definition is problematic. Suggest replace .for each fact population. by .for each state of the fact model taken individually.. static constraint FL Definition: rule that defines bounds, borders, or limits on fact populations and that imposes a restriction on what fact populations are possible or permitted, for each fact population taken individually I don.t have time right now to look at the other document. After Neumont sacked Andy, all his classes were added to my teaching schedule, so I am severely overloaded. Hope this is of some small help. Cheers Terry From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Thursday, December 04, 2008 6:34 AM To: Terry Halpin Cc: john.hall@modelsys.com Subject: Can You Review the Change-Tracked Vocabulary for Your SBVR Clause 10.1.1 Formal Semantics Text? Importance: High Hi Terry, Could you review the attached change-tracked document to see if it is an accurate vocabulary for the terms that you used, as you used them, in the text for the SBVR formal semantics that you wrote in Clause 10.1.1? I need this as soon as you can do it. There.s nothing in it that.s not in Clause 10.1.1 as far as I know . so it should be quick for you. I spent hours (days) trawling your SBVR Clause 10.1.1 text to create a faithful and accurate vocabulary for it (and nothing else) to resolve two pending SBVR sub-Issues (11296-1a and 11303-b). I.ve also attached the Issue Resolution with the editing instructions, but there.s no need to look at that as the change tracked document is the exact outcome of those editing instructions. As soon as you let me know that there are no significant problems in the change-tracked document and/or send me any corrections necessary to align it with the wording and intent of Clause 10.1.1, I need to post the editing instructions on the SBVR RTF email. Many Thanks, Donald