Issue 14843: Concepts-centric Model and Fact Model are different (sbvr-rtf) Source: Rule ML Initiative (Mr. John Hall, john.hall(at)modelsystems.co.uk) Nature: Uncategorized Issue Severity: Summary: The definition-based model specified in Clauses 8, 9, 11, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns: 1. Separation of the two different meanings of 'fact type' into different models 2. Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption. Resolution: Revised Text: Actions taken: December 9, 2009: received issue Discussion: The overt problem is that SBVR has two different meanings for 'fact type': 1. In Clause 8, the extension of a fact type is currently a set of actualities, (although another issue proposes that this should be changed to a set of states of affairs) 2. In Clause 10, the extension of a fact type is a set of facts (propositions taken to be true). The underlying issue is: 1. SBVR's metamodel is defined in Clauses 8, 9, 11, 12 and 13. Its instances (domain models) are linguistic models of meanings. 2. The model defined in Clause 10 is included in the normative SBVR model to support a formal logic interpretation of SBVR's metamodel. Its instances (domain models) are fact models. The proposed resolution is: 1. State, in introductory text in Clauses 8 and 10, that the models are different 2. Somewhere in Clause10: a. List the major differences between the two models (see below) b. Describe informally the transformation to derive a domain fact model from a corresponding linguistic model. It is probably beyond the scope of this RTF to develop a formal specification of the transformation 3. Define fact models to be 'closed world' models. Another useful change would be to move the current Clause 10 so that it is placed after the clauses that define the SBVR metamodel - i.e. to renumber Clauses 11, 12 and 13 as 10, 11, 12 respectively, and renumber Clause 10 as 13. One of the reasons for raising this issue is the email discussion about Issue 14241 "Coexistence approach to SBVR" earlier this year. There, a case was made for allowing a fact model to be 'closed world', to enable it to be used as the basis for business applications that will run on relational databases using SQL. There was some discussion that SBVR was not primarily intended to model business applications; it was intended to model the business to be supported by these applications, and the models needed to be 'open world'. When the two kinds of model are recognized as being different, both needs can be satisfied: § The linguistic model defined in Clauses 8, 9, 11, 12 and 13 is the semantic community's open world model of its business. § The corresponding clause 10 fact model is the closed world model that is the basis for developing the data model and database for the required business applications. The transformations to these specifications are well-defined in both ORM and CogNIAM (the two fact modeling approaches described in Annexes of the SBVR Specification). One concern to be kept in mind is that the detail of specification in fact models (identifiers, data types, formats etc.) should not replicate capabilities already provided in other OMG specifications, especially UML and IMM. Dependencies with other Issue Resolutions Issue 10803: 'state of affairs' is an individual concept, not a thing If 'state of affairs' were deemed to be to be an individual concept, the argument here for the differences between the two models would not be substantially changed. Issue 13138: Move Fact Model Container Concepts from Clause 8 to Clause 10 A new issue has been submitted, proposing that the definitions in Subclause 8.5 be moved to Clause 13. Issue 14241: Coexistence approach to SBVR The proposed resolution here includes: 'closed world' assumption for Clause 10 fact model; fact type (Clause 8) having an extension that consists of states of affairs; fact type (Clause 10) having an extension that consists of facts. Issue (awaiting number): Each individual in the extension of a fact type (Clause 8) should be a 'state of affairs'. The proposed resolution here assumes that the extension of a fact type (Clause 8) is states of affairs. Resolution: See the discussion "Differences between Linguistic Model (Clauses 8, 9, 11, 12) and Fact Model (Clause 10)", below Revised Text: To be developed after discussion with RTF Disposition: Open End of Annotations:===== sposition: Open OMG Issue No: nnnnn Title: SBVR Linguistic Model and Fact Model are different models Source: Inferware, John Hall, (john.hall@modelsystems.co.uk) Summary: The definition-based model specified in Clauses 8, 9, 11, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns: 1. Separation of the two different meanings of .fact type. into different models 2. Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption. Discussion: The overt problem is that SBVR has two different meanings for .fact type.: 1. In Clause 8, the extension of a fact type is currently a set of actualities, (although another issue proposes that this should be changed to a set of states of affairs) 2. In Clause 10, the extension of a fact type is a set of facts (propositions taken to be true). The underlying issue is: 1. SBVR.s metamodel is defined in Clauses 8, 9, 11, 12 and 13. Its instances (domain models) are linguistic models of meanings. 2. The model defined in Clause 10 is included in the normative SBVR model to support a formal logic interpretation of SBVR.s metamodel. Its instances (domain models) are fact models. The proposed resolution is: 1. State, in introductory text in Clauses 8 and 10, that the models are different 2. Somewhere in Clause10: a. List the major differences between the two models (see below) b. Describe informally the transformation to derive a domain fact model from a corresponding linguistic model. It is probably beyond the scope of this RTF to develop a formal specification of the transformation 3. Define fact models to be .closed world. models. Another useful change would be to move the current Clause 10 so that it is placed after the clauses that define the SBVR metamodel . i.e. to renumber Clauses 11, 12 and 13 as 10, 11, 12 respectively, and renumber Clause 10 as 13. One of the reasons for raising this issue is the email discussion about Issue 14241 .Coexistence approach to SBVR. earlier this year. There, a case was made for allowing a fact model to be .closed world., to enable it to be used as the basis for business applications that will run on relational databases using SQL. There was some discussion that SBVR was not primarily intended to model business applications; it was intended to model the business to be supported by these applications, and the models needed to be .open world.. When the two kinds of model are recognized as being different, both needs can be satisfied: § The linguistic model defined in Clauses 8, 9, 11, 12 and 13 is the semantic community.s open world model of its business. § The corresponding clause 10 fact model is the closed world model that is the basis for developing the data model and database for the required business applications. The transformations to these specifications are well-defined in both ORM and CogNIAM (the two fact modeling approaches described in Annexes of the SBVR Specification). One concern to be kept in mind is that the detail of specification in fact models (identifiers, data types, formats etc.) should not replicate capabilities already provided in other OMG specifications, especially UML and IMM. Dependencies with other Issue Resolutions Issue 10803: 'state of affairs' is an individual concept, not a thing If .state of affairs. were deemed to be to be an individual concept, the argument here for the differences between the two models would not be substantially changed. Issue 13138: Move Fact Model Container Concepts from Clause 8 to Clause 10 A new issue has been submitted, proposing that the definitions in Subclause 8.5 be moved to Clause 13. Issue 14241: Coexistence approach to SBVR The proposed resolution here includes: .closed world. assumption for Clause 10 fact model; fact type (Clause 8) having an extension that consists of states of affairs; fact type (Clause 10) having an extension that consists of facts. Issue (awaiting number): Each individual in the extension of a fact type (Clause 8) should be a .state of affairs.. The proposed resolution here assumes that the extension of a fact type (Clause 8) is states of affairs. Resolution: See the discussion .Differences between Linguistic Model (Clauses 8, 9, 11, 12) and Fact Model (Clause 10)., below Revised Text: To be developed after discussion with RTF Disposition: Open Differences between Linguistic Model (Clauses 8, 9, 11, 12, 13) and Fact Model (Clause 10) The clause numbers in the following table are the current ones, not the suggested renumbering above. Feature Linguistic Model (Clauses 8, 9, 11, 12, 13) Fact Model (Clause 10) Scope Body of shared meanings for a semantic communityNote: some linguistic models are not transformed into database-centric fact models. For example, a model for legal contracts would probably be transformed into a specification for a content management application. Basis for data schema for database-centric application systems.Note: it is possible to develop a fact model directly (i.e. without deriving it from a linguistic model Focus Models meanings Models facts World view Open Closed [proposed in this issue] Communities Semantic community, speech communities Semantic community is mentioned in .General Requirements for Formal Logic Interpretation., otherwise plays no part. Structure Flat (like a dictionary) In levels of abstraction (needed for FOL) Definitions Noun concept definitions are: intensional (characteristic-based), extensional or adopted Noun concept definitions are informal Fact type and fact Clause 8 fact type.s extension is actualities [states of affairs proposed] Clause 10 fact type.s extension is facts (propositions taken to be true) General Concepts and Fact types Noun concepts, (clause 8) fact types (Clause 10) fact types (that have instances) and the noun concepts that play roles in them Individuals Individual concepts that are explicitly defined, or included in extensional definitions.Illustrative examples (as text) (At least) the population of representative facts from which fact types have been abstracted Guidance Structural business rules, advices of possibilityBusiness policies, operative business rules, advices of permission Structural business rulesSome operative business rules will not be automated. Additional noun concepts and fact types may be needed in the fact model for recording human actions, supporting human decisions. Representations Representations of: noun concepts, fact types, fact type forms, structural and operative business rules, in vocabularies owned by all speech communities in the semantic community. A set of preferred representations of the concepts and structural rules that are within the scope of the fact-based formal interpretation. Speech communities and their vocabularies are not recognizedTo be discussed . are the following essential to fact models, or .in practice. (methodology and tooling) concerns? 1. Data types and formats2. Synonymous forms of fact types being restricted to readings based on a single fact type symbol (verb) m: "Donald Chapin" To: Subject: RE: issues 14843 -- SBVR RTF issues Date: Fri, 11 Nov 2011 12:21:24 -0000 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcygbG3Um6M+2/RrQQSqVwRvk7ZNBw== X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0302.4EBD134A.00CE, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.11.11.114515:17:9.975, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, LINK_TO_IMAGE, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __IMGSPAM_BODY, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_70_90, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK, IMGSPAM_BODY X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4EBD13E9.0146,ss=1,vtr=str,vl=0,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Attached is the resolution for Issue 14843 that states that Issue 14843 was merged into Issue 15623. From: Juergen Boldt [mailto:juergen@omg.org] Sent: 23 December 2009 17:14 To: issues@omg.org; sbvr-rtf@omg.org Subject: issues 14843 - 14844 -- SBVR RTF issues This is issue # 14843 SBVR Linguistic Model and Fact Model are different models The definition-based model specified in Clauses 8, 9, 11, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns: 1. Separation of the two different meanings of 'fact type' into different models 2. Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption. ========================================================= This is issue # 14844 Move the Definitions in Subclause 8.5 to Clause 13 Subclause 8.5 is about the interchange files defined in Clause 15. The syntax for these files is (mostly) defined in Clause 13; the content of Subclause 8.5 should be placed in Clause 13. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Draft Resolution for SBVR Issue 14843 - Linguistic Model and Fact Model are different (2011-11-11).doc Disposition: Duplicate or Merged OMG Issue No: 14843 Title: SBVR Linguistic Model and Fact Model are different models Source: Inferware, John Hall, (john.hall@modelsystems.co.uk) Summary: The definition-based model specified in Clauses 8, 9, 10, 12 and 13 and the fact model defined in Clause 10 are different (although closely related) models. The differences between them should be described and a transformation from one to the other defined. This would address two concerns: 1. Separation of the two different meanings of .fact type. into different models 2. Allow the definition-based model to have an open-world assumption and the fact model to have a closed-world assumption. Discussion: The overt problem is that SBVR has two different meanings for .fact type.: 1. In Clause 8, the extension of a fact type is currently a set of actualities, (although another issue proposes that it should be changed to a set of states of affairs) 2. In Clause 10, the extension of a fact type is a set of facts (propositions taken to be true). The underlying issue is: 1. SBVR.s metamodel is defined in Clauses 8, 9, 10, 12 and 13. Its instances (domain models) are linguistic models of meanings. 2. The model defined in Clause 10 is included in the normative SBVR model to support a formal logic interpretation of SBVR.s metamodel. Its instances (domain models) are fact models. The proposed resolution is: 1. State, in introductory text in Clauses 8 and 10, that the models are different 2. Somewhere in Clause10: a. List the major differences between the two models b. Describe informally what transformation would be needed to derive a domain fact model from a corresponding linguistic model. It is probably beyond the scope of this RTF to develop a formal specification 3. Define fact models to be closed world models. One of the reasons for raising this issue is the email discussion about Issue 14241 .Coexistence approach to SBVR. earlier this year. There, a case was made for allowing a fact model to be .closed world., to enable it to be used as the basis for business applications that will run on relational databases using SQL. There was some discussion that SBVR was not primarily intended to model business applications, but the business to be supported by these applications, and the models needed to be open world. When the two kinds of model are recognized as being different, both needs can be satisfied: . The linguistic model defined in Clauses 8, 9, 11, 12 and 13 is the semantic community.s open world model of its business. . The corresponding clause 10 fact model is the closed world model that is the basis for developing the data model and database for the required business applications. The transformations to these specifications are well-defined in both ORM and CogNIAM (the two fact modeling approaches described in Annexes of the SBVR Specification). One concern to be kept in mind is that the detail of specification in fact models (identifiers, data types, formats etc.) should not replicate capabilities already provided in other OMG specifications, especially UML and IMM. Resolution: Merged with Issue 15623 Revised Text: No change. Disposition: Duplicate or Merged Date: Fri, 11 Nov 2011 12:26:39 +0000 From: John Hall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 To: SBVR RTF Subject: [SBVR] Suggested change to resolution of 15623 & 14843 X-Mailcore-Auth: 4600872 X-Mailcore-Domain: 13170 Hello all, Since I submitted Issue 14843 (now merged with 15623) almost two years ago, we have had some discussion of open and closed world semantics. In the spin-off issue mentioned in item 6 of the resolution of 15623 & 14843, I would prefer the proposed resolution to be less rigid than in the original issue. My suggestion is to change the wording of Item 6 from "... defining Clause 10 .fact model. to be closed world. to "... defining that Clause 10 .fact models. are by default closed world models. Regards, John To: SBVR RTF Subject: Re: [SBVR] Suggested change to resolution of 15623 & 14843 X-KeepSent: 3EA632F9:7FECDE6A-85257945:00499AB2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Fri, 11 Nov 2011 08:25:31 -0500 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 11/11/2011 08:25:33, Serialize complete at 11/11/2011 08:25:33 x-cbid: 11111113-1976-0000-0000-000002711EE9 I don't think SBVR uses "closed world" by default in clause 10 any more than it uses it in any other clause. In any case, this discussion can come be entered with the spinoff issue called for in the resolution text. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: John Hall To: SBVR RTF Date: 11/11/2011 07:29 AM Subject: [SBVR] Suggested change to resolution of 15623 & 14843 -------------------------------------------------------------------------------- Hello all, Since I submitted Issue 14843 (now merged with 15623) almost two years ago, we have had some discussion of open and closed world semantics. In the spin-off issue mentioned in item 6 of the resolution of 15623 & 14843, I would prefer the proposed resolution to be less rigid than in the original issue. My suggestion is to change the wording of Item 6 from "... defining Clause 10 âfact modelâ to be closed worldâ to "... defining that Clause 10 âfact modelsâ are by default closed world modelsâ Regards, John