Issue 12540: Clause 8 does not include the concepts needed to represent itself (sbvr-rtf) Source: International Business Machines (Mr. Mark H. Linehan, mlinehan(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: SBVR currently has multiple concepts for organizing vocabularies and rules: * conceptual schema (clause 8.5) * fact model (8.5) * body of shared meanings (11.1.1) * body of shared concepts (11.1.1) * terminological dictionary (11.1.1) * vocabulary (11.1.1) * rulebook (11.2.2.4) Some issues: 1) Clause 8 does not include the concepts needed to represent itself, even though clause 2 says clause 8 is a standalone compliance point. Clause 8 claims to be a vocabulary, but the concept "vocabulary" is in clause 11, not clause 8. Hence an implementation of clause 8 cannot model clause 8 itself. Resolution: Revised Text: Actions taken: June 20, 2008: received issue Discussion: End of Annotations:===== s is issue # 12540 Clause 8 does not include the concepts needed to represent itself SBVR currently has multiple concepts for organizing vocabularies and rules: * conceptual schema (clause 8.5) * fact model (8.5) * body of shared meanings (11.1.1) * body of shared concepts (11.1.1) * terminological dictionary (11.1.1) * vocabulary (11.1.1) * rulebook (11.2.2.4) Some issues: 1) Clause 8 does not include the concepts needed to represent itself, even though clause 2 says clause 8 is a standalone compliance point. Clause 8 claims to be a vocabulary, but the concept "vocabulary" is in clause 11, not clause 8. Hence an implementation of clause 8 cannot model clause 8 itself. 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:X-MimeOLE:In-Reply-To:Thread-Index; b=Ah7kEzD3T6XsuKWeQPGmfFNshnYyQXnXOSVgZm4sgzUaIskfTqo38Lwp+yuKmW8AuRLwAV7ykcEsWQIY83ri+VXX3VJvXcT9sGYq7H3TTl340T3xM9HnxQ+X6KyGaeR5FavRmOM7ByZiNNqYxOdV1TEJu80X+T3Q39tfUlA793k= ; X-YMail-OSG: jSrHZCcVM1nD6hueb8IE2ui92NI8p3aiAsaGseS28uB_rwLuD_nQfo_n9Su9ZGyLpRLW8FJzuz7.A3kKTqYV5XGDh_McuoHO0xiZYWruZ_Y8fFx.P6YEs2gZPylHEbWIa_DTIZY4RvX0eVxLhYQzXFGv_RksSZ_z.qGB6rhHhTMEE1M7DYjsQYXsPjw- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: RE: issues 12540 -- SBVR RTF issues Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjTEV2zkSKM8qZySmS+n+wXc5/KJyC+qarg All -- Attached is a proposed resolution for Issue 12540 for discussion at next Thursday's face to face SBVR RTF meeting. This proposed Issue resolution is a part of a package of three proposed Issue resolutions. The other two will be posted in response to the two new (spin-off) Issues submitted at the same time that this proposed Issue resolution was posted to the SBVR RTF email. Donald > -----Original Message----- > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: Friday, June 20, 2008 9:07 PM > To: issues@omg.org; sbvr-rtf@omg.org > Subject: issues 12540 -- SBVR RTF issues > > This is issue # 12540 > > Clause 8 does not include the concepts needed to represent itself > > SBVR currently has multiple concepts for organizing vocabularies and > rules: > > > * conceptual schema (clause 8.5) > * fact model (8.5) > * body of shared meanings (11.1.1) > * body of shared concepts (11.1.1) > * terminological dictionary (11.1.1) > * vocabulary (11.1.1) > * rulebook (11.2.2.4) > > > Some issues: > > > 1) Clause 8 does not include the concepts needed to represent itself, even > though clause 2 says clause 8 is a standalone compliance point. Clause 8 > claims to be a vocabulary, but the concept "vocabulary" is in clause 11, > not clause 8. Hence an implementation of clause 8 cannot model clause 8 > itself. > > ================================================================ > > > 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 Proposed Issue 12540 Resolution 2008-12-04.doc 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 Subject: Issue 12540 open questions To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 25 Mar 2009 17:15:40 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/25/2009 17:15:43 Per our discussion, this afternoon, I think we need the following to address this issue: 1. We should have a separate subsection of clause 13 that describes how fact models map to XMI documents. Currently, this information is buried in the last paragraph above 13.2 and in the discussion of the example in 13.4. Also, the following details are missing: * Where do the URIs for the fact model and conceptual schema come from, given that the SBVR metamodel does not provide URIs for these concepts. * Can one specify multiple conceptual schemas on the XMI document element? Does this mean multiple instances of "fact model is based on conceptual schema"? * Can a or a element appear within an SBVR XMI document? If so, what does it mean? * How does one encode in an XMI document instances of the clause 8.5 fact types? For example, how do you encode a fact based on "concept is closed in conceptual schema" when the "conceptual schema" is given as a namespace on the element rather than as a element? Ditto for facts that involve references to "fact models" such as "fact model includes fact". 2. A clause 8 implementation of clause 8 or 9 omits the fact because that fact depends upon the concept that is part of clause 11 implementations. (The purpose of this is to tell implementors not to worry about the vocabulary name for clause 8 or 9 if the implementor is only supporting clause 8.) 3. Clause 8.3.5 uses the clause 11 concept "vocabulary". This make it impossible to implement clause 8 as a standalone compliance point. Here's a possible fix: * change "attributive namespace is within vocabulary namespace" to "attributive namespace is within namespace" * move "vocabulary namespace" and "language" and related fact types to clause 11 -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038