Issue 13138: Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) (sbvr-rtf) Source: Business Semantics Ltd. (Mr. Donald R. Chapin, Donald.Chapin(at)BusinessSemantics.com) Nature: Uncategorized Issue Severity: Summary: 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 11296-1a / 11303-b 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:01:34 -0500 To: issues@omg.org, sbvr-rtf@omg.org From: Juergen Boldt Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald Issue nnnnn - Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540)3.doc SBVR Container Diagram for Proposed Issue nnnnn (Move Fact Model Container Concepts from Clause 8 to Clause 10) Resolution 2008-12-043.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 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 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:Thread-Index:In-Reply-To; b=OZ2m/kaIL3n981i/j7nRODYstnIQCsavT95icf3jOdYh33KPJ6tH6JebpennFr93mTSVakcoChODCLx5CI7JezAZ+CArG63YtuqzZK90K+0d0hnG999O8ZviqsSv5yqQB0LShj440PczQGYuaFAZmTTUHgC9Cwk8zb+4OOWKIIg= ; X-YMail-OSG: tRoG1FYVM1mQlFSxUyeHzbd7WS1oFM5CrKJZRt5z9cgGKDZmywJUKQzGzNdh9MWN8djSIhkW4GAF1ayULkZGimADcMF64tt3SUc1fv1R63HAzmbG_LkGgx2_EB9sOVuSHL01peGiPR.h0H2dcvTpwpmNW3cPPYWzGcDE7pY4_H7XiYmYj8YRjmv1wW.amS0iQPYBOcdQY1vKN7Wr_odSbdDXSQ-- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: Subject: RE: issue 13138 -- SBVR RTF issue Date: Wed, 25 Mar 2009 07:37:40 -0400 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWQsuSPj1zJrR1QQO8SbCCRepNPgAsE2cwFZJw7yA= All . At the December SBVR RTF face to face meeting two or three people were quite reluctant to move Clause 8.5 to Clause 10, so it seems best to focus on fixing the problems in Clause 8.5 before any further discussion on moving the content. I spend more than a day trying different approaches to fixing the problems based on the feedback from the December meeting. By the end of that time I had an insight as to the core problem which is that .conceptual schema. and .population. are both roles of a body of shared meanings and its representations. Please see that attached diagram provided by Terry Halpin and in the December 2003 minutes of the Business Rules Team that created the SBVR specification. I have annotated with green and orange arrows to show how the sBVR specification itself in its Clause 15 XMI, XSD and XML documents illustrates this point. By defining .conceptual schema. and .population. this way the changes to Clause 8.5 are minimal. I didn.t want to spend a lot of time on edit instructions until we agreed this principle. Donald -------------------------------------------------------------------------------- From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: 05 December 2008 11:10 To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue All -- Attached is a proposed resolution for Issue 13138 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: 12540, 13138 & 13139. Donald -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Thursday, December 04, 2008 7:02 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- SBVR RTF issue Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald X-SpamScore: -26 X-BigFish: PS-26(z21cILz9371Kc85fh98dKzz1202hzz84d07h8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139;KIP:(null);UIP:(null);IPV:SKI;H:SN2PRD0302HT004.namprd03.prod.outlook.com;R:internal;EFV:INT From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: issue 13138 -- SBVR RTF issue: Closed-World Examples -- for discussion in October 7 SBVR-RTF call Thread-Topic: issue 13138 -- SBVR RTF issue: Closed-World Examples -- for discussion in October 7 SBVR-RTF call Thread-Index: AcyEusyRdAMxJJJFTymnPkntDqqX6g== Date: Fri, 7 Oct 2011 06:31:58 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.104.188.194] X-OrganizationHeadersPreserved: SN2PRD0302HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%OMG.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com Here are examples based on Mark.s examples from last week, and more examples at the end. I am sending this in response to a request made in last week.s SBVR call. Mark.s Example 1 Rule: An order must be shipped within 24 hours if the order does not include a line item that has quantity greater than 100. How would a business person know whether an order satisfies the rule? Is it because the fact type .order includes line item. is internally closed in some conceptual schema? No, for two reasons: 1. That would not be enough. Knowing that you have all the line items for an item doesn.t mean you know all the quantities for those line items. 2. A business person knows whether a rule is violated from facts about the things involved (orders and line items), not from facts about conceptual schemas. What facts about an order make the size of the order definite rather than open? Here is one example: Order 12345 has two lines items. Line item 1 of order 12345 has the quantity 10. Line item 2 of order 12345 has the quantity 20. Here is another example that does not explicitly state the number of line items: The line items of order 12345 are a line item for the product MS Windows with quantity 30 and a line item for the product MS Office with quantity 20. SBVR provides a means to formulate facts for both approaches above. Facts can be definite about what is in a set. I put the definite article above in bold because its definiteness is significant. Mark.s Example 2 A business keeps track of its employees. If IBM chooses, it can have an employee registry and it can relate that registry to being an IBM employee using a structural rule: A person is an employee of IBM if and only if that person is identified in the IBM Employee Registry. Alternatively, it might decide that other factors determine whether someone is an employee, so it uses operative rules to obligate keeping its registry up to date: Each employee of IBM must be identified in the IBM Employee Registry. Each person that is not an employee of IBM must not be identified in the IBM Employee Registry. Ron Ross in the past has given examples of rules about knowledge using the phrase .must be considered.. A person must be considered to be an IBM employee if and only if that person is identified in the IBM Employee Registry. The registry is an artifact of the business. Its contents are definite and observable. Mark.s Example 3 Mark wrote: .In SBVR, how do you express the idea that the employee name is reliably know, but the work phone number is not reliable?. The .closed. and .internally closed. fact types have nothing to do with reliability. Facts in a fact model are taken to be true. Here are two facts that are taken as true. Note that an alleged phone number is understood to be unreliable. The name of employee 1234 is .Mark.. The alleged phone number of employee 1234 is 234-555-6789. Also, a fact model can have facts about the reliability of propositions: The proposition that employee 1234 has the phone number 234-555-6789 is unreliable. When capturing the meaning of business people.s communication, it is important to capture it using the business people.s concepts . the meanings of the words business people use. The .closed. and .internally closed. fact types for conceptual schemas do not do that. Example 4 Business people sometimes have rules about knowledge. When a customer makes a purchase through a sales clerk, if the clerk knows that the customer is eligible for a discount, the clerk must offer the discount to the customer. Example 5 Business people sometimes have rules about what sources of information are authoritative and/or complete. These sources are artifacts that can be examined. The shipping manifest for each shipment must identify each item in the shipment. The shipping manifest for each shipment is the authoritative statement of what items are in that shipment. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Friday, September 30, 2011 6:55 AM To: sbvr-rtf@omg.org Subject: issue 13138 -- SBVR RTF issue: Closed-World Examples Donald asked me to come up with 2-3 examples of how I think the clause 8.5 "is closed in" and "is internally closed in" verb concepts are needed. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue: Closed-World Examples -- for discussion in October 7 SBVR-RTF call X-KeepSent: 266FEF9C:86D2ECC1-85257922:0051059E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Fri, 7 Oct 2011 10:57:41 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/07/2011 10:57:42, Serialize complete at 10/07/2011 10:57:42 >>MHL I don't have much time to respond to this before the RTF phone call. I'll insert comments like this but will probably run out of time. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "sbvr-rtf@omg.org" Date: 10/07/2011 02:36 AM Subject: RE: issue 13138 -- SBVR RTF issue: Closed-World Examples -- for discussion in October 7 SBVR-RTF call -------------------------------------------------------------------------------- Here are examples based on Markâs examples from last week, and more examples at the end. I am sending this in response to a request made in last weekâs SBVR call. Markâs Example 1 Rule: An order must be shipped within 24 hours if the order does not include a line item that has quantity greater than 100. How would a business person know whether an order satisfies the rule? Is it because the fact type âorder includes line itemâ is internally closed in some conceptual schema? No, for two reasons: 1. That would not be enough. Knowing that you have all the line items for an item doesnât mean you know all the quantities for those line items. >>MHL This is a tangent. The statement about internal closure could certainly be extended to "quantities". But that doesn't change the argument. 2. A business person knows whether a rule is violated from facts about the things involved (orders and line items), not from facts about conceptual schemas. >>MHL This interpretation clearly does not match the plain meaning of clause 8.5, for example in the Notes under "concept is closed in conceptual schema" and >>MHL "fact type is internally closed in conceptual schema". >>MHL The Note under "fact type is internally closed in conceptual schema" says "... if the things participating in a fact are known within a model, then the fact is also known within that model. ". Here "model" means "fact model", which is "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) ". So I read the Note as meaning that a business person can know that if an Order is known, then the line items of the Order are also known. So the business person can determine the values of the quantities of all the line items. What facts about an order make the size of the order definite rather than open? Here is one example: Order 12345 has two lines items. Line item 1 of order 12345 has the quantity 10. Line item 2 of order 12345 has the quantity 20. Here is another example that does not explicitly state the number of line items: The line items of order 12345 are a line item for the product MS Windows with quantity 30 and a line item for the product MS Office with quantity 20. SBVR provides a means to formulate facts for both approaches above. Facts can be definite about what is in a set. I put the definite article above in bold because its definiteness is significant. The above discussion about facts is not relevant. In a real application, most of the facts are not stated as SBVR facts but exist in a database. So Don's discussion about the "definite article" is not meaningful for the example that I gave. Markâs Example 2 I did NOT propose the idea of a registry in my email, so this is Don's example, not mine. (And I resent that Don reworks my example in his words but still labels it as "Mark's Example 2".) A business keeps track of its employees. If IBM chooses, it can have an employee registry and it can relate that registry to being an IBM employee using a structural rule: A person is an employee of IBM if and only if that person is identified in the IBM Employee Registry. Alternatively, it might decide that other factors determine whether someone is an employee, so it uses operative rules to obligate keeping its registry up to date: Each employee of IBM must be identified in the IBM Employee Registry. Each person that is not an employee of IBM must not be identified in the IBM Employee Registry. Ron Ross in the past has given examples of rules about knowledge using the phrase âmust be consideredâ. A person must be considered to be an IBM employee if and only if that person is identified in the IBM Employee Registry. The registry is an artifact of the business. Its contents are definite and observable. Certainly all the above is possible. But the example I gave is simpler because it did not involve a registry at all. Markâs Example 3 Mark wrote: âIn SBVR, how do you express the idea that the employee name is reliably know, but the work phone number is not reliable?â The âclosedâ and âinternally closedâ fact types have nothing to do with reliability. Facts in a fact model are taken to be true. Here are two facts that are taken as true. Note that an alleged phone number is understood to be unreliable. The name of employee 1234 is âMarkâ. The alleged phone number of employee 1234 is 234-555-6789. Also, a fact model can have facts about the reliability of propositions: The proposition that employee 1234 has the phone number 234-555-6789 is unreliable. When capturing the meaning of business peopleâs communication, it is important to capture it using the business peopleâs concepts . the meanings of the words buusiness people use. The âclosedâ and âinternally closedâ fact types for conceptual schemas do not do that. Are you proposing that SBVR add verb concepts such as "proposition is reliable"? Example 4 Business people sometimes have rules about knowledge. When a customer makes a purchase through a sales clerk, if the clerk knows that the customer is eligible for a discount, the clerk must offer the discount to the customer. Example 5 Business people sometimes have rules about what sources of information are authoritative and/or complete. These sources are artifacts that can be examined. The shipping manifest for each shipment must identify each item in the shipment. The shipping manifest for each shipment is the authoritative statement of what items are in that shipment. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Friday, September 30, 2011 6:55 AM To: sbvr-rtf@omg.org Subject: issue 13138 -- SBVR RTF issue: Closed-World Examples Donald asked me to come up with 2-3 examples of how I think the clause 8.5 "is closed in" and "is internally closed in" verb concepts are needed. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research Date: Fri, 07 Oct 2011 13:42:05 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: SBVR RTF Subject: SBVR: Fallout from Issue 13138: the "record" concept X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p97HgA6P032320 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1318614134.89737@r65l+cL7ff7L8JpsqPVX6g X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov For those who just came in, the 7 Oct 2011 conference call included a discussion of Mark's idea that the explicit list of members of a set, such as the "set of products we sell" may be completely known and be an authoritative reference that is cited in business rules. I proposed the idea of a 'record', and this is an attempt to define it. _record_ Definition: a _communication content_ that explicitly identifies each member of a set and may provide additional facts about the individual members. Note: See 11.2.2.3 Note: A record is a set of representations that captures the body of knowledge as to exactly which things are members of the set. A record necessarily contains all the information units needed to satisfy some reference scheme for a concept that corresponds to all the members of the set. The concept may be much more general than the set itself. A record typically contains some other useful facts about each member. Example: the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list _record_ /documents/ _set_ Definition: the _record_ explicitly identifies the members of the _set _Note: The set may be the extension of a particular concept. Example: a product catalog (record) documents the set of all products that the company sells. Example: a general ledger (record) documents the extension of 'company financial transaction' _ record_ /is complete /Definition: every member of the set that the record documents is explicitly identified in the record. Any thing that is not explicitly identified in the record is not a member of the set. _record_ /is authoritative/ Definition: the record is complete and the record is used as a/the reference in determining membership in the set that it documents. Ed Note: We might /define/ the 'record' to be 'complete' instead of making it an optional characteristic; that is, documenting some members of a set is not very interesting. But the problem is whether the completeness of the record is a structural rule or an operational rule. If it is an operational rule, the record might not actually /be/ complete, because maintenance of the record is a business activity that may be delayed or improperly conducted. The general ledger, for example, must be maintained. Other records, however, may be complete at the moment they are constructed or officially released. The product catalog for 2012 may be issued in December and remain as the authoritative specification for a year. Ed Note: 'record is authoritative' may be beyond the scope of SBVR. Making a record authoritative is usually a business policy and rules matter. Admittedly all we are providing is the (tentative) fact type, but it may be insufficient. A given record may be authoritative for some business activities, but not for others. The other problem is that it is only authoritative for the set membership, not necessarily for the other facts contained. The personnel record, for example, may be authoritative for the set of employees, but not necessarily up to date with respect to their immediate supervisors, or their office locations. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Yahoo-Newman-Id: 54078.82618.bm@omp1007.access.mail.sp2.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1318033998; bh=+ub37zpxk5XI3IFDCX8Jo1fMEyqSSnwfj132UL7I4uA=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:In-Reply-To:References:Mime-Version:Content-Type; b=bZLjXOORGxFBQGV/u3jvX7VTm0DwCELNr6bHZ/Aio0NrY9tWiqNdJh0DaEgk9ZFRvkaKLl5FS37kQ2Figms6c1bmfpR2WWsAv6AaqQjoinVfYKRvyTdNO6KEKb2MeunUsc0tXX/z4qRd7Ipm+cvn6oT6ppfgIxWDdW4NINGbXxE= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: OxpiY9YVM1mIU_1mSm38gpSjdsUmCg1lt3w6GVAlCXfghYN KELnJ7j9sLQ46xIN.qcrTvXSk1CBQqVnB0_huHaIJetdDyfY86pcJjCOGpIi wXlkt1XL3CICWqbUVM0hslwOjLqA93n0z_34uezyvOq8HNBlOia7m71V1jVa 0oXkikNzyUKQ6ddLVei1mIbozqTnfJuf.Fp0veUiHPl7nxP9QKwMtFIgHVg6 L2wesVhguL1.4zUWZKNM4G51cjUGiEmhNCkneGhmJ.1nkgvzVrLCMSeP2iFj TWdjJ8O6OQkhrXu_kv.7CH6V8neefSzdjCwZxyndd8uhbrZzzUnBHvUbdOYP bPsbH4JkgTtUwTyL8mT2UXY.FIQw4adASd7LXc1UH2OaPMFkJrouqtSCjakb LreGh_ZLCeygiapOl1b.3.P2fAwz8_n4X1LZsZlpyPzAhDdfXRiEa5wyWxqu 5XvaRGNX9Jt9GAqnO7dbZuEJxYZreJDFVWO_m1jXwDxkO5yYSugQCzNGj0iO 1tLNjECrF4U1fa944fKBKlIDfT8BHX545G4LzNAf3YWEiFi4P5Ik.POeKd_3 gxMdJ28ZxZs9qEA.3MoGmS8ft3RadSMV0KBFhMdYZ3X56YWLad7wdZ0Qv.vF IKDbGXs.gDKMxd2HfLv2IkYGg9dockr02XOOAoMC0qYLQNlzqd6g8k6xSqVO taiFP_vUMNN5iPekr X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 Oct 2011 19:33:02 -0500 To: edbark@nist.gov, SBVR RTF From: "Ronald G. Ross" Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept Ed, I basically like what you have suggested. And it excites me. This is the kind of thing SBVR ought to be clarifying for business people. I do have some comments, but first this. I don't see how this issue can be resolved in the next 3 weeks. But more importantly, let's think about whether it needs to be. ***After today's discussion can we safely say it can be dealt with *without* impacting states-of-affairs questions??*** A couple of general points. 1. Would you agree that a good dictionary basis for "record" as you mean it would be: MWUD 2b(3): a body of known, recorded, or available facts about something : the sum of something done or achieved or the body of data known, recorded, or available about something ... We would need a good dictionary basis. We don't want people to assume the IT sense of "record". 2 . On the meaning side (and from a business point of view) I believe a "record" might correspond to an "aggregation" as per MWUD 2: a group, body, or mass composed of many distinct parts : ASSEMBLAGE (This is Issue 16523.) Your examples ("the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list") seem to suggest that. 3. To your definition of "record is complete" I would add these words: "Any thing that is not explicitly identified in the record **can be assumed** not a member of the set." I see "record is complete" is really a CYA kind of thing. Read on ... At 12:42 PM 10/7/2011, Ed Barkmeyer wrote: For those who just came in, the 7 Oct 2011 conference call included a discussion of Mark's idea that the explicit list of members of a set, such as the "set of products we sell" may be completely known and be an authoritative reference that is cited in business rules. I proposed the idea of a 'record', and this is an attempt to define it. _record_ Definition: a _communication content_ that explicitly identifies each member of a set and may provide additional facts about the individual members. Note: See 11.2.2.3 Note: A record is a set of representations that captures the body of knowledge as to exactly which things are members of the set. I like this phrase. It clearly distinguishes "record" by its business intent and thereby distinguishes it from other kinds of business content where business vocabulary does need to be used but where 'complete list' is *not* the primary purpose (e.g., contracts, agreements, MOUs, deals, certifications, warranties, instructions, etc.. etc.). A record necessarily contains all the information units needed to satisfy some reference scheme for a concept that corresponds to all the members of the set. The concept may be much more general than the set itself. A record typically contains some other useful facts about each member. Ditto aggregations on the meaning side. Example: the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list _record_ /documents/ _set_ Definition: the _record_ explicitly identifies the members of the _set _Note: The set may be the extension of a particular concept. Example: a product catalog (record) documents the set of all products that the company sells. Example: a general ledger (record) documents the extension of 'company financial transaction' _ record_ /is complete /Definition: every member of the set that the record documents is explicitly identified in the record. Any thing that is not explicitly identified in the record is not a member of the set. _record_ /is authoritative/ Definition: the record is complete and the record is used as a/the reference in determining membership in the set that it documents. Ed Note: We might /define/ the 'record' to be 'complete' instead of making it an optional characteristic; that is, documenting some members of a set is not very interesting. But the problem is whether the completeness of the record is a structural rule or an operational rule. Again, I think that bringing rules into this is off-target. The real sense of "record is complete" is that the company is saying "we believe or assume this record to be complete, so if you act in a way that assumes as much, you will not be sanctioned for such action even if it turns out the record is not complete." It's actually a form of permission: It is permitted that you consider this record complete. We usually don't make elements of guidance about such things. But since SBVR assumes an open-world, in cases where the company thinks it can *close* some record, it needs to indicate special allowance for people to act that way. It's sort a disclaimer (or more accurately, maybe an indulgence.) If it is an operational rule, the record might not actually /be/ complete, because maintenance of the record is a business activity that may be delayed or improperly conducted. The general ledger, for example, must be maintained. You need *real* rules for that ... e.g., Every business transaction must be be included in the general ledger. (I'm not thinking of transaction as a 'data' thing, but as a real-world thing.) This can't be a definitional thing (or structural rule) -- it has to have deontic force. You *will* be potentially penalized if you violate this rule (leave some transaction out). But this rule is aimed at different people with different responsibilities than the expression of completeness. Other records, however, may be complete at the moment they are constructed or officially released. The product catalog for 2012 may be issued in December and remain as the authoritative specification for a year. "We will make or apply no behavioral rules against you for that period of time if you act as if the record is complete." It's a stricture against making or applying rules. BTW, this would seem like a date-time thing. You just said how long the 'grace period' applies. So should the fact type be: "record is considered complete until d-t"? Ed Note: 'record is authoritative' may be beyond the scope of SBVR. Making a record authoritative is usually a business policy and rules matter. Admittedly all we are providing is the (tentative) fact type, but it may be insufficient. A given record may be authoritative for some business activities, but not for others. The other problem is that it is only authoritative for the set membership, not necessarily for the other facts contained. The personnel record, for example, may be authoritative for the set of employees, but not necessarily up to date with respect to their immediate supervisors, or their office locations. I think you're mixing a couple of ideas here. I would not consider a list or body-of or record or aggregate to be unchanging unless you told me it was. I used to call one that is static a "snapshot". Could also be a "point-in-time image". These are very important for legal purposes. ("Never reconstruct after the fact.") I've been talking about them since the mid-80's at least. Also, 'record is authoritative'. I don't think we need this. Any application of SBVR has a scope, and anything within that scope should be considered authoritative. Why would any list or body-of or record or aggregate within scope *not* be so?? All in all, I say there are at least 2 ideas here: 1. Record is assumed complete [until date-time] (with respect to the basic kind of things it lists ... there will be no sanction for acting as if it's complete).This fact type.specifically closes the open-world assumption. 2. Record is immutable (cannot be changed). This permits creation of point-in-time snapshots. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info X-SpamScore: -20 X-BigFish: PS-20(z21cILzc85fhzz1202hzz8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:207.46.4.139;KIP:(null);UIP:(null);IPV:SKI;H:SN2PRD0302HT002.namprd03.prod.outlook.com;R:internal;EFV:INT X-FB-SS: 13, From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: RE: issue 13138 discussion Thread-Topic: RE: issue 13138 discussion Thread-Index: AcyGu/i24e6Ema8LTiiu2XeF2d7JJw== Date: Sun, 9 Oct 2011 19:45:44 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.104.188.194] X-OrganizationHeadersPreserved: SN2PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%OMG.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com Here is an example that was requested during Friday.s discussion of issue 13138. If we take .http://www.stateabbreviations.us. as the name of a what SBVR calls a .communication content. or .document content., then it is the name of a composite representation made up other representations, such as statements of propositions. We can make the following statement. http://www.stateabbreviations.us is composed of a statement of what postal abbreviation each state of the United States of America has. or similarly http://www.stateabbreviations.us is composed of a statement of what the postal abbreviations of the states of the United States of America are. These statements are formulated using a combination of concepts from SBVR and from a domain vocabulary. The domain concepts include the fact types that relate a state to the United States of America and to its postal abbreviation. Fact types used from SBVR are these: communication content is composed of representation (I would have preferred using the verb .includes. here) proposition has statement The two statements above would be formulated differently, but both statements indicate completeness. The first statement uses the universal quantifier .each., indicating each state. The second statement uses the definite article (.the states.), indicating the entire set of states. One question that came up was about vocabularies and completeness. The example above can be changed just a little to refer to names, which are elements of vocabularies: http://www.stateabbreviations.us is composed of a statement of what name and postal abbreviation each state of the United States of America has. The EU-Rent Vocabulary includes the name each state of the United States of America. I noticed that SBVR.s concept .rulebook. does not specialize .document content.. If it did, a rulebook could fill the role of being an information source. Perhaps there is a need to align clauses 11.2.2.3 and 11.2.2.4. Such a task, as well as adding anything about completeness to clause 11, should be separate from resolving the issue about the placement of the .conceptual schema. stuff. Best regards, Don From: "Donald Chapin" To: "'Ronald G. Ross'" Cc: "'SBVR RTF'" Subject: RE: SBVR: Fallout from Issue 13138: the "record" concept Date: Mon, 10 Oct 2011 15:00:29 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLlCOCcPyXRikkdzfEpVcTvzHAt6AJDGuZqkzJ7ZMA= X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E92FA7F.0044, actions=tag X-Junkmail-Premium-Raw: score=11/50, refid=2.7.2:2011.10.10.123314:17:11.920, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, LINK_TO_IMAGE, INFO_TLD, __FRAUD_CONTACT_NUM, __CP_MEDIA_BODY, __CP_URI_IN_BODY, __FRAUD_PROPOSE, __C230066_P5, __FRAUD_FUNWORDS, __HTML_MSWORD, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_90_100, HTML_95_100, HTML_98_100, HTML_99_100, HTML_999_100, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=11/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4E92FA80.01CE,ss=1,pt=113351,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 Ron, I agree with your concerns both about timing, and whether there is really an Issue with respect to the .communication content.-related concepts in Clause 11.2.2. I believe that Mark.s preferred solution to a business-oriented ability to specify the availability of knowledge about instances of SBVR concepts, which is focused on the set of instances that comprise the extensions of concepts, is the simplest and most workable. It is inherently part of Issue 13138 because of moving the .closed in fact model. concepts into Clause 10 Given that, dealing with any ambiguities, contradictions, internal disconnects or other problems with .communication content.-related concepts in Clause 11.2.2 really requires a new Issue that addresses those problems, if any exist, directly and explicitly. Such an Issue would best be dealt with in SBVR v1.2 after we get SBVR v1.1 accepted by the OMG Architecture Board. Donald From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: 08 October 2011 01:33 To: edbark@nist.gov; SBVR RTF Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept Ed, I basically like what you have suggested. And it excites me. This is the kind of thing SBVR ought to be clarifying for business people. I do have some comments, but first this. I don't see how this issue can be resolved in the next 3 weeks. But more importantly, let's think about whether it needs to be. ***After today's discussion can we safely say it can be dealt with *without* impacting states-of-affairs questions??*** A couple of general points. 1. Would you agree that a good dictionary basis for "record" as you mean it would be: MWUD 2b(3): a body of known, recorded, or available facts about something : the sum of something done or achieved or the body of data known, recorded, or available about something ... We would need a good dictionary basis. We don't want people to assume the IT sense of "record". 2 . On the meaning side (and from a business point of view) I believe a "record" might correspond to an "aggregation" as per MWUD 2: a group, body, or mass composed of many distinct parts : ASSEMBLAGE (This is Issue 16523.) Your examples ("the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list") seem to suggest that. 3. To your definition of "record is complete" I would add these words: "Any thing that is not explicitly identified in the record **can be assumed** not a member of the set." I see "record is complete" is really a CYA kind of thing. Read on ... At 12:42 PM 10/7/2011, Ed Barkmeyer wrote: For those who just came in, the 7 Oct 2011 conference call included a discussion of Mark's idea that the explicit list of members of a set, such as the "set of products we sell" may be completely known and be an authoritative reference that is cited in business rules. I proposed the idea of a 'record', and this is an attempt to define it. _record_ Definition: a _communication content_ that explicitly identifies each member of a set and may provide additional facts about the individual members. Note: See 11.2.2.3 Note: A record is a set of representations that captures the body of knowledge as to exactly which things are members of the set. I like this phrase. It clearly distinguishes "record" by its business intent and thereby distinguishes it from other kinds of business content where business vocabulary does need to be used but where 'complete list' is *not* the primary purpose (e.g., contracts, agreements, MOUs, deals, certifications, warranties, instructions, etc.. etc.). A record necessarily contains all the information units needed to satisfy some reference scheme for a concept that corresponds to all the members of the set. The concept may be much more general than the set itself. A record typically contains some other useful facts about each member. Ditto aggregations on the meaning side. Example: the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list _record_ /documents/ _set_ Definition: the _record_ explicitly identifies the members of the _set _Note: The set may be the extension of a particular concept. Example: a product catalog (record) documents the set of all products that the company sells. Example: a general ledger (record) documents the extension of 'company financial transaction' _ record_ /is complete /Definition: every member of the set that the record documents is explicitly identified in the record. Any thing that is not explicitly identified in the record is not a member of the set. _record_ /is authoritative/ Definition: the record is complete and the record is used as a/the reference in determining membership in the set that it documents. Ed Note: We might /define/ the 'record' to be 'complete' instead of making it an optional characteristic; that is, documenting some members of a set is not very interesting. But the problem is whether the completeness of the record is a structural rule or an operational rule. Again, I think that bringing rules into this is off-target. The real sense of "record is complete" is that the company is saying "we believe or assume this record to be complete, so if you act in a way that assumes as much, you will not be sanctioned for such action even if it turns out the record is not complete." It's actually a form of permission: It is permitted that you consider this record complete. We usually don't make elements of guidance about such things. But since SBVR assumes an open-world, in cases where the company thinks it can *close* some record, it needs to indicate special allowance for people to act that way. It's sort a disclaimer (or more accurately, maybe an indulgence.) If it is an operational rule, the record might not actually /be/ complete, because maintenance of the record is a business activity that may be delayed or improperly conducted. The general ledger, for example, must be maintained. You need *real* rules for that ... e.g., Every business transaction must be be included in the general ledger. (I'm not thinking of transaction as a 'data' thing, but as a real-world thing.) This can't be a definitional thing (or structural rule) -- it has to have deontic force. You *will* be potentially penalized if you violate this rule (leave some transaction out). But this rule is aimed at different people with different responsibilities than the expression of completeness. Other records, however, may be complete at the moment they are constructed or officially released. The product catalog for 2012 may be issued in December and remain as the authoritative specification for a year. "We will make or apply no behavioral rules against you for that period of time if you act as if the record is complete." It's a stricture against making or applying rules. BTW, this would seem like a date-time thing. You just said how long the 'grace period' applies. So should the fact type be: "record is considered complete until d-t"? Ed Note: 'record is authoritative' may be beyond the scope of SBVR. Making a record authoritative is usually a business policy and rules matter. Admittedly all we are providing is the (tentative) fact type, but it may be insufficient. A given record may be authoritative for some business activities, but not for others. The other problem is that it is only authoritative for the set membership, not necessarily for the other facts contained. The personnel record, for example, may be authoritative for the set of employees, but not necessarily up to date with respect to their immediate supervisors, or their office locations. I think you're mixing a couple of ideas here. I would not consider a list or body-of or record or aggregate to be unchanging unless you told me it was. I used to call one that is static a "snapshot". Could also be a "point-in-time image". These are very important for legal purposes. ("Never reconstruct after the fact.") I've been talking about them since the mid-80's at least. Also, 'record is authoritative'. I don't think we need this. Any application of SBVR has a scope, and anything within that scope should be considered authoritative. Why would any list or body-of or record or aggregate within scope *not* be so?? All in all, I say there are at least 2 ideas here: 1. Record is assumed complete [until date-time] (with respect to the basic kind of things it lists ... there will be no sanction for acting as if it's complete).This fact type.specifically closes the open-world assumption. 2. Record is immutable (cannot be changed). This permits creation of point-in-time snapshots. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info To: sbvr-rtf@omg.org Subject: RE: SBVR: Fallout from Issue 13138: the "record" concept X-KeepSent: 5C492938:3CA85B4B-85257925:0055D2EB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 10 Oct 2011 14:05:03 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/10/2011 14:05:04, Serialize complete at 10/10/2011 14:05:04 I have several comments about this: 1) I think issue 13138 has nothing to do with the "state of affairs" issues and should be handled entirely as a separate thread. Whether it can be resolved within the next 3 weeks, I don't know. I offer the solution below as a step towards that. 2) I agree with Ron that there is both a "meaning" and a "representation" side of this "closed world" issue. I think we need to resolve the "meaning" side of it as part of 13138, otherwise we'll lose the "closed world" capability. I think the representation aspect (i.e. "records") can be addressed separately. 3) For the meaning aspect, I suggest a new characteristic of "set": "set is completely known" defined as: "each element of the set is known to the semantic community that shares an understanding of the set". I would add a Note that "Under SBVR's normal 'open world' semantics, there could be elements of the set that exist but are unknown. "set is completely known" reverses the 'open world' assumption with respect to the set. If a set is completely known, then an existential quantification such as "if there does not exist an element of the set that " can be relied upon to conclusively determine that there is no element that meets the given condition". This could go somewhere in clause 11. Semantic communities would use this in facts. For example: * Redoing the existing example in 8.5 in the Note under "concept is closed in conceptual schema": both EU-Rent and a corporate customer of EU-Rent might adopt EU-Rent''s "rental" concept. Only the EU-Rent semantic community would state as a fact "the extension of rental is completely known" to indicate that EU-Rent knows all its rentals. The corporate customer would not state this fact so would operate on the usual "open world" assumption. * Consider an order that has multiple line items. The fact "the extension of 'order has line item' is completely known" means that the semantic community that states this fact knows all the actualities of "order has line item". Responding to Ron's comments: * "set" is an existing SBVR concept that is similar to "aggregation" * I did not address "set is immutable" because I think it is outside the scope of 13138. And I think the idea of "snapshot in time" requires more -- at least the identification of the time. So this deserves more thorough investigation, which I would leave to domain use cases. Responding to Ed's comments: * I don't think the distinction between "is complete" and "is authoritative" is worth the additional complexity of having two characteristics rather than one. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: "'Ronald G. Ross'" Cc: "'SBVR RTF'" Date: 10/10/2011 10:21 AM Subject: RE: SBVR: Fallout from Issue 13138: the "record" concept -------------------------------------------------------------------------------- Ron, I agree with your concerns both about timing, and whether there is really an Issue with respect to the âcommunication contentâ-related concepts in Clause 11.2.2. I believe that Markâs preferred solution to a business-oriented ability to specify the availability of knowledge about instances of SBVR concepts, which is focused on the set of instances that comprise the extensions of concepts, is the simplest and most workable. It is inherently part of Issue 13138 because of moving the âclosed in fact modelâ concepts into Clause 10 Given that, dealing with any ambiguities, contradictions, internal disconnects or other problems with âcommunication contentâ-related concepts in Clause 11.2.2 really requires a new Issue that addresses those problems, if any exist, directly and explicitly. Such an Issue would best be dealt with in SBVR v1.2 after we get SBVR v1.1 accepted by the OMG Architecture Board. Donald From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: 08 October 2011 01:33 To: edbark@nist.gov; SBVR RTF Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept Ed, I basically like what you have suggested. And it excites me. This is the kind of thing SBVR ought to be clarifying for business people. I do have some comments, but first this. I don't see how this issue can be resolved in the next 3 weeks. But more importantly, let's think about whether it needs to be. ***After today's discussion can we safely say it can be dealt with *without* impacting states-of-affairs questions??*** A couple of general points. 1. Would you agree that a good dictionary basis for "record" as you mean it would be: MWUD 2b(3): a body of known, recorded, or available facts about something : the sum of something done or achieved or the body of data known, recorded, or available about something ... We would need a good dictionary basis. We don't want people to assume the IT sense of "record". 2 . On the meaning side (and from a business point of view) I believe a "record" might correspond to an "aggregation" as per MWUD 2: a group, body, or mass composed of many distinct parts : ASSEMBLAGE (This is Issue 16523.) Your examples ("the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list") seem to suggest that. 3. To your definition of "record is complete" I would add these words: "Any thing that is not explicitly identified in the record **can be assumed** not a member of the set." I see "record is complete" is really a CYA kind of thing. Read on ... At 12:42 PM 10/7/2011, Ed Barkmeyer wrote: For those who just came in, the 7 Oct 2011 conference call included a discussion of Mark's idea that the explicit list of members of a set, such as the "set of products we sell" may be completely known and be an authoritative reference that is cited in business rules. I proposed the idea of a 'record', and this is an attempt to define it. _record_ Definition: a _communication content_ that explicitly identifies each member of a set and may provide additional facts about the individual members. Note: See 11.2.2.3 Note: A record is a set of representations that captures the body of knowledge as to exactly which things are members of the set. I like this phrase. It clearly distinguishes "record" by its business intent and thereby distinguishes it from other kinds of business content where business vocabulary does need to be used but where 'complete list' is *not* the primary purpose (e.g., contracts, agreements, MOUs, deals, certifications, warranties, instructions, etc.. etc.). A record necessarily contains all the information units needed to satisfy some reference scheme for a concept that corresponds to all the members of the set. The concept may be much more general than the set itself. A record typically contains some other useful facts about each member. Ditto aggregations on the meaning side. Example: the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list _record_ /documents/ _set_ Definition: the _record_ explicitly identifies the members of the _set _Note: The set may be the extension of a particular concept. Example: a product catalog (record) documents the set of all products that the company sells. Example: a general ledger (record) documents the extension of 'company financial transaction' _ record_ /is complete /Definition: every member of the set that the record documents is explicitly identified in the record. Any thing that is not explicitly identified in the record is not a member of the set. _record_ /is authoritative/ Definition: the record is complete and the record is used as a/the reference in determining membership in the set that it documents. Ed Note: We might /define/ the 'record' to be 'complete' instead of making it an optional characteristic; that is, documenting some members of a set is not very interesting. But the problem is whether the completeness of the record is a structural rule or an operational rule. Again, I think that bringing rules into this is off-target. The real sense of "record is complete" is that the company is saying "we believe or assume this record to be complete, so if you act in a way that assumes as much, you will not be sanctioned for such action even if it turns out the record is not complete." It's actually a form of permission: It is permitted that you consider this record complete. We usually don't make elements of guidance about such things. But since SBVR assumes an open-world, in cases where the company thinks it can *close* some record, it needs to indicate special allowance for people to act that way. It's sort a disclaimer (or more accurately, maybe an indulgence.) If it is an operational rule, the record might not actually /be/ complete, because maintenance of the record is a business activity that may be delayed or improperly conducted. The general ledger, for example, must be maintained. You need *real* rules for that ... e.g., Every business transaction must be be included in the general ledger. (I'm not thinking of transaction as a 'data' thing, but as a real-world thing.) This can't be a definitional thing (or structural rule) -- it has to have deontic force. You *will* be potentially penalized if you violate this rule (leave some transaction out). But this rule is aimed at different people with different responsibilities than the expression of completeness. Other records, however, may be complete at the moment they are constructed or officially released. The product catalog for 2012 may be issued in December and remain as the authoritative specification for a year. "We will make or apply no behavioral rules against you for that period of time if you act as if the record is complete." It's a stricture against making or applying rules. BTW, this would seem like a date-time thing. You just said how long the 'grace period' applies. So should the fact type be: "record is considered complete until d-t"? Ed Note: 'record is authoritative' may be beyond the scope of SBVR. Making a record authoritative is usually a business policy and rules matter. Admittedly all we are providing is the (tentative) fact type, but it may be insufficient. A given record may be authoritative for some business activities, but not for others. The other problem is that it is only authoritative for the set membership, not necessarily for the other facts contained. The personnel record, for example, may be authoritative for the set of employees, but not necessarily up to date with respect to their immediate supervisors, or their office locations. I think you're mixing a couple of ideas here. I would not consider a list or body-of or record or aggregate to be unchanging unless you told me it was. I used to call one that is static a "snapshot". Could also be a "point-in-time image". These are very important for legal purposes. ("Never reconstruct after the fact.") I've been talking about them since the mid-80's at least. Also, 'record is authoritative'. I don't think we need this. Any application of SBVR has a scope, and anything within that scope should be considered authoritative. Why would any list or body-of or record or aggregate within scope *not* be so?? All in all, I say there are at least 2 ideas here: 1. Record is assumed complete [until date-time] (with respect to the basic kind of things it lists ... there will be no sanction for acting as if it's complete).This fact type.specifically closes the open-world assumption. 2. Record is immutable (cannot be changed). This permits creation of point-in-time snapshots. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info From: "Donald Chapin" To: "sbvr-rtf " Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Date: Tue, 11 Oct 2011 14:31:54 +0100 X-Mailer: Microsoft Outlook 14.0 thread-index: AQDjDZT3ixhxN3T1Dk0ZiN4CsibJRpdKF34w X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0301.4E94454B.0022, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.11.125714:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __OEM_SOFTWARE_5, __FRAUD_CONTACT_NAME, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_70_90, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, OEM_SOFTWARE_X1, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4E9445E8.00DA,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 an updated draft resolution to Issue 13138 that incorporates all the input from SBVR RTF telecons and email discussions to date. The objective is to release the resolution of Issue 13138 to ballot, with revisions as necessary, in this Friday.s SBVR telecon. Please discuss any questions you may have via the SBVR RTF email list before Friday.s telecon. Many thanks, Donald From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2011 12:30 To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald Draft Resolution for Issue 13138- 2011-10-11-1400.doc To: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution X-KeepSent: CCEB92A9:C68B6C6F-85257926:00600C3F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Tue, 11 Oct 2011 13:34:25 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/11/2011 13:34:22, Serialize complete at 10/11/2011 13:34:22 Donald, Why did you not write the "is completely known" characteristic in terms of "set" rather than in terms of "concept"? In the definition you propose, why do you use "is known to exist" for noun concepts and "is known to have occurred" for verb concepts? Why "exist" in one case and "occurred" in the other? Why use the simple aspect in "is know to exist" and the perfect aspect in "is known to have occurred"? And should "exist" be associated with existential quantification or not? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: "sbvr-rtf " Date: 10/11/2011 09:41 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution -------------------------------------------------------------------------------- Attached is an updated draft resolution to Issue 13138 that incorporates all the input from SBVR RTF telecons and email discussions to date. The objective is to release the resolution of Issue 13138 to ballot, with revisions as necessary, in this Fridayâs SBVR telecon. Please discuss any questions you may have via the SBVR RTF email list before Fridayâs telecon. Many thanks, Donald From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2011 12:30 To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== All . Please see attached Word document ffor 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald [attachment "Draft Resolution for Issue 13138- 2011-10-11-1400.doc" deleted by Mark H Linehan/Watson/IBM] Date: Tue, 11 Oct 2011 14:12:34 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9BICd46028105 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1318961560.41871@cXfZqKVnn5E9PEIRP9T5sw X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark H Linehan wrote: I have several comments about this: 1) I think issue 13138 has nothing to do with the "state of affairs" issues and should be handled entirely as a separate thread. Whether it can be resolved within the next 3 weeks, I don't know. I concur on both counts. The issue of whether a body of information is complete has nothing whatever to do with states of affairs. The idea that a body of information is complete seems to be a concept that SBVR didn't really have. Mark and I are among those who believed that a 'conceptual schema' was something other/more than an IT packaging idea. The problem for SBVR is that it was doing double duty. And that is what makes resolving Issue 13138 really problematic -- we need to sort out the idea of 'closure of a body of information' from the idea of a body of SBVR exchange elements. 2) I agree with Ron that there is both a "meaning" and a "representation" side of this "closed world" issue. I think we need to resolve the "meaning" side of it as part of 13138, otherwise we'll lose the "closed world" capability. I think the representation aspect (i.e. "records") can be addressed separately. I agree in part. I argue, however, that a 'complete body of information' is the content of a repository, and what is being said is that some repository of expressions holds the entire body. The whole idea of a body of information is that it is a package that is somehow accessible as a package. And the same is true of a body of shared meanings and a body of shared guidance. We can separate the content from the container, but we are implying that there is a container, or an identifiable collection of containers, that contains the body. One of the serious shortcomings of SBVR is that it provides no practical approach to terminology exchange, because it doesn't have exchange concepts for meaningful containers. 3) For the meaning aspect, I suggest a new characteristic of "set": "_set _/is completely known/" defined as: "each _element _/of /the _set _is known to the _semantic community_ that /shares an understanding of/ the _set_". I would argue that this approach is a bit misguided. A set is a 'res', not a 'meaning', so I don't know how one can 'share understanding of it'. And every set is by definition 'complete' -- it is a collection of specific things, and no others. The intensional description of a set -- the rule for membership -- is a 'concept', not a 'set'. The set is the extension of that concept. A "set that is not completely known" is a concept whose extension is not (completely) known. The issue is, as clause 8 currently says, whether a 'concept is closed' -- whether the set that is its extension is extensionally defined in some 'resource'. As Don points out, we know how to define a concept extensionally -- one big OR of the 'individual concepts'. But that assumes that the 'resource' that defines the extension is an extensional definition per se. (We don't have a similar fact type for sets, because SBVR doesn't think things have designations, there is no corresponding grammatical construct in SBVR SE, and no part of SBVR provides a means of exchanging a structure that is a 'list' of specific things, even though that is a common business concept.) Further, it assumes that the extension of the concept is not only 'known', but also 'constant'; it doesn't change over time. In many other cases, the resource is something like a database table, in which each row represents an instance, and the whole set of rows -- the table itself -- which in SBVR is a 'fact model'. In such cases, the extension of the concept, at the time of any business decision, is "completely known" and captured in that resource. That is what I meant by a 'record'. Upon reflection, I think 'fact model' should mean 'body of information', and we want 'concept is closed in fact model'. A 'fact model' is not an XML data set that conforms to an SBVR schema. That is just one form of 'resource'/'repository' that is a container of a fact model. Every fact model is contained in some 'resource' or set of such 'resources'. A fact model that is to be identified as specifically defining the extent of some concept (by such a closure rule) must have a name or designation, and that designation may be different from the designation for the container itself (which may be an IT object or a file cabinet). I think my concept 'record' is the expression of a 'fact model' within some 'resource'. And I think 'communication content' is the expression of a 'fact model' (i.e., body of information), or perhaps a role of that expression with respect to some 'resource', such as a document, a database, or a message. _ _ * Redoing the existing example in 8.5 in the Note under "concept is closed in conceptual schema": both EU-Rent and a corporate customer of EU-Rent might adopt EU-Rent''s "rental" concept. Only the EU-Rent semantic community would state as a fact "the _extension _/of /_rental _/is completely known/" to indicate that EU-Rent knows all its rentals. The idea: 'extension of _concept_ is completely known', as distinct from '_set_ is completely known', is useful. But, that it is completely known to unidentified parties is not useful in business. The useful fact type must be binary: we need to know WHO knows, or WHERE it is captured. So there may be two such fact types: 'extension of _concept_ is known by _party_' and 'extension of _concept_ is specified in _record_'. SBVR itself never introduces 'party' (or SUMO 'legal entity', or anything the like); so that makes it difficult to express the WHO version. I proposed 'record' to address the WHERE. The corporate customer would not state this fact so would operate on the usual "open world" assumption. In point of fact, the corporate customer doesn't care about other EU Rent rentals; they are not likely to be things in its world of interest. So its concept 'rental' would have a different extension. It may still be true that it is treated as 'open'. * Consider an order that has multiple line items. The fact "the extension of 'order has line item' is completely known" means that the semantic community that states this fact knows all the actualities of "order has line item". This is actually a bit trickier. Knowing all the actualities of 'order has line item' requires some resource/party to know all of the orders, and all of the line items in each. One would expect, of course, that an 'orders database' would have all that. So the fact type 'customer order has line item' is closed in the 'customer orders data' (fact model) which is captured as a set of tables (the record) in the Sales Database (repository). But the signed contract that documents a specific 'order' explicitly documents all of the line items for that order -- it is a closed 'record' of the line items of that order only. Responding to Ron's comments: * "set" is an existing SBVR concept that is similar to "aggregation" * I did not address "set is immutable" because I think it is outside the scope of 13138. The more general concept is 'collection'; 'aggregation' has several meanings of which 'set' is not a specialization. And 'set is immutable' by definition. A 'set' is a specific enumeration of things, and no others. If you add one, or take one out, you get a different 'set' -- a distinguishably different instance of the concept 'set'. Responding to Ed's comments: * I don't think the distinction between "is complete" and "is authoritative" is worth the additional complexity of having two characteristics rather than one. I agree. I think 'is authoritative' is an inappropriate addition. Business rules determine what is authoritative for what purposes, and the 'characteristic' alone may not actually characterize anything. We do best by not going there. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: "'Ronald G. Ross'" Cc: "'SBVR RTF'" Date: 10/10/2011 10:21 AM Subject: RE: SBVR: Fallout from Issue 13138: the "record" concept ------------------------------------------------------------------------ Ron, I agree with your concerns both about timing, and whether there is really an Issue with respect to the âcommunication contentâ-related concepts in Clause 11.2.2. I believe that Markâs preferred solution to a business-oriented ability to specify the availability of knowledge about instances of SBVR concepts, which is focused on the */set/* of instances that comprise the extensions of concepts, is the simplest and most workable. It is inherently part of Issue 13138 because of moving the âclosed in fact modelâ concepts into Clause 10 Given that, dealing with any ambiguities, contradictions, internal disconnects or other problems with âcommunication contentâ-related concepts in Clause 11.2.2 really requires a new Issue that addresses those problems, if any exist, directly and explicitly. Such an Issue would best be dealt with in SBVR v1.2 after we get SBVR v1.1 accepted by the OMG Architecture Board. Donald *From:* Ronald G. Ross [mailto:rross@brsolutions.com] * Sent:* 08 October 2011 01:33* To:* edbark@nist.gov; SBVR RTF* Subject:* Re: SBVR: Fallout from Issue 13138: the "record" concept Ed, I basically like what you have suggested. And it excites me. This is the kind of thing SBVR ought to be clarifying for business people. I do have some comments, but first this. I don't see how this issue can be resolved in the next 3 weeks. But more importantly, let's think about whether it needs to be. ***After today's discussion can we safely say it can be dealt with *without* impacting states-of-affairs questions??*** A couple of general points. 1. Would you agree that a good dictionary basis for "record" as you mean it would be: MWUD 2b(3): a body of known, recorded, or available facts about something : the sum of something done or achieved or the body of data known, recorded, or available about something ... We would need a good dictionary basis. We don't want people to assume the IT sense of "record". 2 . On the meaning side (and from a business point of view) I believe a "record" might correspond to an "aggregation" as per MWUD 2: a group, body, or mass composed of many distinct parts : ASSEMBLAGE (This is Issue 16523.) Your examples ("the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list") seem to suggest that. 3. To your definition of "record is complete" I would add these words: "Any thing that is not explicitly identified in the record **can be assumed** not a member of the set." I see "record is complete" is really a CYA kind of thing. Read on ... At 12:42 PM 10/7/2011, Ed Barkmeyer wrote: For those who just came in, the 7 Oct 2011 conference call included a discussion of Mark's idea that the explicit list of members of a set, such as the "set of products we sell" may be completely known and be an authoritative reference that is cited in business rules. I proposed the idea of a 'record', and this is an attempt to define it. _record_ Definition: a _communication content_ that explicitly identifies each member of a set and may provide additional facts about the individual members. Note: See 11.2.2.3 Note: A record is a set of representations that captures the body of knowledge as to exactly which things are members of the set. I like this phrase. It clearly distinguishes "record" by its business intent and thereby distinguishes it from other kinds of business content where business vocabulary does need to be used but where 'complete list' is *not* the primary purpose (e.g., contracts, agreements, MOUs, deals, certifications, warranties, instructions, etc.. etc.). A record necessarily contains all the information units needed to satisfy some reference scheme for a concept that corresponds to all the members of the set. The concept may be much more general than the set itself. A record typically contains some other useful facts about each member. Ditto aggregations on the meaning side. Example: the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list _record_ /documents/ _set_ Definition: the _record_ explicitly identifies the members of the _set _Note: The set may be the extension of a particular concept. Example: a product catalog (record) documents the set of all products that the company sells. Example: a general ledger (record) documents the extension of 'company financial transaction' _ record_ /is complete /Definition: every member of the set that the record documents is explicitly identified in the record. Any thing that is not explicitly identified in the record is not a member of the set. _record_ /is authoritative/ Definition: the record is complete and the record is used as a/the reference in determining membership in the set that it documents. Ed Note: We might /define/ the 'record' to be 'complete' instead of making it an optional characteristic; that is, documenting some members of a set is not very interesting. But the problem is whether the completeness of the record is a structural rule or an operational rule. Again, I think that bringing rules into this is off-target. The real sense of "record is complete" is that the company is saying "we believe or assume this record to be complete, so if you act in a way that assumes as much, you will not be sanctioned for such action even if it turns out the record is not complete." It's actually a form of permission: It is permitted that you consider this record complete. We usually don't make elements of guidance about such things. But since SBVR assumes an open-world, in cases where the company thinks it can *close* some record, it needs to indicate special allowance for people to act that way. It's sort a disclaimer (or more accurately, maybe an indulgence.) If it is an operational rule, the record might not actually /be/ complete, because maintenance of the record is a business activity that may be delayed or improperly conducted. The general ledger, for example, must be maintained. You need *real* rules for that ... e.g., Every business transaction must be be included in the general ledger. (I'm not thinking of transaction as a 'data' thing, but as a real-world thing.) This can't be a definitional thing (or structural rule) -- it has to have deontic force. You *will* be potentially penalized if you violate this rule (leave some transaction out). But this rule is aimed at different people with different responsibilities than the expression of completeness. Other records, however, may be complete at the moment they are constructed or officially released. The product catalog for 2012 may be issued in December and remain as the authoritative specification for a year. "We will make or apply no behavioral rules against you for that period of time if you act as if the record is complete." It's a stricture against making or applying rules. BTW, this would seem like a date-time thing. You just said how long the 'grace period' applies. So should the fact type be: "record is considered complete until d-t"? Ed Note: 'record is authoritative' may be beyond the scope of SBVR. Making a record authoritative is usually a business policy and rules matter. Admittedly all we are providing is the (tentative) fact type, but it may be insufficient. A given record may be authoritative for some business activities, but not for others. The other problem is that it is only authoritative for the set membership, not necessarily for the other facts contained. The personnel record, for example, may be authoritative for the set of employees, but not necessarily up to date with respect to their immediate supervisors, or their office locations. I think you're mixing a couple of ideas here. I would not consider a list or body-of or record or aggregate to be unchanging unless you told me it was. I used to call one that is static a "snapshot". Could also be a "point-in-time image". These are very important for legal purposes. ("Never reconstruct after the fact.") I've been talking about them since the mid-80's at least. Also, 'record is authoritative'. I don't think we need this. Any application of SBVR has a scope, and anything within that scope should be considered authoritative. Why would any list or body-of or record or aggregate within scope *not* be so?? All in all, I say there are at least 2 ideas here: 1. Record is assumed complete [until date-time] (with respect to the basic kind of things it lists ... there will be no sanction for acting as if it's complete).This fact type.specifically closes the open-world assumption. 2. Record is immutable (cannot be changed). This permits creation of point-in-time snapshots. Ron -Ed -- Edward J. Barkmeyer Email: _edbark@nist.gov_ National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." *Blog* || _http://www.RonRoss.info/blog/_ *LinkedIn* || _http://www.linkedin.com/pub/ronald-ross/1/3b/346_ *Twitter* || _https://twitter.com/Ronald_G_Ross_ *Homepage* || _http://www.RonRoss.info_ -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-SpamScore: -36 X-BigFish: PS-36(z21cILzbb2dK9371Kc89bh11fbM10e3K1a09Jc857hzz1202hzz8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:207.46.4.139;KIP:(null);UIP:(null);IPV:SKI;H:SN2PRD0302HT001.namprd03.prod.outlook.com;R:internal;EFV:INT X-FB-SS: 13, From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Thread-Topic: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Thread-Index: Acx5GvraX+JglD2jTMKNopqhUD1MtwO/ykQAAAh4RIAAASZokA== Date: Tue, 11 Oct 2011 18:51:49 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] X-OrganizationHeadersPreserved: SN2PRD0302HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%OMG.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com I agree with Mark.s concerns. Also, I have other concerns about part 2 of the resolution: 1. What are the intended alethic implications of the new .is completely known. fact type? In general, SBVR fact types about concepts are for defining concept systems, so they have clear alethic implications: they are used to state facts that are true for all states of the universe of discourse. I don.t see that made clear in the new definition. 2. Knowing that every instance exists is not the same as knowing the identification, based on a reference scheme, for every instance. 3. I hope we will look at more flexible ways of describing completeness of information sources that will be useful when writing rules. When writing rules, a business person will .use. a concept to refer to a .set. of things. The rule will use the concept, not mention it. But using the new .is completely known. fact type in a rule will require mentioning a concept. Regarding part 1 in the draft resolution: Please add to the instructions that the .FL. markers should be removed from the ends of the lines. Those markers are not used in clause 10. Part 4 of the resolution should be put into the last paragraph of 13.1.2. The simplest thing is to add the following parenthetical expression to the end of the second sentence: (see Clause 10.1.2.1) Part 5 is important. The new text should be this: Other necessities stated in the context of the Meaning and Representation Vocabulary concern concepts and their representations. But the following necessities are about the correspondence of meanings to things in a universe of discourse. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Tuesday, October 11, 2011 10:34 AM To: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Donald, Why did you not write the "is completely known" characteristic in terms of "set" rather than in terms of "concept"? In the definition you propose, why do you use "is known to exist" for noun concepts and "is known to have occurred" for verb concepts? Why "exist" in one case and "occurred" in the other? Why use the simple aspect in "is know to exist" and the perfect aspect in "is known to have occurred"? And should "exist" be associated with existential quantification or not? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: "sbvr-rtf " Date: 10/11/2011 09:41 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution -------------------------------------------------------------------------------- Attached is an updated draft resolution to Issue 13138 that incorporates all the input from SBVR RTF telecons and email discussions to date. The objective is to release the resolution of Issue 13138 to ballot, with revisions as necessary, in this Friday.s SBVR telecon. Please discuss any questions you may have via the SBVR RTF email list before Friday.s telecon. Many thanks, Donald From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2011 12:30 To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== All . Please see attached Word document for Isssue 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald [attachment "Draft Resolution for Issue 13138- 2011-10-11-1400.doc" deleted by Mark H Linehan/Watson/IBM] Date: Tue, 11 Oct 2011 17:01:48 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Ronald G. Ross" CC: SBVR RTF Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov Ron wrote: Ed, I basically like what you have suggested. And it excites me. This is the kind of thing SBVR ought to be clarifying for business people. I do have some comments, but first this. I don't see how this issue can be resolved in the next 3 weeks. OK. That is fair. But more importantly, let's think about whether it needs to be. ***After today's discussion can we safely say it can be dealt with *without* impacting states-of-affairs questions??*** It has nothing whatever to do with the states of affairs issues. It deals with collections of facts, yes, but I don't think any 'states of affairs' issue will change the intent of 'fact'. I do see how you want to relate it time. See below. A couple of general points. 1. Would you agree that a good dictionary basis for "record" as you mean it would be: MWUD 2b(3): a body of known, recorded, or available facts about something : the sum of something done or achieved or the body of data known, recorded, or available about something ... We would need a good dictionary basis. We don't want people to assume the IT sense of "record". A good point. And yes, I fully agree that this is the dictionary basis. "A body of facts about something" is exactly the idea. 2 . On the meaning side (and from a business point of view) I believe a "record" might correspond to an "aggregation" as per MWUD 2: a group, body, or mass composed of many distinct parts : ASSEMBLAGE (This is Issue 16523.) Your examples ("the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list") seem to suggest that. I would never have called any of those an 'aggregation'. The connotation I have for 'aggregation' is 'things BROUGHT together', and in particular, diverse things brought together for a purpose, such as a machine assembly, or a gathering together of things or information that is diversely maintained, if not diverse in itself. One aggregates the orders of multiple divisions. Further I have the idea that the aggregation tends to lose the identities of its parts. The more general concept I would have used is 'collection' -- a grouping of things of the same kind, maintaining their individual identities. But this is all about the social connotations of words. 3. To your definition of "record is complete" I would add these words: "Any thing that is not explicitly identified in the record **can be assumed** not a member of the set." I see "record is complete" is really a CYA kind of thing. Read on ... The issue of whether a thing not explicitly identified "is not" versus "is assumed not to be" is analogous to the issue of whether a 'fact' "is true" or "is taken to be true". I don't object to the wording; it is about the business practice for the use of the record. The question is what assumptions you make about the relationship between the actual state of the business and the statement that a particular record is complete. If the statement is 'taken to be true', then the thing that is not in the record is 'taken not to be a member of the set'. At 12:42 PM 10/7/2011, Ed Barkmeyer wrote: For those who just came in, the 7 Oct 2011 conference call included a discussion of Mark's idea that the explicit list of members of a set, such as the "set of products we sell" may be completely known and be an authoritative reference that is cited in business rules. I proposed the idea of a 'record', and this is an attempt to define it. _record_ Definition: a _communication content_ that explicitly identifies each member of a set and may provide additional facts about the individual members. Note: See 11.2.2.3 Note: A record is a set of representations that captures the body of knowledge as to exactly which things are members of the set. I like this phrase. It clearly distinguishes "record" by its business intent and thereby distinguishes it from other kinds of business content where business vocabulary does need to be used but where 'complete list' is *not* the primary purpose (e.g., contracts, agreements, MOUs, deals, certifications, warranties, instructions, etc.. etc.). A record necessarily contains all the information units needed to satisfy some reference scheme for a concept that corresponds to all the members of the set. The concept may be much more general than the set itself. A record typically contains some other useful facts about each member. Ditto aggregations on the meaning side. Example: the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list _record_ /documents/ _set_ Definition: the _record_ explicitly identifies the members of the _set _Note: The set may be the extension of a particular concept. Example: a product catalog (record) documents the set of all products that the company sells. Example: a general ledger (record) documents the extension of 'company financial transaction' _ record_ /is complete /Definition: every member of the set that the record documents is explicitly identified in the record. Any thing that is not explicitly identified in the record is not a member of the set. _record_ /is authoritative/ Definition: the record is complete and the record is used as a/the reference in determining membership in the set that it documents. Ed Note: We might /define/ the 'record' to be 'complete' instead of making it an optional characteristic; that is, documenting some members of a set is not very interesting. But the problem is whether the completeness of the record is a structural rule or an operational rule. Again, I think that bringing rules into this is off-target. The real sense of "record is complete" is that the company is saying "we believe or assume this record to be complete, so if you act in a way that assumes as much, you will not be sanctioned for such action even if it turns out the record is not complete." It's actually a form of permission: It is permitted that you consider this record complete. We usually don't make elements of guidance about such things. But since SBVR assumes an open-world, in cases where the company thinks it can *close* some record, it needs to indicate special allowance for people to act that way. It's sort a disclaimer (or more accurately, maybe an indulgence.) I think it is much stronger than a form of permission. If I get a shipment with an order number that I can't find in the 'complete record', the business rule may require me to reject the shipment. The intepretation is that we did not order this. That is not 'permission to treat this as not ordered'; it is 'requirement to treat it as not ordered'. In formal reasoning terms, this idea is called 'negation as failure', and it is common in rules engines, like the Blaze Advisor tool, the ILOG tools, and many database tools. That is, 'x is an order' is formally defined as 'x is in the record of contractual orders', so 'x is not in the record of contractual orders' (the lookup failure) means 'x is not an order' (the negation). The structural rule is enforced by the logic engine. If it is an operational rule, the record might not actually /be/ complete, because maintenance of the record is a business activity that may be delayed or improperly conducted. The general ledger, for example, must be maintained. You need *real* rules for that ... e.g., Every business transaction must be be included in the general ledger. (I'm not thinking of transaction as a 'data' thing, but as a real-world thing.) This can't be a definitional thing (or structural rule) -- it has to have deontic force. You *will* be potentially penalized if you violate this rule (leave some transaction out). But this rule is aimed at different people with different responsibilities than the expression of completeness. Yes. The problem is always with other business rules that begin, "If there is no outstanding lien on the property, then ..." How does such a rule ever fire? Someone conducts a title encumbrance search on the property records in the appropriate jurisdiction, and if the records do not contain an outstanding lien, the antecedent is assumed to be true. The operational rules for maintenance are aimed at the people who manage the property records, and those who create and file the liens. But the impact is that those records are used by estate agents and financial organizations to make important business decisions. They are not the ones bound by the rules, but the antecedents of their rules depend on the record. The truth of 'there is no outstanding lien' is determined from those records alone. Other records, however, may be complete at the moment they are constructed or officially released. The product catalog for 2012 may be issued in December and remain as the authoritative specification for a year. "We will make or apply no behavioral rules against you for that period of time if you act as if the record is complete." It's a stricture against making or applying rules. I don't understand the comment. The point I was making is that some records are complete by fiat from the moment of issuance until the moment of their retirement (usually in favor of a replacement record). Those are structural rules. The record is complete by definition. BTW, this would seem like a date-time thing. You just said how long the 'grace period' applies. So should the fact type be: "record is considered complete until d-t"? Well, that depends on the record. Some such records are explicitly intended for a limited time period and have the time period built in to their definition. Others are viewed as being the reference set until and unless there is some reason to change it. The United States has had exactly the same 50 states for 50 years now, and for the indefinite future. The extension of 'state of the United States' is subject to change, according to operational rules laid out in the Constitution, but those rules don't have anything much to do with time. In a similar way, the services offered by a hospital may change as new technologies are acquired, by decision of the Board of Directors, but there is no temporal limitation on the current list. Any change to anything involves different times, but not necessarily rules or definitions involving time. Ed Note: 'record is authoritative' may be beyond the scope of SBVR. Making a record authoritative is usually a business policy and rules matter. Admittedly all we are providing is the (tentative) fact type, but it may be insufficient. A given record may be authoritative for some business activities, but not for others. The other problem is that it is only authoritative for the set membership, not necessarily for the other facts contained. The personnel record, for example, may be authoritative for the set of employees, but not necessarily up to date with respect to their immediate supervisors, or their office locations. I think you're mixing a couple of ideas here. I would not consider a list or body-of or record or aggregate to be unchanging unless you told me it was. I used to call one that is static a "snapshot". Could also be a "point-in-time image". These are very important for legal purposes. ("Never reconstruct after the fact.") I've been talking about them since the mid-80's at least. But that is not by any means limited to 'record is complete'. It may apply to every fact in your information base (fact model, actual world) and to every definition in your vocabulary. There is a difference between saying that, at any given time, a record is treated as complete with respect to making business decisions (the snapshot), and saying that a record is intended to be invariant over time. Some records change minute-by-minute and are still treated as authoritative for certain purposes -- consider stock prices. Other records are complete and constant 'until further notice', which only means they change slowly relative to business events that may demand their inspection. I owned stock in National City Bank for many years before it became PNC without my stir (regrettably). Also, 'record is authoritative'. I don't think we need this. Any application of SBVR has a scope, and anything within that scope should be considered authoritative. Why would any list or body-of or record or aggregate within scope *not* be so?? Vocabularies certainly include business records and other business artifacts that are not treated as authoritative, I would think. But in any case, I think 'record is authoritative' is a bridge too far. All in all, I say there are at least 2 ideas here: 1. Record is assumed complete [until date-time] (with respect to the basic kind of things it lists ... there will be no sanction for acting as if it's complete).This fact type.specifically closes the open-world assumption. Proposition is assumed true [until date-time] is another version of the same idea. The 'assumed' is just another case of 'what is truth', and I don't want to start putting belief modalities in SBVR fact types. Similarly, the [until date-time] is just a special case of 'state of affairs occurs over time' and has nothing special to do with records and completeness. 2. Record is immutable (cannot be changed). This permits creation of point-in-time snapshots. I don't object to this, but in many cases, it just means that the record is one of a series that have what are essentially version identifiers. The record per se is immutable, but it is replaceable. Ron -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." [Ronald G. Ross Contact Information] http://www.brsolutions.com/email/wordpress-2.png *Blog* || http://www.RonRoss.info/blog/ http://www.brsolutions.com/email/linkedin.png *LinkedIn* || http://www.linkedin.com/pub/ronald-ross/1/3b/346 http://www.brsolutions.com/email/twitter.png *Twitter* || https://twitter.com/Ronald_G_Ross http://www.brsolutions.com/email/button-green.png *Homepage* || http://www.RonRoss.info -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." To: "sbvr-rtf@omg.org" Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept X-KeepSent: 561C28AC:5779C629-85257927:00455E67; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Wed, 12 Oct 2011 09:53:12 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/12/2011 09:53:13, Serialize complete at 10/12/2011 09:53:13 x-cbid: 11101213-3534-0000-0000-00000097D6F8 Ed, Your concept of "record" is about a "set of representations". I have no objection to the "record" idea, but I suggest that the more fundamental idea is about the completeness of sets. If we accept the "set is completely known" characteristic, then a "record" can be a "communication content that is a set that is completely known" -- meaning that all the elements of the set are represented in the communication content. Notice that the representations might be in either of two forms: (a) representations of the actual things, such as the line items of an order; (b) representations of the concepts that makeup the reference scheme for the "target" concept. For example, a "record" of employees will not contain the actual employees but instead will have representations of the names or employee serial numbers or some other references to the employees. I can think of examples where the "closed world" concept applies independently of any sort of representation: * The set of my siblings is completely known to me. I can definitively say that Ed is not my sibling. * In a very small business (e.g. a small farm or retail store with fewer than a half-dozen employees), the set of employees may be "completely known" to the employer but not written down in a list. That is, the employer may be able to distinguish employees from non-employees without a "record". * In a small bookstore, there may be no formal inventory "record". The answer to the question "do you have book x?" may be answered by going to the shelves and looking. The set of books is "completely known" in the sense that they are exactly the books on the shelves. To put this another way, I do not agree that "a 'complete body of information' is the content of a repository". I think that a "complete body of information" may be knowledge in someone's mind or may be dynamically derived by "querying" something in the physical world (as in the bookstore example). Each of the above is "accessible as a package" even though not written anywhere. I propose the concept "set" as the "package" that Ed mentions because "set" is an existing SBVR "package" concept that contains "things" independently of how or whether they are represented. Note that "extension" is a role of "set" in "concept has extension". The reason that I propose "is completely known" as a characteristic of "set" (rather than "extension") is that I think the "is completely known" idea is independent of whether a set of things is conceptualized. In the bookstore example, above, the set of books "is completely known" regardless of whether or not the bookstore owner conceptualizes the set of books on the shelves as "book inventory" (or some such term). Ed correctly points out that "set is completely known" must identify either "WHO" thinks a set is complete or "WHERE" it is complete. I addressed that in my proposed definition by using the existing SBVR verb concept "semantic community shares understanding of concept". I think my proposed characteristic should be used in facts stated by semantic communities. The "WHO" is the semantic community that states a fact such as "the set of books is completely known". Ed argues that "'set is immutable' by definition". I don't see anything like that in the clause 8.7 definition of "set". It seems to me that the set of books available for sale does vary over time -- that is, over possible worlds. In any given world, the set of books is fixed and "completely known", but as that world evolves to new possible worlds, the set certainly changes. Thus, in my view and answering a question raised by Don, "set is completely known" has no special alethic implications. MHL>> I inserted a few more responses below, like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/11/2011 02:22 PM Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept -------------------------------------------------------------------------------- Mark H Linehan wrote: > I have several comments about this: > > 1) I think issue 13138 has nothing to do with the "state of affairs" > issues and should be handled entirely as a separate thread. Whether > it can be resolved within the next 3 weeks, I don't know. I concur on both counts. The issue of whether a body of information is complete has nothing whatever to do with states of affairs. The idea that a body of information is complete seems to be a concept that SBVR didn't really have. Mark and I are among those who believed that a 'conceptual schema' was something other/more than an IT packaging idea. The problem for SBVR is that it was doing double duty. And that is what makes resolving Issue 13138 really problematic -- we need to sort out the idea of 'closure of a body of information' from the idea of a body of SBVR exchange elements. > 2) I agree with Ron that there is both a "meaning" and a > "representation" side of this "closed world" issue. I think we need > to resolve the "meaning" side of it as part of 13138, otherwise we'll > lose the "closed world" capability. I think the representation aspect > (i.e. "records") can be addressed separately. I agree in part. I argue, however, that a 'complete body of information' is the content of a repository, and what is being said is that some repository of expressions holds the entire body. The whole idea of a body of information is that it is a package that is somehow accessible as a package. And the same is true of a body of shared meanings and a body of shared guidance. We can separate the content from the container, but we are implying that there is a container, or an identifiable collection of containers, that contains the body. One of the serious shortcomings of SBVR is that it provides no practical approach to terminology exchange, because it doesn't have exchange concepts for meaningful containers. > 3) For the meaning aspect, I suggest a new characteristic of "set": > "_set _/is completely known/" defined as: "each _element _/of /the > _set _is known to the _semantic community_ that /shares an > understanding of/ the _set_". I would argue that this approach is a bit misguided. A set is a 'res', not a 'meaning', so I don't know how one can 'share understanding of it'. MHL>> "Set" is a concept that defines a kind of "res". One can certainly share an understanding of MHL>> of a set independent of the elements of the set. And every set is by definition 'complete' -- it is a collection of specific things, and no others. The intensional description of a set -- the rule for membership -- is a 'concept', not a 'set'. The set is the extension of that concept. A "set that is not completely known" is a concept whose extension is not (completely) known. MHL>> Yes. My point is that a set can be "complete" but not "completely known". And a set is an MHL>> "extension" only in the context of a concept. You can implicitly refer to a set using a definite description MHL>> (e.g. "the books on the shelves") without explicitly conceptualizing it. The issue is, as clause 8 currently says, whether a 'concept is closed' -- whether the set that is its extension is extensionally defined in some 'resource'. As Don points out, we know how to define a concept extensionally -- one big OR of the 'individual concepts'. But that assumes that the 'resource' that defines the extension is an extensional definition per se. (We don't have a similar fact type for sets, because SBVR doesn't think things have designations, there is no corresponding grammatical construct in SBVR SE, and no part of SBVR provides a means of exchanging a structure that is a 'list' of specific things, even though that is a common business concept.) MHL>> This is a problem that we ran into in the Date-Time effort. Further, it assumes that the extension of the concept is not only 'known', but also 'constant'; it doesn't change over time. In many other cases, the resource is something like a database table, in which each row represents an instance, and the whole set of rows -- the table itself -- which in SBVR is a 'fact model'. In such cases, the extension of the concept, at the time of any business decision, is "completely known" and captured in that resource. That is what I meant by a 'record'. MHL>> Regarding whether SBVR thinks the extension of a concept is "known" -- SBVR is clearly "open world" MHL>> by default, meaning that the extension of a concept is not necessarily known. MHL>> Regarding whether SBVR thinks the extension of a concept is "constant" -- my reading of clause 10 is that MHL>> as one "fact model" evolves to another "fact model", the "fact population" does change. In other words, MHL>> concepts may have different extensions in different "fact models". Upon reflection, I think 'fact model' should mean 'body of information', and we want 'concept is closed in fact model'. A 'fact model' is not an XML data set that conforms to an SBVR schema. That is just one form of 'resource'/'repository' that is a container of a fact model. Every fact model is contained in some 'resource' or set of such 'resources'. A fact model that is to be identified as specifically defining the extent of some concept (by such a closure rule) must have a name or designation, and that designation may be different from the designation for the container itself (which may be an IT object or a file cabinet). MHL>> This view focusses on the WHERE. I think for business purposes, it is more helpful to focus on the WHO. I think my concept 'record' is the expression of a 'fact model' within some 'resource'. And I think 'communication content' is the expression of a 'fact model' (i.e., body of information), or perhaps a role of that expression with respect to some 'resource', such as a document, a database, or a message. _ _ > > > * Redoing the existing example in 8.5 in the Note under "concept > is closed in conceptual schema": both EU-Rent and a corporate customer > of EU-Rent might adopt EU-Rent''s "rental" concept. Only the EU-Rent > semantic community would state as a fact "the _extension _/of /_rental > _/is completely known/" to indicate that EU-Rent knows all its rentals. The idea: 'extension of _concept_ is completely known', as distinct from '_set_ is completely known', is useful. But, that it is completely known to unidentified parties is not useful in business. The useful fact type must be binary: we need to know WHO knows, or WHERE it is captured. So there may be two such fact types: 'extension of _concept_ is known by _party_' and 'extension of _concept_ is specified in _record_'. SBVR itself never introduces 'party' (or SUMO 'legal entity', or anything the like); so that makes it difficult to express the WHO version. I proposed 'record' to address the WHERE. MHL>>This is why I used the concept "semantic community" for what Ed calls "party". > The corporate customer would not state this fact so would operate on > the usual "open world" assumption. In point of fact, the corporate customer doesn't care about other EU Rent rentals; they are not likely to be things in its world of interest. So its concept 'rental' would have a different extension. It may still be true that it is treated as 'open'. > * Consider an order that has multiple line items. The fact "the > extension of 'order has line item' is completely known" means that the > semantic community that states this fact knows all the actualities of > "order has line item". This is actually a bit trickier. Knowing all the actualities of 'order has line item' requires some resource/party to know all of the orders, and all of the line items in each. One would expect, of course, that an 'orders database' would have all that. So the fact type 'customer order has line item' is closed in the 'customer orders data' (fact model) which is captured as a set of tables (the record) in the Sales Database (repository). But the signed contract that documents a specific 'order' explicitly documents all of the line items for that order -- it is a closed 'record' of the line items of that order only. > Responding to Ron's comments: > > * "set" is an existing SBVR concept that is similar to "aggregation" > * I did not address "set is immutable" because I think it is outside > the scope of 13138. The more general concept is 'collection'; 'aggregation' has several meanings of which 'set' is not a specialization. And 'set is immutable' by definition. A 'set' is a specific enumeration of things, and no others. If you add one, or take one out, you get a different 'set' -- a distinguishably different instance of the concept 'set'. > Responding to Ed's comments: > > * I don't think the distinction between "is complete" and "is > authoritative" is worth the additional complexity of having two > characteristics rather than one. I agree. I think 'is authoritative' is an inappropriate addition. Business rules determine what is authoritative for what purposes, and the 'characteristic' alone may not actually characterize anything. We do best by not going there. -Ed > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > > > From: "Donald Chapin" > To: "'Ronald G. Ross'" > Cc: "'SBVR RTF'" > Date: 10/10/2011 10:21 AM > Subject: RE: SBVR: Fallout from Issue 13138: the "record" concept > ------------------------------------------------------------------------ > > > > Ron, > > I agree with your concerns both about timing, and whether there is > really an Issue with respect to the âcommunication contentâ-related > concepts in Clause 11.2.2. > > I believe that Markâs preferred solution to a business-oriented > ability to specify the availability of knowledge about instances of > SBVR concepts, which is focused on the */set/* of instances that > comprise the extensions of concepts, is the simplest and most > workable. It is inherently part of Issue 13138 because of moving the > âclosed in fact modelâ concepts into Clause 10 > > Given that, dealing with any ambiguities, contradictions, internal > disconnects or other problems with âcommunication contentâ-related > concepts in Clause 11.2.2 really requires a new Issue that addresses > those problems, if any exist, directly and explicitly. Such an Issue > would best be dealt with in SBVR v1.2 after we get SBVR v1.1 accepted > by the OMG Architecture Board. > > Donald > > > > *From:* Ronald G. Ross [mailto:rross@brsolutions.com] * > Sent:* 08 October 2011 01:33* > To:* edbark@nist.gov; SBVR RTF* > Subject:* Re: SBVR: Fallout from Issue 13138: the "record" concept > > Ed, > > I basically like what you have suggested. And it excites me. > This is the kind of thing SBVR ought to be clarifying for business > people. I do have some comments, but first this. > > I don't see how this issue can be resolved in the next 3 weeks. > But more importantly, let's think about whether it needs to be. > ***After today's discussion can we safely say it can be dealt with > *without* impacting states-of-affairs questions??*** > > A couple of general points. > > 1. Would you agree that a good dictionary basis for "record" as you > mean it would be: MWUD 2b(3): a body of known, recorded, or available > facts about something : the sum of something done or achieved or the > body of data known, recorded, or available about something ... We > would need a good dictionary basis. We don't want people to assume the > IT sense of "record". > > 2 . On the meaning side (and from a business point of view) I believe > a "record" might correspond to an "aggregation" as per MWUD 2: a > group, body, or mass composed of many distinct parts : ASSEMBLAGE > (This is Issue 16523.) Your examples ("the DUNS registry, a general > ledger, a shipping manifest, an employee phone book, a product > catalog, a team roster, an approved supplier list") seem to suggest that. > > 3. To your definition of "record is complete" I would add these words: > "Any thing that is not explicitly identified in the record **can be > assumed** not a member of the set." I see "record is complete" is > really a CYA kind of thing. Read on ... > > > At 12:42 PM 10/7/2011, Ed Barkmeyer wrote: > > For those who just came in, the 7 Oct 2011 conference call included a > discussion of Mark's idea that the explicit list of members of a set, > such as the "set of products we sell" may be completely known and be > an authoritative reference that is cited in business rules. > > I proposed the idea of a 'record', and this is an attempt to define it. > > _record_ > Definition: a _communication content_ that explicitly identifies each > member of a set and may provide additional facts about the individual > members. > Note: See 11.2.2.3 > Note: A record is a set of representations that captures the body of > knowledge as to exactly which things are members of the set. > > I like this phrase. It clearly distinguishes "record" by its business > intent and thereby distinguishes it from other kinds of business > content where business vocabulary does need to be used but where > 'complete list' is *not* the primary purpose (e.g., contracts, > agreements, MOUs, deals, certifications, warranties, instructions, > etc.. etc.). > > > A record necessarily contains all the information units needed to > satisfy some reference scheme for a concept that corresponds to all > the members of the set. The concept may be much more general than the > set itself. A record typically contains some other useful facts about > each member. > > Ditto aggregations on the meaning side. > > > Example: the DUNS registry, a general ledger, a shipping manifest, an > employee phone book, a product catalog, a team roster, an approved > supplier list > > _record_ /documents/ _set_ > Definition: the _record_ explicitly identifies the members of the _set > _Note: The set may be the extension of a particular concept. > Example: a product catalog (record) documents the set of all products > that the company sells. > Example: a general ledger (record) documents the extension of > 'company financial transaction' > _ > record_ /is complete > /Definition: every member of the set that the record documents is > explicitly identified in the record. Any thing that is not explicitly > identified in the record is not a member of the set. > > _record_ /is authoritative/ > Definition: the record is complete and the record is used as a/the > reference in determining membership in the set that it documents. > > > Ed Note: We might /define/ the 'record' to be 'complete' instead of > making it an optional characteristic; that is, documenting some > members of a set is not very interesting. But the problem is whether > the completeness of the record is a structural rule or an operational > rule. > > Again, I think that bringing rules into this is off-target. The real > sense of "record is complete" is that the company is saying "we > believe or assume this record to be complete, so if you act in a way > that assumes as much, you will not be sanctioned for such action even > if it turns out the record is not complete." It's actually a form of > permission: It is permitted that you consider this record complete. > > We usually don't make elements of guidance about such things. But > since SBVR assumes an open-world, in cases where the company thinks it > can *close* some record, it needs to indicate special allowance for > people to act that way. It's sort a disclaimer (or more accurately, > maybe an indulgence.) > > > > If it is an operational rule, the record might not actually /be/ > complete, because maintenance of the record is a business activity > that may be delayed or improperly conducted. The general ledger, for > example, must be maintained. > > You need *real* rules for that ... e.g., Every business transaction > must be be included in the general ledger. (I'm not thinking of > transaction as a 'data' thing, but as a real-world thing.) This can't > be a definitional thing (or structural rule) -- it has to have deontic > force. You *will* be potentially penalized if you violate this rule > (leave some transaction out). But this rule is aimed at different > people with different responsibilities than the expression of > completeness. > > > > Other records, however, may be complete at the moment they are > constructed or officially released. The product catalog for 2012 may > be issued in December and remain as the authoritative specification > for a year. > > "We will make or apply no behavioral rules against you for that period > of time if you act as if the record is complete." It's a stricture > against making or applying rules. > > BTW, this would seem like a date-time thing. You just said how long > the 'grace period' applies. So should the fact type be: "record is > considered complete until d-t"? > > > > Ed Note: 'record is authoritative' may be beyond the scope of SBVR. > Making a record authoritative is usually a business policy and rules > matter. Admittedly all we are providing is the (tentative) fact type, > but it may be insufficient. A given record may be authoritative for > some business activities, but not for others. The other problem is > that it is only authoritative for the set membership, not necessarily > for the other facts contained. The personnel record, for example, may > be authoritative for the set of employees, but not necessarily up to > date with respect to their immediate supervisors, or their office > locations. > > I think you're mixing a couple of ideas here. I would not consider a > list or body-of or record or aggregate to be unchanging unless you > told me it was. I used to call one that is static a "snapshot". Could > also be a "point-in-time image". These are very important for legal > purposes. ("Never reconstruct after the fact.") I've been talking > about them since the mid-80's at least. > > Also, 'record is authoritative'. I don't think we need this. Any > application of SBVR has a scope, and anything within that scope should > be considered authoritative. Why would any list or body-of or record > or aggregate within scope *not* be so?? > > All in all, I say there are at least 2 ideas here: > > 1. Record is assumed complete [until date-time] (with respect to the > basic kind of things it lists ... there will be no sanction for acting > as if it's complete).This fact type.specifically closes the open-world > assumption. > 2. Record is immutable (cannot be changed). This permits creation of > point-in-time snapshots. > > Ron > > > > -Ed > > -- > Edward J. Barkmeyer Email: _edbark@nist.gov_ > > National Institute of Standards & Technology > Manufacturing Systems Integration Division > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > "The opinions expressed above do not reflect consensus of NIST, and > have not been reviewed by any Government authority." > > > > *Blog* || _http://www.RonRoss.info/blog/_ > > *LinkedIn* || _http://www.linkedin.com/pub/ronald-ross/1/3b/346_ > *Twitter* || _https://twitter.com/Ronald_G_Ross_ > *Homepage* || _http://www.RonRoss.info_ > > -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: "Donald Chapin" To: "'Mark H Linehan'" , Subject: RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Date: Wed, 12 Oct 2011 17:14:43 +0100 X-Mailer: Microsoft Outlook 14.0 thread-index: AcyI+gHGWLi6h0lVSt24LWiiuafQdg== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E95BCF4.0007, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2011.10.12.143615:17:8.129, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __OEM_SOFTWARE_5, SUPERLONG_LINE, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_70_90, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, OEM_SOFTWARE_X1, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4E95BCF7.0004,ss=1,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 Mark, On 11 October 2011 18:34 Mark wrote: Donald, Why did you not write the "is completely known" characteristic in terms of "set" rather than in terms of "concept"? First, semantic communities only share meanings and set is not a meaning. Second, every set by definition is complete. Third, put it on .concept. does the required job. The purpose of this is to know whether or not the semantic community knows all the things in the Universe of Discourse that are in the extension of the concept. There is no other connection between the Universe of Discourse and concepts excepts the concept.s extension. However, as Don points out there are potential alethic concerns about using concept. So in the next revision I will make it: extension is completely known. This will work because the definition for extension is that it is for a given concept. This approach has the best of set in that it has no alethic implications and still ties the .is completely known. the a given concept whose meaning is shared by the semantic community. In the definition you propose, why do you use "is known to exist" for noun concepts and "is known to have occurred" for verb concepts? Why "exist" in one case and "occurred" in the other? Why use the simple aspect in "is known to exist" and the perfect aspect in "is known to have occurred"? And should "exist" be associated with existential quantification or not? I.ll remove these in the next version. Donald -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: "sbvr-rtf " Date: 10/11/2011 09:41 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution -------------------------------------------------------------------------------- Attached is an updated draft resolution to Issue 13138 that incorporates all the input from SBVR RTF telecons and email discussions to date. The objective is to release the resolution of Issue 13138 to ballot, with revisions as necessary, in this Friday.s SBVR telecon. Please discuss any questions you may have via the SBVR RTF email list before Friday.s telecon. Many thanks, Donald From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2011 12:30 To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald [attachment "Draft Resolution for Issue 13138- 2011-10-11-1400.doc" deleted by Mark H Linehan/Watson/IBM] From: "Donald Chapin" To: "sbvr-rtf " Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Date: Wed, 12 Oct 2011 17:16:34 +0100 X-Mailer: Microsoft Outlook 14.0 thread-index: AQDjDZT3ixhxN3T1Dk0ZiN4CsibJRpdKF34wgAHAofA= X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E95BD63.0028, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.12.153614:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __OEM_SOFTWARE_5, __FRAUD_CONTACT_NAME, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_70_90, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, OEM_SOFTWARE_X1, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4E95BDE0.0199,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 an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback from Mark, Ed and Don. From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 11 October 2011 14:32 To: sbvr-rtf (sbvr-rtf@omg.org) Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is an updated draft resolution to Issue 13138 that incorporates all the input from SBVR RTF telecons and email discussions to date. The objective is to release the resolution of Issue 13138 to ballot, with revisions as necessary, in this Friday.s SBVR telecon. Please discuss any questions you may have via the SBVR RTF email list before Friday.s telecon. Many thanks, Donald From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2011 12:30 To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald Draft Resolution for Issue 13138- 2011-10-12.doc Disposition: Resolved OMG Issue No: 13138 Title: Move fact model container concepts from Clause 8 to Clause 10 Source: Business Semantics Ltd, Donald Chapin, (Donald.Chapin@btinternet.com) Summary: In resolution of Issue 12540 (Clause 8 does not include the concepts needed to represent itself) it was recognized that subclause 8.5 defines containers that are not part of the SBVR metamodel, but are relevant to the formal semantics concepts in Clause 10. They would be more appropriately placed in Clause 10. Resolution: 1. Sub-clause 8.5 is, for all practical purposes, disconnected from the rest of Clauses 7, 8, 9, 11 & 12 in that the terms (i.e. conceptual schema, fact model) defined in Sub-clause 8.5 are hardly used at all in Clauses 7, 8, 9, 11 & 12, and none of those uses are styled. Conversely Clause 10.1.1 .SBVR Formal Grounding Model Interpretation. (as well as the non-normative Annex L: .A Conceptual Overview of SBVR and the NIAM2007 Procedure to Specify a Conceptual Schema.) makes high use of the terms defined Sub-clause 8.5. The vocabulary entries in Sub-clause 8.5 are moved to the context where they are used normatively i.e. in Clause 10. 2. The .closed in fact model. concepts in clause 8.5 could be read to include a .business-oriented ability to specify the availability of knowledge about instances of SBVR concepts.. To preserve this function when Clause 8.5 is moved to Clause 10, add a characteristic to concept that specifies this. 3. Clarify that the uses of .conceptual schema. and .fact model. in Clause 2 .Conformance. refer to their use in Clause 13 .SBVR.s Use of MOF and XMI. as defined in Clause 10.1.2.1 4. Make clear that the uses of .conceptual schema. and .fact model. in Clause 13 .SBVR.s Use of MOF and XMI. are as defined in Sub-clause 10.1.2.1 5. Clarify that the Sub-clause 8.6.2 necessities are about the distinction between what is in the SBVR model and what is the Universe of Discourse of the SBVR Model. Revised Text: 1. Move Sub-clause 8.5 a. MOVE the entire Sub-clause 8.5 as is to Clause 10 as Sub-clause 10.1.2.1 .Conceptual Schemas and Models.. a.b. REMOVE the .FL. markings on all the entries in Sub-clause 10.1.2.1 b.c. REMOVE the item .5. Conceptual Schemas and Models. from the list of subjects at the end of the introductory paragraphs of Clause 8 on printed page 18 2. ADD the following entry to Clause 11.1.1 directly after .semantic community shares understanding of concept.: concept extension is completely known Definition: If the concept is a noun concept then each instance in the extension of the noun concept is known to exist by the semantic community that shares the understanding of the noun concept else if the concept is a verb concept then each instance of the verb concept is known to have occurred by the semantic community that shares the understanding of the verb concept Note: The means and source of .completely knowing. is outside the scope of SBVR. It could be knowledge that people have; it could be recorded information; and/or it could be direct observation. All that this characteristic asserts is that all the instances in the extension of the concept are completely known -- as in .taken to be true. or .believed to be a fact.. Errors in the recorded data or knowledge and observations of people are outside the scope of SBVR. Note: If this characteristic is not specified for a given concept, is it assumed to be .false. by default as per SBVR's normal 'open world' semantics. Note: Under SBVR's normal 'open world' semantics, there could be instances in the extension of the concept that exist but are unknown. "Concept is completely known" reverses the 'open world' assumption with respect to the concept. If a concept is completely known, then an existential quantification such as "if there does not exist an instance of the concept that " can be relied upon to conclusively determine that there is no instance that meets the given condition. Example: .is completely known. is specified as a metafact for the concept .rental. in the SBVR Terminological Dictionary contain it. 3. Clarify that the uses of .conceptual schema. and .fact model. in Clause 2 a. ADD the following as the third paragraph immediately following the Clause 2 .Conformance. heading: .All references to .conceptual schema. and .fact model. in this clause are references to their use in Clause 13 .SBVR.s Use of MOF and XMI. as they are defined in Clause 10.1.2.1.. b. REPLACE the first paragraph in Sub-clause 2.3 .Conformance of an SBVR exchange document.: .An exchange document that conforms to this specification (an .SBVR exchange document.) shall be an XML document that represents a .fact model. as defined in subclause 8.5.. WITH .An exchange document that conforms to this specification (an .SBVR exchange document.) shall be an XML document that represents a .fact model. as used in Clause 13 .SBVR.s Use of MOF and XMI. and defined in subclause 10.1.2.1.. c. REPLACE at the end of paragraph 2 under .EXAMPLE. in Sub-clause 2.3: .(see 8.5). WITH .(see subclause 10.1.2.1). 4. ADD the following as at the end of fourth last introductory paragraph immediately followingof the Clause 13.1.2 .SBVR.s Use of MOF and XMI. heading: All references to .conceptual schema. and .fact model. in this clause are as defined in Clause 10.1.2.1. 5. REPLACE the last two sentences in the introductory paragraph to Sub-clause 8.6.2 .Necessities Concerning Extension.: Other necessities stated in the context of the Meaning and Representation Vocabulary concern the contents of conceptual schemas and their representations. But the following necessities concern each fact model in relation to the conceptual schema that underlies it. WITH Other necessities stated in the context of the Meaning and Representation Vocabulary concern the contents of terminological dictionarymeanings and their representations. But the following necessities concern the relationships between a meaning in the terminological dictionary and its extension in the universe of discourse addressed by the terminological dictionary are about the correspondence of meanings to things in the universe of discourse. Disposition: Resolved From: "Donald Chapin" To: "sbvr-rtf " Subject: RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Date: Wed, 12 Oct 2011 17:16:43 +0100 X-Mailer: Microsoft Outlook 14.0 thread-index: AQDjDZT3ixhxN3T1Dk0ZiN4CsibJRgJXnCFnAS3rcwADLx7SCAHw7QmSlwashdA= X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E95BD6C.0099, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2011.10.12.145714:17:8.129, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __CP_NOT_1, __OEM_SOFTWARE_5, __FRAUD_CONTACT_NAME, SUPERLONG_LINE, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_70_90, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, OEM_SOFTWARE_X1, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4E95BDFE.0134,ss=1,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 Don, I.ve fixed all the items you pointed out below in the update just sent out. Donald From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: 11 October 2011 20:20 To: Donald Chapin (Donald.Chapin@BusinessSemantics.com) Subject: FW: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Hi Donald, I just noticed that for part 5 I should have said .meanings. where I said .concepts.. See change highlighted below. Best regards, Don From: Don Baisley [mailto:Don.Baisley@microsoft.com] Sent: Tuesday, October 11, 2011 11:52 AM To: sbvr-rtf@omg.org Subject: RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution I agree with Mark.s concerns. Also, I have other concerns about part 2 of the resolution: 1. What are the intended alethic implications of the new .is completely known. fact type? In general, SBVR fact types about concepts are for defining concept systems, so they have clear alethic implications: they are used to state facts that are true for all states of the universe of discourse. I don.t see that made clear in the new definition. 2. Knowing that every instance exists is not the same as knowing the identification, based on a reference scheme, for every instance. 3. I hope we will look at more flexible ways of describing completeness of information sources that will be useful when writing rules. When writing rules, a business person will .use. a concept to refer to a .set. of things. The rule will use the concept, not mention it. But using the new .is completely known. fact type in a rule will require mentioning a concept. Regarding part 1 in the draft resolution: Please add to the instructions that the .FL. markers should be removed from the ends of the lines. Those markers are not used in clause 10. Part 4 of the resolution should be put into the last paragraph of 13.1.2. The simplest thing is to add the following parenthetical expression to the end of the second sentence: (see Clause 10.1.2.1) Part 5 is important. The new text should be this: Other necessities stated in the context of the Meaning and Representation Vocabulary concern meanings and their representations. But the following necessities are about the correspondence of meanings to things in a universe of discourse. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Tuesday, October 11, 2011 10:34 AM To: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Donald, Why did you not write the "is completely known" characteristic in terms of "set" rather than in terms of "concept"? In the definition you propose, why do you use "is known to exist" for noun concepts and "is known to have occurred" for verb concepts? Why "exist" in one case and "occurred" in the other? Why use the simple aspect in "is know to exist" and the perfect aspect in "is known to have occurred"? And should "exist" be associated with existential quantification or not? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: "sbvr-rtf " Date: 10/11/2011 09:41 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution -------------------------------------------------------------------------------- Attached is an updated draft resolution to Issue 13138 that incorporates all the input from SBVR RTF telecons and email discussions to date. The objective is to release the resolution of Issue 13138 to ballot, with revisions as necessary, in this Friday.s SBVR telecon. Please discuss any questions you may have via the SBVR RTF email list before Friday.s telecon. Many thanks, Donald From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2011 12:30 To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald [attachment "Draft Resolution for Issue 13138- 2011-10-11-1400.doc" deleted by Mark H Linehan/Watson/IBM] To: sbvr-rtf@omg.org Subject: RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution X-KeepSent: C7087AFD:8C7D5715-85257927:00645D3C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Wed, 12 Oct 2011 14:31:40 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/12/2011 14:31:42, Serialize complete at 10/12/2011 14:31:42 x-cbid: 11101218-8974-0000-0000-000000CDF535 MHL>> Comments like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: Mark H Linehan/Watson/IBM@IBMUS, Date: 10/12/2011 12:25 PM Subject: RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution -------------------------------------------------------------------------------- Mark, On 11 October 2011 18:34 Mark wrote: Donald, Why did you not write the "is completely known" characteristic in terms of "set" rather than in terms of "concept"? First, semantic communities only share meanings and set is not a meaning. The concept "set" is a concept defined as a kind of "res". Thus if I define (for example) "bill of materials" as "set of parts needed to manufacture an xx", the concept "bill of materials" is a meaning and the characteristic "is completely known" would be meaningful with respect to "bill of materials". Second, every set by definition is complete. Under the open world assumption, even if a set is "complete", the contents may not be "known". A condition such as "if the bill of materials does not include a part that weighs more than 20 kilos" would be unsatisfiable under the open world assumption because there is no justification to believe that all the elements of the set are known. Third, put it on âconceptâ does the required job. The purpose of this is to know whether or not the semantic community knows all the things in the Universe of Discourse that are in the extension of the concept. There is no other connection between the Universe of Discourse and concepts excepts the conceptâs extension. However, as Don points out there are potential alethic concerns about using concept. So in the next revision I will make it: extension is completely known. "Extension" is a role of "set". Putting it on "set" has the advantage that it applies to any set, not just those sets that are the extensions of concepts. This will work because the definition for extension is that it is for a given concept. This approach has the best of set in that it has no alethic implications and still ties the âis completely knownâ the a given concept whose meaning is shared by the semantic community. I agree with the goal of tying the characteristic to a semantic community. But we need to be careful about how this association is accomplished. In the rental example, the same "rental" concept is "completely known" by EU-Rent but not by its corporate customers. rental: contract with a renter specifying use of some car of a car group for a rental period and a car movement I would expect that there would be several "bodies of shared meaning", organized as follows: 1. A "body of shared meaning" (and one or more terminological dictionaries that express the body of shared meaning) that is shared between EU-Rent and its customers, defining concepts like "rental" such that EU-Rent and the customers can communicate about these concepts. 2. A "body of shared meaning" (and terminological dictionary) defined by EU-Rent for itself, and containing concepts that are meaningful only to EU-Rent. I think this body of shared meaning would include a fact such as "the extension of the concept 'rental' is completely known" to mean that EU-Rent knows about all the rentals. Because the "completely known" fact is only in #2, it would not be asserted with respect to EU-Rent's customers, who are using #1. In the definition you propose, why do you use "is known to exist" for noun concepts and "is known to have occurred" for verb concepts? Why "exist" in one case and "occurred" in the other? Why use the simple aspect in "is known to exist" and the perfect aspect in "is known to have occurred"? And should "exist" be associated with existential quantification or not? Iâll remove these in the next version. Donald -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: "sbvr-rtf " Date: 10/11/2011 09:41 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution -------------------------------------------------------------------------------- Attached is an updated draft resolution to Issue 13138 that incorporates all the input from SBVR RTF telecons and email discussions to date. The objective is to release the resolution of Issue 13138 to ballot, with revisions as necessary, in this Fridayâs SBVR telecon. Please discuss any questions you may have via the SBVR RTF email list before Fridayâs telecon. Many thanks, Donald From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 22 September 2011 12:30 To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== All . Please see attached Word documeent 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald [attachment "Draft Resolution for Issue 13138- 2011-10-11-1400.doc" deleted by Mark H Linehan/Watson/IBM] X-Yahoo-Newman-Id: 633946.78794.bm@omp1002.access.mail.sp2.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1318451216; bh=5JlWUcWLV/823EZozTNznGG4qRSo2Rh5fuc0i7A9nV0=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:In-Reply-To:References:Mime-Version:Content-Type; b=HTzspl8bQ+I5TsnS/aWBQ27NUZ1VSahXUd4IJk8sBGfZ+d9yNRSIzhS2pLXVZeG1pExsKGDaJ4EMLa7kraHUlgi/EA8fKqcbBbjSaMrcqqdnulcSpaXjd5y6h2dJVzLI7MbB18yysmSNZFWqbHm32vaojcC31qql0R+hB9EFjOc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: XBImPzUVM1kymn6QMMPEcnCsRZSYoYepG2ZXpjuYgyN8xEK 355WW.43tQuHQPEbuWJtnFNDOcJFFdsIxU6dMFabkmtB3ZLySFtwPIJ6RK1Q tZu_RXIcj1NAWfm6wH4m1ndQZuglC9dwM32xJRdilAe40u_IY4ZbUO0FZHgS INau2Z9VQapCF8dOal59dIGRcfXQOHwJ.E55omrHPl_jRt9bXqsTt.gpXesw YSRtEcS9rdSXEtVBnS5dIt0WqsORtEK9_Kd8zSiLJJf39B1bIy7DiEcO061z GWE6XnkPRcHXEO8BVTu5CEvVSmyDTmu5x.O170yYIbBwqJPBIlGdu.vGS7DG ZLbTC.XrO76axzPGzPIA_peSjtgsddld7qRPHx7sWsJpgI67M9UKfDMCnIJw 44XQTZxF_1IRVwMNQeeO6Y2_zlfexQNq.MiqxmR7sZrACouhO9vtqWr.kEoI SKZ4I17ei3_nl.ijYSGjX7DBThL.528S7g1Xwnz50KufLoxd6lPOyOq7CWBR j.Q718_L4YlG6yXg81mCM224CEhcjK1f7mtSUg_iDmsm4Bt8DqnE04dWYvuz M4gpGdXJFFXm3Ml0Uk7BgGyzs46l99lg_lrKcl0hkyHzwqagtgw8U7jOGZK8 ffES.XNMteRsODBifxekELVIC1PSbE4YtH4YfMAg5 X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Oct 2011 15:25:01 -0500 To: sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: [containers and bigger problems] RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution All, [The important part is at the bottom.] For some time we have been using the word "container" as a catch-all term to talk about various things in SBVR, including (as I understand): * body of shared meanings * body of shared concepts * body of shared guidance * vocabulary * business vocabulary * terminological dictionary * rulebook * conceptual schema * fact model "Container" is a misleading term. MWUD defines "container" as: "one that contains: as (a): a receptacle (as a box or jar) or a formed or flexible covering for the packing or shipment of articles, goods, or commodities". MWUD gives conflicting definitions for "contain", includng: 2a: to have within : HOLD *the box contained only some old papers and a few odds and ends* 2b: to consist of wholly or in part : COMPRISE, INCLUDE *the bill contains several new clauses* 2c: ENCLOSE *the building contains classrooms and an auditorium*". The term we should be using is "aggregation". This is the closest business term that fits things of this nature. (See my issue 19523.) Here is the relevant MWUD definition: 2: a group, body, or mass composed of many distinct parts : ASSEMBLAGE. Yes, it's Ron being Ron, but we should call things by the closest real-world terms wherever possible. Mark has had outstanding issues (e.g., 12540, 12541, 12542, 15151) pending since 2008 about how these aggregations (my word) relate to each other and how they should be used by tools. I have also raised various related issues. But the problem is even more fundamental. Ed made the following comment in a recent e-mail which has really stuck with my like a burr under a saddle: "For the record, this is why SBVR is useless for the exchange of 'vocabularies'. There is no agreement on which of these collections a business vocabulary management tool should exchange. Compare with SKOS, which has one structure with some (not many) content options. The consequence of supporting every special nuance is defeating interoperability. We would suggest that SBVR needs terminological dictionary, rulebook and fact model, and the rest are academic." This is *very* discouraging ... and I don't think I'm speaking just for Ed and myself. I want some resolution and progress NOW on these issues. How can we resolve them for 1.1? First let me say that I am appalled by the lack of thought given to presentation, organization and explanation in Clauses 8, 9, and 11. (Yes, again Ron being Ron, but it is inexcusably naive to think that good idea sell themselves just because they are good.) Can we create a new section in Clause 11 and put at least the specific aggregations SBVR is meant to exchange in it (and say so clearly) and work out how they relate? Three years is too long for issues like these to sit on the table. WE DON'T HAVE FOREVER. Ron Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Date: Wed, 12 Oct 2011 17:37:42 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9CLbl0X004003 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1319060269.83789@ueOLvEV/b6BCJWpwWCphtA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark wrote: Ed, Your concept of "record" is about a "set of representations". Well, I said it is a representation of a body of knowledge, which in turn is a set of representations of the elements of that body, yes. I have no objection to the "record" idea, but I suggest that the more fundamental idea is about the completeness of sets. I have no objection to the 'set is known by person(s)' idea, but it is not more fundamental. It is just different. I do object to term 'completeness of sets". 'is complete' and 'is completely known to community' are different ideas. A set is a collection of specific things. All sets are complete; they contain exactly the elements that make up the set. If we accept the "set is completely known" characteristic I don't. It is not a useful characteristic. The basic concept you mean is a binary fact type. "Knowing" requires an intelligent agent. The fact type you mean is '_set_ /is completely known by/ _group_'. I would argue that 'set is completely known' is formally defined by: there exists some group of persons g such that _set_ is completely known by g And I aver that that information is not useful to business purposes, while the binary fact type may well be. , then a "record" can be a "communication content that is a set that is completely known" -- meaning that all the elements of the set are represented in the communication content. The fact type I stated is the one I meant. '_Set_ is completely documented by _record_', aka 'record documents set'. The record enumerates the elements of the set, by providing identifiers for each element, and possibly other information. Finding the record and reading the information is a different process from finding the person who knows and asking him and listening to what he tells you. They are different means of adding you to the group of persons who know the set. And in different circumstances one may be better than the other. But neither is more 'fundamental'. In the terms of clause 11, the knowledge is transferred by communication content, the distinction is in the form and the access mechanism. I don't argue that the fact type 'group completely knows set' is a bad idea, but it is a different idea from 'record completely documents set'. And the relationship between them is that some group who completely knows the set created the record, and did not thereafter have to provide the information to multiple clients one by one. "That the UK Foreign Ministry Bureau for Central America completely knows the set of states of Mexico" is a useful fact; "that Wikipedia documents the set of states of Mexico" is probably a more useful fact. Notice that the representations might be in either of two forms: (a) representations of the actual things, such as the line items of an order; (b) representations of the concepts that makeup the reference scheme for the "target" concept. For example, a "record" of employees will not contain the actual employees but instead will have representations of the names or employee serial numbers or some other references to the employees. This is a good point. If we elect to keep 'record', then we should improve on the definition: (a) is what is meant. (b) defines a concept. It only defines a set as the extension of that concept, which takes us back to square one. Now "representations of the actual things" is not quite right, because SBVR says that only concepts have representations. The term I used was 'identifiers' for the things that are the elements of the set, that is, the record provides the values of the elements of some reference scheme for the individual things. I believe Mark's example is an example of (a) thus reworded, in that employee numbers are identifiers for employees. Aside: "identifies" and "identifiers" is about the behaviour of reference schemes, not representations. Terry's intent in this is that while we may think that "Ed Barkmeyer" /represents/ a person, what we really mean is "the person whose name is 'Ed Barkmeyer'" -- a definite description that resolves to an individual person (assuming that it does). "the person whose name is 'Ed Barkmeyer'" is a concept that corresponds to exactly one person (in our current UoD). The designation for that concept is its definition. We may choose to make the symbol 'Ed Barkmeyer' a designation for that individual concept as well, but that is a separate concern. The name expression is being used as the value of the sole element of a reference scheme for 'person'. But it is the thing (the actual person) that has the 'name' attribute, and the name attribute per se has nothing to do with designations or individual concepts. The SBVR definition of 'thing has name' is utterly misguided. 'thing has name' just makes an expression play the role of 'name' with respect to a thing. The intent of that role is to participate in a reference scheme for the thing. I can think of examples where the "closed world" concept applies independently of any sort of representation: * The set of my siblings is completely known to me. I can definitively say that Ed is not my sibling. * In a very small business (e.g. a small farm or retail store with fewer than a half-dozen employees), the set of employees may be "completely known" to the employer but not written down in a list. That is, the employer may be able to distinguish employees from non-employees without a "record". This is absolutely correct. In each case a specific person or group does the knowing. As I said, there is nothing wrong with the binary 'person knows all elements of set' fact type; it is just distantly related to 'record documents set'. * In a small bookstore, there may be no formal inventory "record". The answer to the question "do you have book x?" may be answered by going to the shelves and looking. The set of books is "completely known" in the sense that they are exactly the books on the shelves. Yes. There is no record. But the set is not 'known'. It is just the set of books on the shelves. The elements of that set can become 'known' to anyone who gets to examine all the shelves. But it is not 'known' in any other sense. To put this another way, I do not agree that "a 'complete body of information' is the content of a repository". I think that a "complete body of information" may be knowledge in someone's mind or may be dynamically derived by "querying" something in the physical world (as in the bookstore example). How the knowledge is derived is irrelevant. It is known when someone has the knowledge, and not otherwise. Each of the above is "accessible as a package" even though not written anywhere. I propose the concept "set" as the "package" that Ed mentions because "set" is an existing SBVR "package" concept that contains "things" independently of how or whether they are represented. This is word conflation. The 'body of information that identifies each element of the set of states of Mexico' is not the 'set of states of Mexico'. An 'accessible package' that is or contains the 'body of information' is not and does not contain the 'set of states of Mexico'. And the person who completely knows the set of states of Mexico knows some identifier for, and possibly other facts about, each and every element of that set. What he knows is information, not states. Note that "extension" is a role of "set" in "concept has extension". The reason that I propose "is completely known" as a characteristic of "set" (rather than "extension") is that I think the "is completely known" idea is independent of whether a set of things is conceptualized. In the bookstore example, above, the set of books "is completely known" regardless of whether or not the bookstore owner conceptualizes the set of books on the shelves as "book inventory" (or some such term). I agree with this. I see no problem with 'person knows set' and 'record documents set'. Ed correctly points out that "set is completely known" must identify either "WHO" thinks a set is complete or "WHERE" it is complete. I addressed that in my proposed definition by using the existing SBVR verb concept "semantic community shares understanding of concept". I think my proposed characteristic should be used in facts stated by semantic communities. The "WHO" is the semantic community that states a fact such as "the set of books is completely known". Ah! That is, the subject of 'group knows set' is a semantic community that has a definite description. Mark wants define 'set is known' as: the semantic community that shares the body of shared meaning that contains some concept that refers to this set knows exactly which individual things are in the set. Or something like that. Is that right? Does that also mean that no one will ever refer to the set who doesn't know all the members? I can't talk about the set of states of Mexico because I don't know them all? And if you don't know them, you can't understand the concept? I don't believe that the semantic community that uses the concept knows them all. Further, I don't understand the business use of the idea that the originating community knows what the elements of the set are. For business purposes, I just need some authority I can ask; I really don't care whether it is the originators of the term or the local librarian. I really don't think this definition is viable. And I really don't think this is the fact type we want. Just put the subject role out there and let the user fill it with something useful. Most importantly, this doesn't address the closure issue. The point of this was to be able to say that the set of individual facts in some body of knowledge completely enumerates the members of a set. It is a particular body of knowledge, not necessarily all or only the common knowledge of a semantic community. Ed argues that "'set is immutable' by definition". I don't see anything like that in the clause 8.7 definition of "set". It seems to me that the set of books available for sale does vary over time -- that is, over possible worlds. That is, the extension of 'books available for sale' may be a different set in a different possible world. What varies over time is /which/ set of books plays the role 'extension' of the concept 'books available for sale'. English confuses us; that is why we formalize. In any given world, the set of books is fixed and "completely known", but as that world evolves to new possible worlds, the set certainly changes. Being careful, this is a version of the 'concept nominalization' problem. What is actually meant by "the set changes"? If the Chair of the Date/Time FTF changes, does Mark change? No. What changes is who plays the role. Similarly, what changes over time here is which set of books plays the role, not which books constituted the original set. Thus, in my view and answering a question raised by Don, "set is completely known" has no special alethic implications. Well, we should try not to go there. The issue is that 'Person knows proposition' doesn't make the proposition a fact. There is no such inferencing rule in FOLs. Only in an alethic logic is there an inferencing rule of the form: From _person_ knows _proposition_, to infer _proposition_ is true. But here we are not clearly talking about propositions. 'person knows set' means 'person' can enumerate the elements of 'set'. (I think.) MHL>> I inserted a few more responses below, like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/11/2011 02:22 PM Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept ------------------------------------------------------------------------ Mark H Linehan wrote: > I have several comments about this: > > 1) I think issue 13138 has nothing to do with the "state of affairs" > issues and should be handled entirely as a separate thread. Whether > it can be resolved within the next 3 weeks, I don't know. I concur on both counts. The issue of whether a body of information is complete has nothing whatever to do with states of affairs. The idea that a body of information is complete seems to be a concept that SBVR didn't really have. Mark and I are among those who believed that a 'conceptual schema' was something other/more than an IT packaging idea. The problem for SBVR is that it was doing double duty. And that is what makes resolving Issue 13138 really problematic -- we need to sort out the idea of 'closure of a body of information' from the idea of a body of SBVR exchange elements. > 2) I agree with Ron that there is both a "meaning" and a > "representation" side of this "closed world" issue. I think we need > to resolve the "meaning" side of it as part of 13138, otherwise we'll > lose the "closed world" capability. I think the representation aspect > (i.e. "records") can be addressed separately. I agree in part. I argue, however, that a 'complete body of information' is the content of a repository, and what is being said is that some repository of expressions holds the entire body. The whole idea of a body of information is that it is a package that is somehow accessible as a package. And the same is true of a body of shared meanings and a body of shared guidance. We can separate the content from the container, but we are implying that there is a container, or an identifiable collection of containers, that contains the body. One of the serious shortcomings of SBVR is that it provides no practical approach to terminology exchange, because it doesn't have exchange concepts for meaningful containers. > 3) For the meaning aspect, I suggest a new characteristic of "set": > "_set _/is completely known/" defined as: "each _element _/of /the > _set _is known to the _semantic community_ that /shares an > understanding of/ the _set_". I would argue that this approach is a bit misguided. A set is a 'res', not a 'meaning', so I don't know how one can 'share understanding of it'. MHL>> "Set" is a concept that defines a kind of "res". One can certainly share an understanding of MHL>> of a set independent of the elements of the set. EJB: No. I stand by what I said. Each instance of the concept 'set' is a res. I don't know what it means to 'understand a res'. One understands the 'intension' of a set, that is, one understands the concept of which the set is the extension. One understands the concept that defines the membership rule. And one thus 'understands the set' as the set of things that satisfy that rule. This is really foundational stuff. 'set' has a very narrow meaning in the SBVR context, while English usage commonly confuses the set -- the things -- with the intension -- the concept that defines the set by an admissibility rule for each thing. And every set is by definition 'complete' -- it is a collection of specific things, and no others. The intensional description of a set -- the rule for membership -- is a 'concept', not a 'set'. The set is the extension of that concept. A "set that is not completely known" is a concept whose extension is not (completely) known. MHL>> Yes. My point is that a set can be "complete" but not "completely known". And a set is an MHL>> "extension" only in the context of a concept. You can implicitly refer to a set using a definite description MHL>> (e.g. "the books on the shelves") without explicitly conceptualizing it. That is the problem. "the books on the shelves" is the definition of a concept. Any given book is either on one of the shelves and thus in the set of interest, or it is not on one of the shelves and is not in the set of interest. If Treasure Island, Kidnapped, and Ivanhoe are on the shelves, and Jane Eyre is on the table, then the set {Treasure Island, Kidnapped, Ivanhoe} is the extension of the concept. If someone picks up the Jane Eyre book and puts it on the shelf, the set {Treasure Island, Kidnapped, Ivanhoe} does not change, but it is no longer the extension of "the books on the shelves". The extension is now the set {Treasure Island, Kidnapped, Ivanhoe, Jane Eyre}, which is a different set. In a similar way, if the number of apples on my desk is 3, and I eat one apple, 3 does not become 2; rather the number that is the instance of the concept "number of apples on my desk" becomes 2, a different number. The issue is, as clause 8 currently says, whether a 'concept is closed' -- whether the set that is its extension is extensionally defined in some 'resource'. As Don points out, we know how to define a concept extensionally -- one big OR of the 'individual concepts'. But that assumes that the 'resource' that defines the extension is an extensional definition per se. (We don't have a similar fact type for sets, because SBVR doesn't think things have designations, there is no corresponding grammatical construct in SBVR SE, and no part of SBVR provides a means of exchanging a structure that is a 'list' of specific things, even though that is a common business concept.) MHL>> This is a problem that we ran into in the Date-Time effort. Further, it assumes that the extension of the concept is not only 'known', but also 'constant'; it doesn't change over time. In many other cases, the resource is something like a database table, in which each row represents an instance, and the whole set of rows -- the table itself -- which in SBVR is a 'fact model'. In such cases, the extension of the concept, at the time of any business decision, is "completely known" and captured in that resource. That is what I meant by a 'record'. MHL>> Regarding whether SBVR thinks the extension of a concept is "known" -- SBVR is clearly "open world" MHL>> by default, meaning that the extension of a concept is not necessarily known. MHL>> Regarding whether SBVR thinks the extension of a concept is "constant" -- my reading of clause 10 is that MHL>> as one "fact model" evolves to another "fact model", the "fact population" does change. In other words, MHL>> concepts may have different extensions in different "fact models". This is all true and mostly irrelevant. Don suggested that SBVR can define a concept extensionally, e.g., "boy in the band" as "John or Paul or George or Ringo". The set that is the extension of that concept is not only closed; it is constant. "boy in the band" cannot correspond to any other person in any possible world. By comparison, I can define a concept "boy in the band" and state in the fact model for a possible world: John is a boy in the band. Ringo is a boy in the band. Paul is a boy in the band. The concept 'boy in the band' is closed in this fact model. That means that in this possible world, the set of boys in the band is John, Paul and Ringo, and no others. It is not the case that there may be some other person who is a boy in the band but did not get explicitly mentioned in the fact model. The meaning of 'is closed in this fact model' is that the open world assumption does not apply to the concept 'boy in the band'. But unlike the constant definition, this formulation does not preclude another possible world in which George or Linda or Yoko is also a boy in the band. The fact model for this other world then contains: Linda is a boy in the band. George is a boy in the band. in addition to the facts above. So this other possible world also states that the concept 'boy in the band' is closed in it. It only means that this possible world does not include any boys in the band that were not explicitly mentioned in its fact model. In this world, the set of boys in the band is {John, Paul, Ringo, Linda, George}. Yoko cannot be a boy in the band in this world, but she might be a boy in the band in some other possible world. This is the case for employees. The fact model for a given world identifies each employee and is "complete" in the sense that 'employee' is closed in that model. There are no persons who are 'employees' that are not explicitly mentioned in the fact model. The fact model that describes the world of two weeks later may well identify a somewhat different set of persons as employees, but it can still be 'closed'. No one defines the concept 'employee' "extensionally", by listing all the current ones. If you do, you have to change the definition of the concept 'employee' every time the staff changes. Upon reflection, I think 'fact model' should mean 'body of information', and we want 'concept is closed in fact model'. A 'fact model' is not an XML data set that conforms to an SBVR schema. That is just one form of 'resource'/'repository' that is a container of a fact model. Every fact model is contained in some 'resource' or set of such 'resources'. A fact model that is to be identified as specifically defining the extent of some concept (by such a closure rule) must have a name or designation, and that designation may be different from the designation for the container itself (which may be an IT object or a file cabinet). MHL>> This view focusses on the WHERE. I think for business purposes, it is more helpful to focus on the WHO. I disagree. But as long as we support both, we can all be happy. I think my concept 'record' is the expression of a 'fact model' within some 'resource'. And I think 'communication content' is the expression of a 'fact model' (i.e., body of information), or perhaps a role of that expression with respect to some 'resource', such as a document, a database, or a message. _ _ > > > * Redoing the existing example in 8.5 in the Note under "concept > is closed in conceptual schema": both EU-Rent and a corporate customer > of EU-Rent might adopt EU-Rent''s "rental" concept. Only the EU-Rent > semantic community would state as a fact "the _extension _/of /_rental > _/is completely known/" to indicate that EU-Rent knows all its rentals. The idea: 'extension of _concept_ is completely known', as distinct from '_set_ is completely known', is useful. But, that it is completely known to unidentified parties is not useful in business. The useful fact type must be binary: we need to know WHO knows, or WHERE it is captured. So there may be two such fact types: 'extension of _concept_ is known by _party_' and 'extension of _concept_ is specified in _record_'. SBVR itself never introduces 'party' (or SUMO 'legal entity', or anything the like); so that makes it difficult to express the WHO version. I proposed 'record' to address the WHERE. MHL>>This is why I used the concept "semantic community" for what Ed calls "party". Well, not quite. Mark assumed a specific semantic community, which he proposes to identify by a definite description within the definition of 'set is completely known'. I was thinking of '_set_ is completely known by _party_'. For business purposes, is '_set_ is completely known by _semantic community_' a satisfactory substitute? Color me doubtful. > The corporate customer would not state this fact so would operate on > the usual "open world" assumption. In point of fact, the corporate customer doesn't care about other EU Rent rentals; they are not likely to be things in its world of interest. So its concept 'rental' would have a different extension. It may still be true that it is treated as 'open'. > * Consider an order that has multiple line items. The fact "the > extension of 'order has line item' is completely known" means that the > semantic community that states this fact knows all the actualities of > "order has line item". This is actually a bit trickier. Knowing all the actualities of 'order has line item' requires some resource/party to know all of the orders, and all of the line items in each. One would expect, of course, that an 'orders database' would have all that. So the fact type 'customer order has line item' is closed in the 'customer orders data' (fact model) which is captured as a set of tables (the record) in the Sales Database (repository). But the signed contract that documents a specific 'order' explicitly documents all of the line items for that order -- it is a closed 'record' of the line items of that order only. > Responding to Ron's comments: > > * "set" is an existing SBVR concept that is similar to "aggregation" > * I did not address "set is immutable" because I think it is outside > the scope of 13138. The more general concept is 'collection'; 'aggregation' has several meanings of which 'set' is not a specialization. And 'set is immutable' by definition. A 'set' is a specific enumeration of things, and no others. If you add one, or take one out, you get a different 'set' -- a distinguishably different instance of the concept 'set'. > Responding to Ed's comments: > > * I don't think the distinction between "is complete" and "is > authoritative" is worth the additional complexity of having two > characteristics rather than one. I agree. I think 'is authoritative' is an inappropriate addition. Business rules determine what is authoritative for what purposes, and the 'characteristic' alone may not actually characterize anything. We do best by not going there. -Ed > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Wed, 12 Oct 2011 19:30:55 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Donald Chapin CC: sbvr-rtf Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9CNV0qo012736 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1319067062.07464@VOSKIa/SxvhUNTHwyZup4w X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Donald Chapin wrote: Attached is an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback from Mark, Ed and Don. Not that it matters really, but these are my comments on the draft of 12 Oct Change 2. extension is completely known This is very strange. 'extension' is a role of set, but a set can be the extension of any number of concepts. What is intended here is either '_set_ /is completely known/' or '//_concept_ /has completely known extension/'. That is, the intent is that an instance of type 'set' will be identified by a definite description as the extension of a specific concept. So either, 'set' is the range of the subject, or 'concept' is the range of the subject and the reference to its extension is part of the verb phrase. That said, for the reasons I put forth in my email to Mark, I don't think that the given definition is of any use to business. One possible interpretation is that if you are part of the semantic community that uses the concept, you must know what its extension is. If you don't know the extension, you shouldn't be using the term. An alternative interpretation is that the community as a whole knows all the elements of the set, but there may be no individual who does. If you want to know all the members of the set, you may have to ask all the members of the community. The only version of this fact type that is useful to business is a binary fact type that identifies a 'party' (person or organization) as a source of the information as to what all the elements of the set are. And it has nothing to do with replacing 'concept is closed in fact model', which says that the fact model -- a specific resource -- specifies all the elements of the extension. There is no relationship between 'resource specifies extension' and 'community knows extension'. (Note: I don't care one way or the other if you keep or toss 'record', but I sure don't think it will help business or the acceptance of SBVR to create 'community knows extension' and try somehow to use it as a substitute.) Change 3. use of conceptual schema and fact model in conformance This is totally inappropriate. This would be the first time that any concept defined in clause 10 is explicitly used as an SBVR construct, and of all things, what is said to be the logical foundation is used in specifying the physical representation of the SBVR concepts. Clause 10 is supposed to be the formal background for terms used in SBVR concept definitions that are not part of the SBVR concept set itself. There is nothing wrong with the unstyled use of those terms in clause 13. But conformance must be stated in terms of concepts that are part of the SBVR concept set or part of the 'exchange concept set' that is introduced in clauses 13 and 15. Further, the concept 'fact model' is defined (in 8.5) as "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations...)". This doesn't define 'fact model' to have any formal logic meaning at all. It is just some set of propositions that are true in the possible world. In formal logic, one talks about 'theories' and 'postulates'. A possible world is postulated by a set of 'postulates' (facts). Everything we can know about that world is based on the applicable theory (the conceptual schema?) and the set of postulates. 'Postulate' is a role of 'fact' that is an a priori assertion that is part of characterizing the possible world before inferencing. So, is a fact model the set of postulates that characterizes a possible world? Or just a bag of propositions that are assumed to be true in some unidentified possible world, possibly along with others that may come from another source? Does the set of facts identify the world, so that a larger set of non-redundant facts identifies a different world? The useful formal logic concept is 'the set of postulates (facts) that characterizes a possible world'. My impression is that SBVR treats 'fact model' as a bag of propositions that are taken to be true, and that is not a formal logic notion. If that is the case, it is purely a clause 13 idea -- it is just a packaging concept, and the clause 10 concept is 'possible world'. (BTW, this problem is not new with SBVR. UML had the same problem until the idea 'model' was introduced in UMLv2.) -Ed "I call that 'slop', the first big step on the road to the depths of degredation" (followed by a sequence of non sequiturs) - Meredith Wilson, "Trouble", from "The Music Man" -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Yahoo-Newman-Id: 271242.61748.bm@omp1014.access.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1318469224; bh=TCypPMD8QxIz2xHuXlpus0c7kjqK4z83gObqcrFSs6c=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:Content-Transfer-Encoding; b=Iay4GPhaK9adtVCxqyoYxEAcaSt69JVBqnAoKq4nE8YWPqI+Cg7aaSnrruHkEMrToG62LPzlAeWHQLGkABKF6xgKPk3B7LwyENZz9K0ygbQTA4zPSaPQIK6OptUmF/HkhC77t32UZgel5FEtZPctosu+Tlh6PLPGpCtqHw13A6Y= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GSYiJjIVM1msaMjF6VBJjGoz4rGFpmpesr_rOOX9Hs90biZ ug5oEeMD8LjVhY_sPn2wgHcKNgjzYjwE6RhXDFCpkeBHmVSCz6QIVM9crdf_ TWyqyfOTYVjIEjD9gyjYBfcJVE7HPEFX.G_9Wd1VttzcCgog_HhiMT92hTC7 ymk6Y6E9tNxneswfuLQb9ucjnPnEqneC0ooCnUwp6.AnpsvwlRg25RiRHF5B OMb.eGyh3hnQviV_Ap64H1jpcHZ4A.MWtaKsavQzZgP0p3HC4ZX8VWSrU5W4 rAt37ssHCs51O05EEHnueuXXQAVLJEUsGAuVqlz.W47HGij2I8ddD5scXaH_ GNs3L54VAiNmHV1eFoCAp3MURUAAhNPd87CpW.RjCbs4ZhXlp9.ERNSmXCnG wSjOR74qzia4PUu1U_0oQ.JIcfJjWmp6NHtZGb8qKFuhH1RVYK4qAmLI238h 9HJjroNEVb_rYyoyb52zl9ZDIAKWA.9MHzolSyS1OXYuP3R7ZUoI63GGDOXt Qto8ALTK1z9j5O0vbM_8.m6j8g9dM7y0qQa3NryXjetBI3jjUaAnDg1EpSGe 73pNZG.wc8XMSjbIGn5dg8J9lqAb6nNjJbT4riGILf6NWECpZGrJuM7WIVK0 CkZ_l5_ZS0iwu6rb2Dk0jeWAkk_0aI2TnQYUQ_1o9 X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Oct 2011 20:26:55 -0500 To: edbark@nist.gov, Donald Chapin From: "Ronald G. Ross" Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Cc: sbvr-rtf My 2 cents, below like this ... At 06:30 PM 10/12/2011, Ed Barkmeyer wrote: Donald Chapin wrote: Attached is an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback from Mark, Ed and Don. Not that it matters really, but these are my comments on the draft of 12 Oct Change 2. extension is completely known This is very strange. 'extension' is a role of set, but a set can be the extension of any number of concepts. What is intended here is either '_set_ /is completely known/' or '//_concept_ /has completely known extension/'. That is, the intent is that an instance of type 'set' will be identified by a definite description as the extension of a specific concept. So either, 'set' is the range of the subject, or 'concept' is the range of the subject and the reference to its extension is part of the verb phrase. That said, for the reasons I put forth in my email to Mark, I don't think that the given definition is of any use to business. One possible interpretation is that if you are part of the semantic community that uses the concept, you must know what its extension is. If you don't know the extension, you shouldn't be using the term. An alternative interpretation is that the community as a whole knows all the elements of the set, but there may be no individual who does. If you want to know all the members of the set, you may have to ask all the members of the community. The only version of this fact type that is useful to business is a binary fact type that identifies a 'party' (person or organization) as a source of the information as to what all the elements of the set are. And it has nothing to do with replacing 'concept is closed in fact model', which says that the fact model -- a specific resource -- specifies all the elements of the extension. There is no relationship between 'resource specifies extension' and 'community knows extension'. (Note: I don't care one way or the other if you keep or toss 'record', but I sure don't think it will help business or the acceptance of SBVR to create 'community knows extension' and try somehow to use it as a substitute.) Either I am completely confused (very possible), or I agree with Ed, or I'm completely confused *and* I agree with Ed. There are some other possibilities, but not worth going into here. * The only thing that is of any real-world value here is whether something is completely *specified*. How would you ever *know* that all the knowable thingees of some kind are known? ... "We know that we know what they all are ... and we're very sure about that ... even though we don't know for sure who knows which ... and of course, we've never asked about it, or recorded them, because you'd have to use words or signs to do that." To me this is looking down a rabbit hole(!). * What's useful for business purposes is to say that all the knowable thingees of some kind **have been specified". Some specified list(s) of them is/are complete. What kinds of thingees could those be? * The obvious kind is general concepts. * But business people want to have assurance that other things have been specified completely and are trustworthy in that respect. (This is partly a CYA thing.) For example, Mark wants the IBM personnel directory to be trustworthy as 'complete'. That's an example of Ed's 'record'. * Ron would want any rulebook to be specified completely (not necessarily published and distributed that way). * I suspect Donald would want any terminological dictionary to be specified completely (ditto). * What are examples of "record", "rulebook" and "terminological dictionary" respectively? Not employees, rules, or terms, but records, rulebooks and terminological dictionaries. * And in all three cases they are more than sets or lists. They are *aggregations* ... or if you prefer, *aggregate specifications*. Change 3. use of conceptual schema and fact model in conformance This is totally inappropriate. I agree entirely ... but, not understanding Ed's justification entirely, I'll have to object on other grounds. SBVR is "Semantics of Business Vocabulary and Business Rules". (Stop me if I make a mistake here.) So the 'units' of inter-operability should be things recognizable as ... uh ... business vocabulary and business rules. "Conceptual schema" and "fact model" are unrecognizable in that regard. How about ... let's see ... something having to do with terminological dictionaries or rulebooks? O.K., our ambition is to support some additional forms of semantic communication ... so maybe some more general concept like .... uh .... business communication. The serious point here is ... Let's refocus on the *business purpose* of SBVR. That's ultimately the key to its acceptance (and elegance). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Having said all that, two things are obvious: 1. None of this has anything to do with states of affairs, which we agreed would be the focus of 1.1. 2. We are not going to resolve al this in time for 1.1. **So why the heck are we still talking about it??** This would be the first time that any concept defined in clause 10 is explicitly used as an SBVR construct, and of all things, what is said to be the logical foundation is used in specifying the physical representation of the SBVR concepts. Clause 10 is supposed to be the formal background for terms used in SBVR concept definitions that are not part of the SBVR concept set itself. There is nothing wrong with the unstyled use of those terms in clause 13. But conformance must be stated in terms of concepts that are part of the SBVR concept set or part of the 'exchange concept set' that is introduced in clauses 13 and 15. Further, the concept 'fact model' is defined (in 8.5) as "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations...)". This doesn't define 'fact model' to have any formal logic meaning at all. It is just some set of propositions that are true in the possible world. In formal logic, one talks about 'theories' and 'postulates'. A possible world is postulated by a set of 'postulates' (facts). Everything we can know about that world is based on the applicable theory (the conceptual schema?) and the set of postulates. 'Postulate' is a role of 'fact' that is an a priori assertion that is part of characterizing the possible world before inferencing. So, is a fact model the set of postulates that characterizes a possible world? Or just a bag of propositions that are assumed to be true in some unidentified possible world, possibly along with others that may come from another source? Does the set of facts identify the world, so that a larger set of non-redundant facts identifies a different world? The useful formal logic concept is 'the set of postulates (facts) that characterizes a possible world'. My impression is that SBVR treats 'fact model' as a bag of propositions that are taken to be true, and that is not a formal logic notion. If that is the case, it is purely a clause 13 idea -- it is just a packaging concept, and the clause 10 concept is 'possible world'. (BTW, this problem is not new with SBVR. UML had the same problem until the idea 'model' was introduced in UMLv2.) -Ed "I call that 'slop', the first big step on the road to the depths of degredation" (followed by a sequence of non sequiturs) - Meredith Wilson, "Trouble", from "The Music Man" -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-12_08:2011-10-12,2011-10-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110120345 Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution From: keri Date: Wed, 12 Oct 2011 19:04:44 -0700 Cc: edbark@nist.gov, Donald Chapin , sbvr-rtf To: "Ronald G. Ross" X-Mailer: Apple Mail (2.1084) Adding a cent to Ron's two... On Oct 12, 2011, at 6:26 PM, Ronald G. Ross wrote: My 2 cents, below like this ... ... Having said all that, two things are obvious: 1. None of this has anything to do with states of affairs, which we agreed would be the focus of 1.1. 2. We are not going to resolve al this in time for 1.1. **So why the heck are we still talking about it??** Indeed. After last week's roundtable I asked that very question. The answer, it seems, is that is is part of the "move stuff out of Clause 8.x and into Clause 10" initiative. If that is the case then the larger question is: Is that package (moving things from 8 to 10) to be part of our 1.1 focus? Let's ask/answer that in Friday's (re)confirmation of 1.1 scope, please. ~ Keri X-Yahoo-Newman-Id: 611844.55043.bm@omp1010.access.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1318478042; bh=2SgIXFbox0DKbS6I1yEKKGRU9peZhp2zXQiuEslruoE=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type; b=rEBmecXEcbN4DIECze0EWC1GmzOhpoJHwXA6yAcLXzKP+O0BpcszDKwGFDTPym54ll+wl8apHl9g4acPoMRbiJK8bv7/UCsgqCtN4Y4anBVti579h6/6kgU4fE7tHjkyxsi0OM0IIGs21ATgaxtgfIEdTI2vkeDA9Rjqv4uEC98= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aHmFF_AVM1mPWvZNdhpxuVMFD7CMLDoScK6rbQrpV4KrMgz crOCqcKGDJaffm.BPbeq6T7FFoy6sBTs1mRFaQNw2jW_Dxl6i1dZZ9nv5c4Q UIXfKLzWmXSHZ.genQXqTvzbgTs62M9t6tPMBVCcImIj9uX0E0uliF0zFteJ x3Uy5a1OmIpVlXjA2RwL6y8GuY_49WxRDWQuUJVcetBURB6SzJCh9YxCKE9r 5CnF59FAQhK6HQdbkhOdFO5R5f_eG_9mXgjDJnaOClDlM4729i8ZF8e0kdv_ JvP.2I9ibZ1HizKOjf2iuP6xobPF9DRFE7jd4FKyqo8mc8Bg9H1wuky5.2.v 5rT5v_E5ovO3Q7.eVrmn7z8hMOKCvUA8JHujRIjl5GHN9hr6aHauKxD3lRo6 _512Zzs5.xil7ghgPmxv7vt4q6OPafQRURlI4ND_0lFr1mSEfzk0bY3fziOk g3d_uOSs0pONkUjTT5GjUXer8jaAB3yjB0xFfqs4fBsekpQdM.qRpcBXCSDi 7wsuwMo6dJe_fJDrf8D5dhMopchJDQMwnPEMKR0B5zzTgpCUTJneAXfBdfvZ VG67YLehE4uXW1r2dGMWMWm7vlMHoSqe8orSaRjU7pFc67kvSfXKtzv5uOGt 9wBXe3bTfr8cQ_go85WwriWC8tMx66mOEz_FkADiF3eiH6jidXPijolFCwnw 2XUmgvz_l4v.94kKCCQ-- X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Oct 2011 22:53:02 -0500 To: edbark@nist.gov, Donald Chapin From: "Ronald G. Ross" Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Cc: sbvr-rtf All, Off-line I was told politely to put up or shut up about my response below, and several other I've written recently. Unless you read the below and the others first, the attached may not make much sense. It's very rough. It proposes a new section for Clause 11. So best to look at the responses first. Even though I have spent this evening working on this (I didn't want to lose the thoughts), I stick with my bottom line below: 1. None of this has anything to do with states of affairs, which we agreed would be the focus of 1.1. 2. We are not going to resolve all this in time for 1.1. **So why the heck are we still talking about it??** Ron At 08:26 PM 10/12/2011, Ronald G. Ross wrote: My 2 cents, below like this ... At 06:30 PM 10/12/2011, Ed Barkmeyer wrote: Donald Chapin wrote: Attached is an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback from Mark, Ed and Don. Not that it matters really, but these are my comments on the draft of 12 Oct Change 2. extension is completely known This is very strange. 'extension' is a role of set, but a set can be the extension of any number of concepts. What is intended here is either '_set_ /is completely known/' or '//_concept_ /has completely known extension/'. That is, the intent is that an instance of type 'set' will be identified by a definite description as the extension of a specific concept. So either, 'set' is the range of the subject, or 'concept' is the range of the subject and the reference to its extension is part of the verb phrase. That said, for the reasons I put forth in my email to Mark, I don't think that the given definition is of any use to business. One possible interpretation is that if you are part of the semantic community that uses the concept, you must know what its extension is. If you don't know the extension, you shouldn't be using the term. An alternative interpretation is that the community as a whole knows all the elements of the set, but there may be no individual who does. If you want to know all the members of the set, you may have to ask all the members of the community. The only version of this fact type that is useful to business is a binary fact type that identifies a 'party' (person or organization) as a source of the information as to what all the elements of the set are. And it has nothing to do with replacing 'concept is closed in fact model', which says that the fact model -- a specific resource -- specifies all the elements of the extension. There is no relationship between 'resource specifies extension' and 'community knows extension'. (Note: I don't care one way or the other if you keep or toss 'record', but I sure don't think it will help business or the acceptance of SBVR to create 'community knows extension' and try somehow to use it as a substitute.) Either I am completely confused (very possible), or I agree with Ed, or I'm completely confused *and* I agree with Ed. There are some other possibilities, but not worth going into here. * The only thing that is of any real-world value here is whether something is completely *specified*. How would you ever *know* that all the knowable thingees of some kind are known? ... "We know that we know what they all are ... and we're very sure about that ... even though we don't know for sure who knows which ... and of course, we've never asked about it, or recorded them, because you'd have to use words or signs to do that." To me this is looking down a rabbit hole(!). * What's useful for business purposes is to say that all the knowable thingees of some kind **have been specified". Some specified list(s) of them is/are complete. What kinds of thingees could those be? * The obvious kind is general concepts. * But business people want to have assurance that other things have been specified completely and are trustworthy in that respect. (This is partly a CYA thing.) For example, Mark wants the IBM personnel directory to be trustworthy as 'complete'. That's an example of Ed's 'record'. * Ron would want any rulebook to be specified completely (not necessarily published and distributed that way). * I suspect Donald would want any terminological dictionary to be specified completely (ditto). * What are examples of "record", "rulebook" and "terminological dictionary" respectively? Not employees, rules, or terms, but records, rulebooks and terminological dictionaries. * And in all three cases they are more than sets or lists. They are *aggregations* ... or if you prefer, *aggregate specifications*. Change 3. use of conceptual schema and fact model in conformance This is totally inappropriate. I agree entirely ... but, not understanding Ed's justification entirely, I'll have to object on other grounds. SBVR is "Semantics of Business Vocabulary and Business Rules". (Stop me if I make a mistake here.) So the 'units' of inter-operability should be things recognizable as ... uh ... business vocabulary and business rules. "Conceptual schema" and "fact model" are unrecognizable in that regard. How about ... let's see ... something having to do with terminological dictionaries or rulebooks? O.K., our ambition is to support some additional forms of semantic communication ... so maybe some more general concept like .... uh .... business communication. The serious point here is ... Let's refocus on the *business purpose* of SBVR. That's ultimately the key to its acceptance (and elegance). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Having said all that, two things are obvious: 1. None of this has anything to do with states of affairs, which we agreed would be the focus of 1.1. 2. We are not going to resolve al this in time for 1.1. **So why the heck are we still talking about it??** This would be the first time that any concept defined in clause 10 is explicitly used as an SBVR construct, and of all things, what is said to be the logical foundation is used in specifying the physical representation of the SBVR concepts. Clause 10 is supposed to be the formal background for terms used in SBVR concept definitions that are not part of the SBVR concept set itself. There is nothing wrong with the unstyled use of those terms in clause 13. But conformance must be stated in terms of concepts that are part of the SBVR concept set or part of the 'exchange concept set' that is introduced in clauses 13 and 15. Further, the concept 'fact model' is defined (in 8.5) as "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations...)". This doesn't define 'fact model' to have any formal logic meaning at all. It is just some set of propositions that are true in the possible world. In formal logic, one talks about 'theories' and 'postulates'. A possible world is postulated by a set of 'postulates' (facts). Everything we can know about that world is based on the applicable theory (the conceptual schema?) and the set of postulates. 'Postulate' is a role of 'fact' that is an a priori assertion that is part of characterizing the possible world before inferencing. So, is a fact model the set of postulates that characterizes a possible world? Or just a bag of propositions that are assumed to be true in some unidentified possible world, possibly along with others that may come from another source? Does the set of facts identify the world, so that a larger set of non-redundant facts identifies a different world? The useful formal logic concept is 'the set of postulates (facts) that characterizes a possible world'. My impression is that SBVR treats 'fact model' as a bag of propositions that are taken to be true, and that is not a formal logic notion. If that is the case, it is purely a clause 13 idea -- it is just a packaging concept, and the clause 10 concept is 'possible world'. (BTW, this problem is not new with SBVR. UML had the same problem until the idea 'model' was introduced in UMLv2.) -Ed "I call that 'slop', the first big step on the road to the depths of degredation" (followed by a sequence of non sequiturs) - Meredith Wilson, "Trouble", from "The Music Man" -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Aggregations + Containers + Closed + Record v1.doc 11.x.x. Aggregations of Meanings and Representations Aggregation of representations is the unit of interoperability for SBVR. [Note: .Aggregation. should be used in place of .container. in SBVR discussions.] 11.x.x.1 Aggregations aggregation of meanings Definition: an assemblage of meanings Dictionary Basis: MWUD 2 : a group, body, or mass composed of many distinct parts : ASSEMBLAGE aggregation of representations Definition: an assemblage of representations Dictionary Basis: MWUD 2 : a group, body, or mass composed of many distinct parts : ASSEMBLAGE Note: An aggregation of representations is sometimes, but not always, based on a partial or complete list of the members of some particular set, often but not always with expression of additional facts. aggregation of representations is specified completely Definition: the aggregation of representations officially identifies every member of a set Note: Any thing that is not explicitly identified in the aggregation of representations can be assumed not to be a member. Note: Since SBVR assumes an open world, in cases where the company thinks it can close some set, it needs to make special allowance for people to act presuming as much. aggregation of representations is authoritative until date-time Note: There will be no sanction during the time period for people acting as if it were authoritative. Note: Date-time gives .shelf life.. Example (from Ed): The product catalog for 2012 may be issued in December and remain as the authoritative specification for a year. aggregation of representations is immutable Note: A snapshot of facts (and rules) at a point in time is highly desirable for compliance, legal protection, traceability and other purposes. 11.x.x.2 Aggregations of Meanings body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community [Second More General Concept: aggregation of meanings] 11.x.x.3 Aggregations of Representations specification of extension Definition: the set of representations for the extension of a concept [Second More General Concept: aggregation of representations] terminological dictionary Definition: collection aggregation of representations including at least one designation or definition of each of a set of concepts from one or more specific subject fields, together with other representations of facts related to those concepts Source: based on ISO 1087-1 English (3.7.1) [.terminological dictionary.] Reference Scheme: a URI of the terminological dictionary rulebook Definition: the set aggregation of representations determined by a given speech community to represent in its language all meanings in its body of shared meanings Synonym: representation set Reference Scheme: the speech community that determines the rulebook record Definition: an aggregation of representations whose primary purpose is to document or report fact(s) Dictionary Basis: MWUD 2b(3): a body of known, recorded, or available facts about something : the sum of something done or achieved or the body of data known, recorded, or available about something Examples (from Ed): the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list instrument Definition: an aggregation of representations whose primary purpose is to document or report an official business accord or action Dictionary Basis: MWUD 5a : a legal document (as a deed, will, bond, lease, agreement, mortgage, note, power of attorney, ticket on carrier, bill of lading, insurance policy, warrant, writ) evidencing legal rights or duties especially of one party to another b : something capable of being presented as evidence to a court for inspection c : an act recorded in writing by a notary : a notarial act Examples: contracts, agreements, MOUs, deals, certifications, warranties, etc. From: "Donald Chapin" To: "'Ronald G. Ross'" , Subject: RE: [containers and bigger problems] RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Date: Thu, 13 Oct 2011 09:49:46 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDjDZT3ixhxN3T1Dk0ZiN4CsibJRgJXnCFnAS3rcwADLx7SCAHw7QmSAfgSB2kBptLzdgJ0T7TtAlRd6xCWxIT50A== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E96A62B.00E6, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.13.72714:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, LINK_TO_IMAGE, INFO_TLD, __CP_URI_IN_BODY, __CP_MEDIA_2_BODY, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4E96A62E.0225,ss=1,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 Ron, The resolution of the Issues you listed below depends on the resolution of Issue 13138. I included Issues 12540/41 (which were submitted as one Issue) in the list of seven critical issues Keri recently requested. So there is agreement that there are important. Donald From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: 12 October 2011 21:25 To: sbvr-rtf@omg.org Subject: [containers and bigger problems] RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution All, [The important part is at the bottom.] For some time we have been using the word "container" as a catch-all term to talk about various things in SBVR, including (as I understand): * body of shared meanings * body of shared concepts * body of shared guidance * vocabulary * business vocabulary * terminological dictionary * rulebook * conceptual schema * fact model "Container" is a misleading term. MWUD defines "container" as: "one that contains: as (a): a receptacle (as a box or jar) or a formed or flexible covering for the packing or shipment of articles, goods, or commodities". MWUD gives conflicting definitions for "contain", includng: 2a: to have within : HOLD *the box contained only some old papers and a few odds and ends* 2b: to consist of wholly or in part : COMPRISE, INCLUDE *the bill contains several new clauses* 2c: ENCLOSE *the building contains classrooms and an auditorium*". The term we should be using is "aggregation". This is the closest business term that fits things of this nature. (See my issue 19523.) Here is the relevant MWUD definition: 2: a group, body, or mass composed of many distinct parts : ASSEMBLAGE. Yes, it's Ron being Ron, but we should call things by the closest real-world terms wherever possible. Mark has had outstanding issues (e.g., 12540, 12541, 12542, 15151) pending since 2008 about how these aggregations (my word) relate to each other and how they should be used by tools. I have also raised various related issues. But the problem is even more fundamental. Ed made the following comment in a recent e-mail which has really stuck with my like a burr under a saddle: "For the record, this is why SBVR is useless for the exchange of 'vocabularies'. There is no agreement on which of these collections a business vocabulary management tool should exchange. Compare with SKOS, which has one structure with some (not many) content options. The consequence of supporting every special nuance is defeating interoperability. We would suggest that SBVR needs terminological dictionary, rulebook and fact model, and the rest are academic." This is *very* discouraging ... and I don't think I'm speaking just for Ed and myself. I want some resolution and progress NOW on these issues. How can we resolve them for 1.1? First let me say that I am appalled by the lack of thought given to presentation, organization and explanation in Clauses 8, 9, and 11. (Yes, again Ron being Ron, but it is inexcusably naive to think that good idea sell themselves just because they are good.) Can we create a new section in Clause 11 and put at least the specific aggregations SBVR is meant to exchange in it (and say so clearly) and work out how they relate? Three years is too long for issues like these to sit on the table. WE DON'T HAVE FOREVER. Ron Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info From: "Donald Chapin" To: Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) Date: Thu, 13 Oct 2011 13:35:03 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyJpIfL5AD7elW+T8aVXGuc5rwrDA== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E96DAF8.00E2, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2011.10.13.113020:17:8.317, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __FRAUD_CONTACT_NAME, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_90_100, HTML_95_100, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK, NO_URI_FOUND X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4E96DB92.000A,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 an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback. Draft Resolution for Issue 13138- 2011-10-13.doc From: "Donald Chapin" To: Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) Date: Thu, 13 Oct 2011 13:35:03 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyJpIfL5AD7elW+T8aVXGuc5rwrDA== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E96DAF8.00E2, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2011.10.13.113020:17:8.317, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __FRAUD_CONTACT_NAME, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_90_100, HTML_95_100, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK, NO_URI_FOUND X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4E96DB92.000A,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 an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback. Draft Resolution for Issue 13138- 2011-10-13.doc From: "Donald Chapin" To: Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) Date: Thu, 13 Oct 2011 13:35:03 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyJpIfL5AD7elW+T8aVXGuc5rwrDA== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E96DAF8.00E2, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2011.10.13.113020:17:8.317, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __FRAUD_CONTACT_NAME, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_90_100, HTML_95_100, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK, NO_URI_FOUND X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4E96DB92.000A,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 an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback. Draft Resolution for Issue 13138- 2011-10-13.doc Disposition: Resolved OMG Issue No: 13138 Title: Move fact model container concepts from Clause 8 to Clause 10 Source: Business Semantics Ltd, Donald Chapin, (Donald.Chapin@btinternet.com) Summary: In resolution of Issue 12540 (Clause 8 does not include the concepts needed to represent itself) it was recognized that subclause 8.5 defines containers that are not part of the SBVR metamodel, but are relevant to the formal semantics concepts in Clause 10. They would be more appropriately placed in Clause 10. Resolution: 1. Sub-clause 8.5 is, for all practical purposes, disconnected from the rest of Clauses 7, 8, 9, 11 & 12 in that the terms (i.e. conceptual schema, fact model) defined in Sub-clause 8.5 are hardly used at all in Clauses 7, 8, 9, 11 & 12, and none of those uses are styled. Conversely Clause 10.1.12 .Scope. and Clause 13 .SBVR.s Use of MOF and XMI. .SBVR Formal Grounding Model Interpretation. (as well as the non-normative Annex L: .A Conceptual Overview of SBVR and the NIAM2007 Procedure to Specify a Conceptual Schema.) makes high use of the terms defined Sub-clause 8.5. The vocabulary entries in Sub-clause 8.5 are moved to the context where they are used normatively i.e. in Clause 1013. 2. The .closed in fact model. concepts in clause 8.5 could be read to include a .business-oriented ability to specify the availability of knowledge about instances of SBVR concepts.. To preserve this function when Clause 8.5 is moved to Clause 10, add a characteristic to concept that specifies this. 3. Clarify that the uses of .conceptual schema. and .fact model. in Clause 2 .Conformance. refer to their use in Clause 13 .SBVR.s Use of MOF and XMI. as defined in Clause 10.1.2.113.7 4. Make clear that the uses of .conceptual schema. and .fact model. in Clause 13 .SBVR.s Use of MOF and XMI. are as defined in Sub-clause 10.1.2.113.7 5. Clarify that the Sub-clause 8.6.2 necessities are about the distinction between what is in the SBVR model and what is the Universe of Discourse of the SBVR Model. Revised Text: 1. Move Sub-clause 8.5 a. MOVE the entire Sub-clause 8.5 as is to Clause 10 13 as a new Sub-clause 10.1.2.113.7 .Conceptual Schemas and Models.. b. REMOVE all styling on all text within the entry headings and subentries in Sub-clause 13.7. b.c. REMOVE the .FL. markings on all the entries in Sub-clause 10.1.2.113.7 d. REMOVE the following example sentences from the Note under .concept is closed in conceptual schema. in Sub-clause 13.7 as it doesn.t make business sense. Ed Barkmeyer pointed out in one of his emails that the corporate customer has only its own rentals in its universe of discourse, .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 concept .rental. as not closed because the customer is not aware of all rentals, but EU-Rent.s conceptual schema has the concept as closed.. c.e. REMOVE the item .5. Conceptual Schemas and Models. from the list of subjects at the end of the introductory paragraphs of Clause 8 on printed page 18 2. ADD the following entry to Clause 11.1.1 directly after .semantic community shares understanding of concept.: extension concept ishas completely known extension Definition: each instance in the extension of the concept is known by the semantic community that shares the understanding of the concept Note: The means and source of .completely knowing. is outside the scope of SBVR. It could be knowledge that people have; it could be recorded information; and/or it could be direct observation. All that this characteristic asserts is that all the instances in the extension of the concept are completely known -- as in .taken to be true. or .believed to be a fact.. Errors in the recorded data or knowledge and observations of people are outside the scope of SBVR. Note: If this characteristic is not specified for a given concept, is it assumed to be .false. by default as per SBVR's normal 'open world' semantics. Note: Under SBVR's normal 'open world' semantics, there could be instances in the extension of the concept that exist but are unknown. "Concept is completely known" reverses the 'open world' assumption with respect to the concept. If a concept is completely known, then an existential quantification such as "if there does not exist an instance of the concept that " can be relied upon to conclusively determine that there is no instance that meets the given condition. Example: .is completely known. is specified as a metafact for the concept .rental. in the SBVR Terminological Dictionary contain it. Example: In EU-Rent, the extension of the concept .rental customer. is completely known, but the extension of the concept .person interested in discounted weekend rental rates. is not. Note: Often, different kinds of business process are needed for dealing with known populations and populations that are unknown or only partly-known. EU-Rent can recognize that a person is a rental customer, but has to find out more about a person in order to decide whether he/she is interested in discounted weekend rental rates. 3. Clarify that the uses of .conceptual schema. and .fact model. in Clause 2 a. ADD the following as the third paragraph immediately following the Clause 2 .Conformance. heading: .All references to .conceptual schema. and .fact model. in this clause are references to their use in Clause 13 .SBVR.s Use of MOF and XMI. as they are defined in Csubclause 10.1.2.113.7.. b. REPLACE the first paragraph in Sub-clause 2.3 .Conformance of an SBVR exchange document.: .An exchange document that conforms to this specification (an .SBVR exchange document.) shall be an XML document that represents a .fact model. as defined in subclause 8.5.. WITH .An exchange document that conforms to this specification (an .SBVR exchange document.) shall be an XML document that represents a .fact model. as used in Clause 13 .SBVR.s Use of MOF and XMI. and defined in subclause 10.1.2.113.7.. c. REPLACE at the end of paragraph 2 under .EXAMPLE. in Sub-clause 2.3: .(see 8.5). WITH .(see subclause 10.1.2.113.7). 4. ADD the following at the end of last introductory paragraph of Clause 13.1.2 .SBVR.s Use of MOF and XMI.: All references to .conceptual schema. and .fact model. in this clause are as defined in Clause subclause 10.1.2.113,7. 5. REPLACE the last two sentences in the introductory paragraph to Sub-clause 8.6.2 .Necessities Concerning Extension.: Other necessities stated in the context of the Meaning and Representation Vocabulary concern the contents of conceptual schemas and their representations. But the following necessities concern each fact model in relation to the conceptual schema that underlies it. WITH Other necessities stated in the context of the Meaning and Representation Vocabulary concern meanings and their representations. But the following necessities are about the correspondence of meanings to things in the universe of discourse. Disposition: Resolved To: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution X-KeepSent: A47B15A4:61643468-85257928:0047C34F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 13 Oct 2011 09:18:55 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/13/2011 09:18:56, Serialize complete at 10/13/2011 09:18:56 Comments: 1) Whether we call these things "aggregations" or "containers" or "collections" makes very little difference to me. But we already have the concept "set". Why not use that? 2) I would not want to see us add new "aggregation" concepts without cleaning up the confusion of existing ones. We should be trying to delete some of these. And probably we should be reusing/redefining existing signifiers. 3) I am particularly interested in applying the "completely known" idea to the extension of a concept: a way to say that a company "completely knows" all its employees. 4) I believe that it makes sense to talk about BOTH "aggregation of representations is specified completely" and the corresponding concept applied to meanings. You can "know" the complete extension of a concept without representing the instances. 5) Regarding the "authoritative until date-time" idea -- if you're going to do that, I suggest specifying it with both a "from" date and a "to" date. The product catalog for 2012 is not authoritative until January 1, 2012. 6) I think "aggregation of representations is immutable" is not what you want for a "snapshot in time". Suggest "aggregation of representations as of date-time" -- that is, a basic versioning concept. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Ronald G. Ross" To: edbark@nist.gov, Donald Chapin Cc: sbvr-rtf Date: 10/12/2011 11:59 PM Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution -------------------------------------------------------------------------------- All, Off-line I was told politely to put up or shut up about my response below, and several other I've written recently. Unless you read the below and the others first, the attached may not make much sense. It's very rough. It proposes a new section for Clause 11. So best to look at the responses first. Even though I have spent this evening working on this (I didn't want to lose the thoughts), I stick with my bottom line below: 1. None of this has anything to do with states of affairs, which we agreed would be the focus of 1.1. 2. We are not going to resolve all this in time for 1.1. **So why the heck are we still talking about it??** Ron At 08:26 PM 10/12/2011, Ronald G. Ross wrote: My 2 cents, below like this ... At 06:30 PM 10/12/2011, Ed Barkmeyer wrote: Donald Chapin wrote: Attached is an updated draft resolution to Issue 13138 that incorporates yesterdayâs feedback from Mark, Ed and Don. Not that it matters really, but these are my comments on the draft of 12 Oct Change 2. extension is completely known This is very strange. 'extension' is a role of set, but a set can be the extension of any number of concepts. What is intended here is either '_set_ /is completely known/' or '//_concept_ /has completely known extension/'. That is, the intent is that an instance of type 'set' will be identified by a definite description as the extension of a specific concept. So either, 'set' is the range of the subject, or 'concept' is the range of the subject and the reference to its extension is part of the verb phrase. That said, for the reasons I put forth in my email to Mark, I don't think that the given definition is of any use to business. One possible interpretation is that if you are part of the semantic community that uses the concept, you must know what its extension is. If you don't know the extension, you shouldn't be using the term. An alternative interpretation is that the community as a whole knows all the elements of the set, but there may be no individual who does. If you want to know all the members of the set, you may have to ask all the members of the community. The only version of this fact type that is useful to business is a binary fact type that identifies a 'party' (person or organization) as a source of the information as to what all the elements of the set are. And it has nothing to do with replacing 'concept is closed in fact model', which says that the fact model -- a specific resource -- specifies all the elements of the extension. There is no relationship between 'resource specifies extension' and 'community knows extension'. (Note: I don't care one way or the other if you keep or toss 'record', but I sure don't think it will help business or the acceptance of SBVR to create 'community knows extension' and try somehow to use it as a substitute.) Either I am completely confused (very possible), or I agree with Ed, or I'm completely confused *and* I agree with Ed. There are some other possibilities, but not worth going into here. * The only thing that is of any real-world value here is whether something is completely *specified*. How would you ever *know* that all the knowable thingees of some kind are known? ... "We know that we know what they all are ... and we're very sure about that ... even though we don't know for sure who knows which ... and of course, we've never asked about it, or recorded them, because you'd have to use words or signs to do that." To me this is looking down a rabbit hole(!). * What's useful for business purposes is to say that all the knowable thingees of some kind **have been specified". Some specified list(s) of them is/are complete. What kinds of thingees could those be? * The obvious kind is general concepts. * But business people want to have assurance that other things have been specified completely and are trustworthy in that respect. (This is partly a CYA thing.) For example, Mark wants the IBM personnel directory to be trustworthy as 'complete'. That's an example of Ed's 'record'. * Ron would want any rulebook to be specified completely (not necessarily published and distributed that way). * I suspect Donald would want any terminological dictionary to be specified completely (ditto). * What are examples of "record", "rulebook" and "terminological dictionary" respectively? Not employees, rules, or terms, but records, rulebooks and terminological dictionaries. * And in all three cases they are more than sets or lists. They are *aggregations* ... or if you prefer, *aggregate specifications*. Change 3. use of conceptual schema and fact model in conformance This is totally inappropriate. I agree entirely ... but, not understanding Ed's justification entirely, I'll have to object on other grounds. SBVR is "Semantics of Business Vocabulary and Business Rules". (Stop me if I make a mistake here.) So the 'units' of inter-operability should be things recognizable as ... uh ... business vocabulary and business rules. "Conceptual schema" and "fact model" are unrecognizable in that regard. How about ... let's see ... something having to do with terminological dictionaries or rulebooks? O.K., our ambition is to support some additional forms of semantic communication ... so maybe some more general concept like .... uh .... business communication. The serious point here is ... Let's refocus on the *business purpose* of SBVR. That's ultimately the key to its acceptance (and elegance). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Having said all that, two things are obvious: 1. None of this has anything to do with states of affairs, which we agreed would be the focus of 1.1. 2. We are not going to resolve al this in time for 1.1. **So why the heck are we still talking about it??** This would be the first time that any concept defined in clause 10 is explicitly used as an SBVR construct, and of all things, what is said to be the logical foundation is used in specifying the physical representation of the SBVR concepts. Clause 10 is supposed to be the formal background for terms used in SBVR concept definitions that are not part of the SBVR concept set itself. There is nothing wrong with the unstyled use of those terms in clause 13. But conformance must be stated in terms of concepts that are part of the SBVR concept set or part of the 'exchange concept set' that is introduced in clauses 13 and 15. Further, the concept 'fact model' is defined (in 8.5) as "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations...)". This doesn't define 'fact model' to have any formal logic meaning at all. It is just some set of propositions that are true in the possible world. In formal logic, one talks about 'theories' and 'postulates'. A possible world is postulated by a set of 'postulates' (facts). Everything we can know about that world is based on the applicable theory (the conceptual schema?) and the set of postulates. 'Postulate' is a role of 'fact' that is an a priori assertion that is part of characterizing the possible world before inferencing. So, is a fact model the set of postulates that characterizes a possible world? Or just a bag of propositions that are assumed to be true in some unidentified possible world, possibly along with others that may come from another source? Does the set of facts identify the world, so that a larger set of non-redundant facts identifies a different world? The useful formal logic concept is 'the set of postulates (facts) that characterizes a possible world'. My impression is that SBVR treats 'fact model' as a bag of propositions that are taken to be true, and that is not a formal logic notion. If that is the case, it is purely a clause 13 idea -- it is just a packaging concept, and the clause 10 concept is 'possible world'. (BTW, this problem is not new with SBVR. UML had the same problem until the idea 'model' was introduced in UMLv2.) -Ed "I call that 'slop', the first big step on the road to the depths of degredation" (followed by a sequence of non sequiturs) - Meredith Wilson, "Trouble", from "The Music Man" -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info [attachment "Aggregations + Containers + Closed + Record v1.doc" deleted by Mark H Linehan/Watson/IBM] To: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-KeepSent: 1C73299A:0B94E43E-85257928:00499436; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 13 Oct 2011 10:17:57 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/13/2011 10:17:58, Serialize complete at 10/13/2011 10:17:58 I still think the "completely known" characteristic should be about sets, not about extensions of concepts. a) Despite what Ed says, there is nothing in SBVR that says or implies that a set is "complete". SBVR's "open world" default means that the extension of a concept is not "completely known". Since "extension" is just a role of "set", the "open world" default must mean that a set is by default open. b) I think we often talk about sets using definite descriptions, not terms. There should be a way to say that a set whose intention is given by a definite description is "completely known". As an example, the set of roads that are maintained by the Town of Yorktown is completely known to the Town. --------------------------- I disagree with the removal of the example about closure of the concept "rental". I think it's a great example and should be reworked using the new characteristic. Here's what the example means to me: * There is a semantic community consisting of EU-Rent and its customers. This community shares the concept "rental". By default, the concept "rental" is NOT "completely known" within this community. * There is a different semantic community consisting of EU-Rent only. The fact " 'rental' has completely known extension" is asserted for this community. This means that EU-Rent knows all instances of the concept 'rental' and EU-Rent can definitively decide whether an instance is a 'rental' or not. * EU-Rents customers (on the other hand) do not know about all rentals and thus cannot decide whether a given instance is a rental. There is a problem with this example, which Ed pointed out: presumably a customer does know about its own rentals. To support this, we could try to extend the example by adding " 'renter is responsible for rental' has completely known extension" as a fact in the semantic community of EU-Rent and its customers. But this still doesn't quite satisfy the need (as Ed also pointed out): we don't want to say that every customer knows about all the rentals of all the customers (which is what "has completely known extension" means). So I suggest that we add another verb concept: role in verb concept has completely known extension Definition: each instance that plays the role is known by the semantic community that shares the understanding of the verb concept if and only if each other role of the verb concept is known by the semantic community Given this additional concept, the semantic community consisting of EU-Rent + its customers could assert a fact " 'rental in customer has rental' has completely known extension'. The intended meaning is that if a customer is known then the customer's rentals are known. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: Date: 10/13/2011 08:42 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Attached is an updated draft resolution to Issue 13138 that incorporates yesterdayâs feedback. [attachment "Draft Resolution for Issue 13138- 2011-10-13.doc" deleted by Mark H Linehan/Watson/IBM] Date: Thu, 13 Oct 2011 10:54:16 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Donald Chapin CC: "sbvr-ftf@omg.org" Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9DEsLLL022809 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1319122465.28327@L+Myxc+3f2UGb6lRtWo4Hw X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Donald, Two minor comments on the 13 Oct draft: In bullet 1 of the Resolution text, clause 2 is 'Conformance', not 'Scope'. In bullet 1d of the Revised text: "d. REMOVE the following example sentences from the Note under .concept is closed in conceptual schema. in Sub-clause 13.7 as it doesn.t make business sense. Ed Barkmeyer pointed out in one of his emails that the corporate customer has only its own rentals in its universe of discourse," Strike all of the words after "13.7". If any part of the deleted text is significant, it should be in the Resolution, not in the directions to the editor (who does not care why). As to bullet 2, I have spoken my piece. This version simply scrubs the pig's face. -Ed Donald Chapin wrote: Attached is an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." To: sbvr-rtf@omg.org Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept X-KeepSent: A51F885E:DC508C11-85257928:004EDD92; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 13 Oct 2011 11:18:33 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/13/2011 11:18:34, Serialize complete at 10/13/2011 11:18:34 x-cbid: 11101315-8974-0000-0000-000000D36F86 MHL>> Responses inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/12/2011 05:43 PM Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept -------------------------------------------------------------------------------- Mark wrote: > Ed, > > Your concept of "record" is about a "set of representations". Well, I said it is a representation of a body of knowledge, which in turn is a set of representations of the elements of that body, yes. > I have no objection to the "record" idea, but I suggest that the more > fundamental idea is about the completeness of sets. I have no objection to the 'set is known by person(s)' idea, but it is not more fundamental. It is just different. MHL>> We agree these two ideas are different and that both are useful. MHL>> It is not worth debating which is "more fundamental". I do object to term 'completeness of sets". 'is complete' and 'is completely known to community' are different ideas. A set is a collection of specific things. All sets are complete; they contain exactly the elements that make up the set. MHL>> I am interested in the "known to community" concept and I tried to make it clear MHL>> that the community that "completely knows" a set is the "semantic community" that MHL>> shares the understanding of a concept defined as a set. See below. > If we accept the "set is completely known" characteristic I don't. It is not a useful characteristic. The basic concept you mean is a binary fact type. "Knowing" requires an intelligent agent. The fact type you mean is '_set_ /is completely known by/ _group_'. I would argue that 'set is completely known' is formally defined by: there exists some group of persons g such that _set_ is completely known by g And I aver that that information is not useful to business purposes, while the binary fact type may well be. MHL>> Please read below and in other emails where I make it clear that the role MHL>> "semantic community" is implicitly referenced in this concept. MHL>> In brief: facts are asserted by semantic communities. The proposed definition MHL>> explicitly refers to the semantic community that asserts a fact using this MHL>> verb concept. > , then a "record" can be a "communication content that is a set that > is completely known" -- meaning that all the elements of the set are > represented in the communication content. The fact type I stated is the one I meant. '_Set_ is completely documented by _record_', aka 'record documents set'. The record enumerates the elements of the set, by providing identifiers for each element, and possibly other information. Finding the record and reading the information is a different process from finding the person who knows and asking him and listening to what he tells you. They are different means of adding you to the group of persons who know the set. And in different circumstances one may be better than the other. But neither is more 'fundamental'. In the terms of clause 11, the knowledge is transferred by communication content, the distinction is in the form and the access mechanism. MHL>> OK. I don't argue that the fact type 'group completely knows set' is a bad idea, but it is a different idea from 'record completely documents set'. And the relationship between them is that some group who completely knows the set created the record, and did not thereafter have to provide the information to multiple clients one by one. "That the UK Foreign Ministry Bureau for Central America completely knows the set of states of Mexico" is a useful fact; "that Wikipedia documents the set of states of Mexico" is probably a more useful fact. MHL>> OK. > Notice that the representations might be in either of two forms: (a) > representations of the actual things, such as the line items of an > order; (b) representations of the concepts that makeup the reference > scheme for the "target" concept. For example, a "record" of employees > will not contain the actual employees but instead will have > representations of the names or employee serial numbers or some other > references to the employees. This is a good point. If we elect to keep 'record', then we should improve on the definition: (a) is what is meant. (b) defines a concept. MHL>> I'm not sure what you mean directly above. It only defines a set as the extension of that concept, which takes us back to square one. Now "representations of the actual things" is not quite right, because SBVR says that only concepts have representations. MHL>> I was thinking of definitive descriptions of the things. For example, a database of MHL>> orders for signs might have an entry that reads "5 plastic signs measuring 2.5 feet MHL>> by 4 feet reading "blah blah" ". The term I used was 'identifiers' for the things that are the elements of the set, that is, the record provides the values of the elements of some reference scheme for the individual things. I believe Mark's example is an example of (a) thus reworded, in that employee numbers are identifiers for employees. MHL>>I meant my example to be of (b), that is of "representations of the concepts that makeup the reference MHL>> scheme for the "target" concept" Aside: "identifies" and "identifiers" is about the behaviour of reference schemes, not representations. MHL>>Yes, but an identifier is "represented" in some form in a "record". Terry's intent in this is that while we may think that "Ed Barkmeyer" /represents/ a person, what we really mean is "the person whose name is 'Ed Barkmeyer'" -- a definite description that resolves to an individual person (assuming that it does). "the person whose name is 'Ed Barkmeyer'" is a concept that corresponds to exactly one person (in our current UoD). MHL>> Yes. The designation for that concept is its definition. MHL>> Not in general. Designations and definitions may be different. We may choose to make the symbol 'Ed Barkmeyer' a designation for that individual concept as well, but that is a separate concern. MHL>> Yes. The name expression is being used as the value of the sole element of a reference scheme for 'person'. But it is the thing (the actual person) that has the 'name' attribute, and the name attribute per se has nothing to do with designations or individual concepts. MHL>>Yes. The SBVR definition of 'thing has name' is utterly misguided. 'thing has name' just makes an expression play the role of 'name' with respect to a thing. The intent of that role is to participate in a reference scheme for the thing. MHL>>"thing has name" applies to things that are conceptualized as individual concepts. MHL>>For most purposes, most people are not conceptualized that way. Instead, most MHL>>people are identified by reference schemes, of which "name" may be a component. MHL>> MHL>>I think the main point Ed is making is that we should not confuse "thing has name" MHL>>with "name" used in a reference scheme. > I can think of examples where the "closed world" concept applies > independently of any sort of representation: > > * The set of my siblings is completely known to me. I can > definitively say that Ed is not my sibling. > * In a very small business (e.g. a small farm or retail store with > fewer than a half-dozen employees), the set of employees may be > "completely known" to the employer but not written down in a list. > That is, the employer may be able to distinguish employees from > non-employees without a "record". This is absolutely correct. In each case a specific person or group does the knowing. As I said, there is nothing wrong with the binary 'person knows all elements of set' fact type; it is just distantly related to 'record documents set'. MHL>> Good, we agree. > * In a small bookstore, there may be no formal inventory "record". > The answer to the question "do you have book x?" may be answered by > going to the shelves and looking. The set of books is "completely > known" in the sense that they are exactly the books on the shelves. Yes. There is no record. But the set is not 'known'. It is just the set of books on the shelves. The elements of that set can become 'known' to anyone who gets to examine all the shelves. But it is not 'known' in any other sense. MHL>>I'm not sure I understand your point here. The set is "closed world" in that MHL>>you can determine whether a book is part of the set or not. Are you complaining MHL>>about the designator "is completely known" with respect to this example? > To put this another way, I do not agree that "a 'complete body of > information' is the content of a repository". I think that a > "complete body of information" may be knowledge in someone's mind or > may be dynamically derived by "querying" something in the physical > world (as in the bookstore example). How the knowledge is derived is irrelevant. It is known when someone has the knowledge, and not otherwise. MHL>>Yes. So you agree with me? > Each of the above is "accessible as a package" even though not written > anywhere. I propose the concept "set" as the "package" that Ed > mentions because "set" is an existing SBVR "package" concept that > contains "things" independently of how or whether they are represented. This is word conflation. The 'body of information that identifies each element of the set of states of Mexico' is not the 'set of states of Mexico'. An 'accessible package' that is or contains the 'body of information' is not and does not contain the 'set of states of Mexico'. And the person who completely knows the set of states of Mexico knows some identifier for, and possibly other facts about, each and every element of that set. What he knows is information, not states. MHL>>I don't understand your point here. MHL>>I think the issue is whether a "body of information" that gives a set of states of Mexico MHL>>definitively lists them all. Whether the set is complete or not. > Note that "extension" is a role of "set" in "concept has extension". > The reason that I propose "is completely known" as a characteristic > of "set" (rather than "extension") is that I think the "is completely > known" idea is independent of whether a set of things is > conceptualized. In the bookstore example, above, the set of books "is > completely known" regardless of whether or not the bookstore owner > conceptualizes the set of books on the shelves as "book inventory" (or > some such term). I agree with this. I see no problem with 'person knows set' and 'record documents set'. MHL>>I'm fine with "record documents set" and have a different solution to the "person" MHL>> part of "person knows set". > Ed correctly points out that "set is completely known" must identify > either "WHO" thinks a set is complete or "WHERE" it is complete. I > addressed that in my proposed definition by using the existing SBVR > verb concept "semantic community shares understanding of concept". I > think my proposed characteristic should be used in facts stated by > semantic communities. The "WHO" is the semantic community that states > a fact such as "the set of books is completely known". Ah! That is, the subject of 'group knows set' is a semantic community that has a definite description. Mark wants define 'set is known' as: the semantic community that shares the body of shared meaning that contains some concept that refers to this set knows exactly which individual things are in the set. Or something like that. Is that right? MHL>>Not quite. The community that "completely knows" a set is a semantic MHL>>community that asserts a fact about "set is completely known". This is not necessarily MHL>>the same semantic community that defines the set. Does that also mean that no one will ever refer to the set who doesn't know all the members? I can't talk about the set of states of Mexico because I don't know them all? And if you don't know them, you can't understand the concept? I don't believe that the semantic community that uses the concept knows them all. MHL>>Agreed. Defining a concept is not the same thing as asserting a fact that MHL>>the extension of a concept is "completely known". Further, I don't understand the business use of the idea that the originating community knows what the elements of the set are. For business purposes, I just need some authority I can ask; I really don't care whether it is the originators of the term or the local librarian. MHL>>The motivation is the existing example in clause 8.5, where EU-Rent knows MHL>>about all rentals, but customers know only about their own rentals. I really don't think this definition is viable. And I really don't think this is the fact type we want. Just put the subject role out there and let the user fill it with something useful. MHL>>I don't think you understood the idea, so no wonder you don't think it "is viable". Most importantly, this doesn't address the closure issue. The point of this was to be able to say that the set of individual facts in some body of knowledge completely enumerates the members of a set. It is a particular body of knowledge, not necessarily all or only the common knowledge of a semantic community. MHL>>I'm not quite sure what you mean by "in some body of knowledge". I think you MHL>>are referring to the "record" idea. But this gets to the heart of the issue between MHL>>us. I think the closure idea can apply to sets as understood by a community, MHL>>independent of how the elements of the set are organized in "records". You are MHL>>particularly interested in how the information is organized in "records". > Ed argues that "'set is immutable' by definition". I don't see > anything like that in the clause 8.7 definition of "set". It seems to > me that the set of books available for sale does vary over time -- > that is, over possible worlds. That is, the extension of 'books available for sale' may be a different set in a different possible world. What varies over time is /which/ set of books plays the role 'extension' of the concept 'books available for sale'. English confuses us; that is why we formalize. MHL>>I think there are two cases that should be distinguished: MHL>> 1) When we define a concept such as "books available for sale" the concept itself doesn't change MHL>> over time, but its extension may. MHL>> 2) When we use a definite description for a set, such as "the set of books on the shelf", the MHL>> definite description itself does not change even though its extension may. MHL>> So in (2), the "elements" of the set may change even though the "set" is the same one over time. MHL>>Net: I certainly agree that "English confuses us; that is why we formalize". > In any given world, the set of books is fixed and "completely known", > but as that world evolves to new possible worlds, the set certainly > changes. Being careful, this is a version of the 'concept nominalization' problem. What is actually meant by "the set changes"? If the Chair of the Date/Time FTF changes, does Mark change? No. What changes is who plays the role. Similarly, what changes over time here is which set of books plays the role, not which books constituted the original set. MHL>>Ah, so you are connecting this problem with the "unitary concept" idea (?) MHL>>I think you are arguing that "the set of books on the shelf" is a unitary concept MHL>>that changes to a new set over time. Is that what you mean? Is that really useful? > Thus, in my view and answering a question raised by Don, "set is > completely known" has no special alethic implications. Well, we should try not to go there. The issue is that 'Person knows proposition' doesn't make the proposition a fact. There is no such inferencing rule in FOLs. Only in an alethic logic is there an inferencing rule of the form: From _person_ knows _proposition_, to infer _proposition_ is true. But here we are not clearly talking about propositions. 'person knows set' means 'person' can enumerate the elements of 'set'. (I think.) MHL>>I agree. > > MHL>> I inserted a few more responses below, like this. > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > > > From: Ed Barkmeyer > To: Mark H Linehan/Watson/IBM@IBMUS > Cc: "sbvr-rtf@omg.org" > Date: 10/11/2011 02:22 PM > Subject: Re: SBVR: Fallout from Issue 13138: the "record" concept > ------------------------------------------------------------------------ > > > > > > Mark H Linehan wrote: > > I have several comments about this: > > > > 1) I think issue 13138 has nothing to do with the "state of affairs" > > issues and should be handled entirely as a separate thread. Whether > > it can be resolved within the next 3 weeks, I don't know. > > I concur on both counts. The issue of whether a body of information is > complete has nothing whatever to do with states of affairs. > The idea that a body of information is complete seems to be a concept > that SBVR didn't really have. Mark and I are among those who believed > that a 'conceptual schema' was something other/more than an IT packaging > idea. The problem for SBVR is that it was doing double duty. And that > is what makes resolving Issue 13138 really problematic -- we need to > sort out the idea of 'closure of a body of information' from the idea of > a body of SBVR exchange elements. > > > 2) I agree with Ron that there is both a "meaning" and a > > "representation" side of this "closed world" issue. I think we need > > to resolve the "meaning" side of it as part of 13138, otherwise we'll > > lose the "closed world" capability. I think the representation aspect > > (i.e. "records") can be addressed separately. > > I agree in part. I argue, however, that a 'complete body of > information' is the content of a repository, and what is being said is > that some repository of expressions holds the entire body. The whole > idea of a body of information is that it is a package that is somehow > accessible as a package. And the same is true of a body of shared > meanings and a body of shared guidance. We can separate the content > from the container, but we are implying that there is a container, or an > identifiable collection of containers, that contains the body. One of > the serious shortcomings of SBVR is that it provides no practical > approach to terminology exchange, because it doesn't have exchange > concepts for meaningful containers. > > > 3) For the meaning aspect, I suggest a new characteristic of "set": > > "_set _/is completely known/" defined as: "each _element _/of /the > > _set _is known to the _semantic community_ that /shares an > > understanding of/ the _set_". > > I would argue that this approach is a bit misguided. > A set is a 'res', not a 'meaning', so I don't know how one can 'share > understanding of it'. > MHL>> "Set" is a concept that defines a kind of "res". One can > certainly share an understanding of > MHL>> of a set independent of the elements of the set. EJB: No. I stand by what I said. Each instance of the concept 'set' is a res. I don't know what it means to 'understand a res'. One understands the 'intension' of a set, that is, one understands the concept of which the set is the extension. One understands the concept that defines the membership rule. And one thus 'understands the set' as the set of things that satisfy that rule. This is really foundational stuff. 'set' has a very narrow meaning in the SBVR context, while English usage commonly confuses the set -- the things -- with the intension -- the concept that defines the set by an admissibility rule for each thing. > And every set is by definition 'complete' -- it is a collection of > specific things, and no others. > The intensional description of a set -- the rule for membership -- is a > 'concept', not a 'set'. The set is the extension of that concept. A > "set that is not completely known" is a concept whose extension is not > (completely) known. > MHL>> Yes. My point is that a set can be "complete" but not > "completely known". And a set is an > MHL>> "extension" only in the context of a concept. You can > implicitly refer to a set using a definite description > MHL>> (e.g. "the books on the shelves") without explicitly > conceptualizing it. That is the problem. "the books on the shelves" is the definition of a concept. Any given book is either on one of the shelves and thus in the set of interest, or it is not on one of the shelves and is not in the set of interest. If Treasure Island, Kidnapped, and Ivanhoe are on the shelves, and Jane Eyre is on the table, then the set {Treasure Island, Kidnapped, Ivanhoe} is the extension of the concept. If someone picks up the Jane Eyre book and puts it on the shelf, the set {Treasure Island, Kidnapped, Ivanhoe} does not change, but it is no longer the extension of "the books on the shelves". The extension is now the set {Treasure Island, Kidnapped, Ivanhoe, Jane Eyre}, which is a different set. In a similar way, if the number of apples on my desk is 3, and I eat one apple, 3 does not become 2; rather the number that is the instance of the concept "number of apples on my desk" becomes 2, a different number. > > The issue is, as clause 8 currently says, whether a 'concept is closed' > -- whether the set that is its extension is extensionally defined in > some 'resource'. As Don points out, we know how to define a concept > extensionally -- one big OR of the 'individual concepts'. But that > assumes that the 'resource' that defines the extension is an extensional > definition per se. (We don't have a similar fact type for sets, > because SBVR doesn't think things have designations, there is no > corresponding grammatical construct in SBVR SE, and no part of SBVR > provides a means of exchanging a structure that is a 'list' of specific > things, even though that is a common business concept.) > MHL>> This is a problem that we ran into in the Date-Time effort. > Further, it > assumes that the extension of the concept is not only 'known', but also > 'constant'; it doesn't change over time. In many other cases, the > resource is something like a database table, in which each row > represents an instance, and the whole set of rows -- the table itself > -- which in SBVR is a 'fact model'. In such cases, the extension of > the concept, at the time of any business decision, is "completely known" > and captured in that resource. That is what I meant by a 'record'. > MHL>> Regarding whether SBVR thinks the extension of a concept is > "known" -- SBVR is clearly "open world" > MHL>> by default, meaning that the extension of a concept is not > necessarily known. > MHL>> Regarding whether SBVR thinks the extension of a concept is > "constant" -- my reading of clause 10 is that > MHL>> as one "fact model" evolves to another "fact model", the "fact > population" does change. In other words, > MHL>> concepts may have different extensions in different "fact models". This is all true and mostly irrelevant. Don suggested that SBVR can define a concept extensionally, e.g., "boy in the band" as "John or Paul or George or Ringo". The set that is the extension of that concept is not only closed; it is constant. "boy in the band" cannot correspond to any other person in any possible world. By comparison, I can define a concept "boy in the band" and state in the fact model for a possible world: John is a boy in the band. Ringo is a boy in the band. Paul is a boy in the band. The concept 'boy in the band' is closed in this fact model. That means that in this possible world, the set of boys in the band is John, Paul and Ringo, and no others. It is not the case that there may be some other person who is a boy in the band but did not get explicitly mentioned in the fact model. The meaning of 'is closed in this fact model' is that the open world assumption does not apply to the concept 'boy in the band'. But unlike the constant definition, this formulation does not preclude another possible world in which George or Linda or Yoko is also a boy in the band. The fact model for this other world then contains: Linda is a boy in the band. George is a boy in the band. in addition to the facts above. So this other possible world also states that the concept 'boy in the band' is closed in it. It only means that this possible world does not include any boys in the band that were not explicitly mentioned in its fact model. In this world, the set of boys in the band is {John, Paul, Ringo, Linda, George}. Yoko cannot be a boy in the band in this world, but she might be a boy in the band in some other possible world. This is the case for employees. The fact model for a given world identifies each employee and is "complete" in the sense that 'employee' is closed in that model. There are no persons who are 'employees' that are not explicitly mentioned in the fact model. The fact model that describes the world of two weeks later may well identify a somewhat different set of persons as employees, but it can still be 'closed'. No one defines the concept 'employee' "extensionally", by listing all the current ones. If you do, you have to change the definition of the concept 'employee' every time the staff changes. > > Upon reflection, I think 'fact model' should mean 'body of information', > and we want 'concept is closed in fact model'. A 'fact model' is not an > XML data set that conforms to an SBVR schema. That is just one form of > 'resource'/'repository' that is a container of a fact model. Every fact > model is contained in some 'resource' or set of such 'resources'. A > fact model that is to be identified as specifically defining the extent > of some concept (by such a closure rule) must have a name or > designation, and that designation may be different from the designation > for the container itself (which may be an IT object or a file cabinet). > > MHL>> This view focusses on the WHERE. I think for business purposes, > it is more helpful to focus on the WHO. I disagree. But as long as we support both, we can all be happy. > > I think my concept 'record' is the expression of a 'fact model' within > some 'resource'. > And I think 'communication content' is the expression of a 'fact model' > (i.e., body of information), or perhaps a role of that expression with > respect to some 'resource', such as a document, a database, or a message. > _ > _ > > > > > > * Redoing the existing example in 8.5 in the Note under "concept > > is closed in conceptual schema": both EU-Rent and a corporate customer > > of EU-Rent might adopt EU-Rent''s "rental" concept. Only the EU-Rent > > semantic community would state as a fact "the _extension _/of /_rental > > _/is completely known/" to indicate that EU-Rent knows all its rentals. > > The idea: 'extension of _concept_ is completely known', as distinct > from '_set_ is completely known', is useful. But, that it is completely > known to unidentified parties is not useful in business. The useful > fact type must be binary: we need to know WHO knows, or WHERE it is > captured. So there may be two such fact types: 'extension of _concept_ > is known by _party_' and 'extension of _concept_ is specified in > _record_'. SBVR itself never introduces 'party' (or SUMO 'legal > entity', or anything the like); so that makes it difficult to express > the WHO version. I proposed 'record' to address the WHERE. > > MHL>>This is why I used the concept "semantic community" for what Ed > calls "party". Well, not quite. Mark assumed a specific semantic community, which he proposes to identify by a definite description within the definition of 'set is completely known'. I was thinking of '_set_ is completely known by _party_'. For business purposes, is '_set_ is completely known by _semantic community_' a satisfactory substitute? Color me doubtful. > > > The corporate customer would not state this fact so would operate on > > the usual "open world" assumption. > > In point of fact, the corporate customer doesn't care about other EU > Rent rentals; they are not likely to be things in its world of > interest. So its concept 'rental' would have a different extension. It > may still be true that it is treated as 'open'. > > > > * Consider an order that has multiple line items. The fact "the > > extension of 'order has line item' is completely known" means that the > > semantic community that states this fact knows all the actualities of > > "order has line item". > > This is actually a bit trickier. Knowing all the actualities of 'order > has line item' requires some resource/party to know all of the orders, > and all of the line items in each. One would expect, of course, that an > 'orders database' would have all that. So the fact type 'customer order > has line item' is closed in the 'customer orders data' (fact model) > which is captured as a set of tables (the record) in the Sales Database > (repository). But the signed contract that documents a specific 'order' > explicitly documents all of the line items for that order -- it is a > closed 'record' of the line items of that order only. > > > Responding to Ron's comments: > > > > * "set" is an existing SBVR concept that is similar to "aggregation" > > * I did not address "set is immutable" because I think it is outside > > the scope of 13138. > > The more general concept is 'collection'; 'aggregation' has several > meanings of which 'set' is not a specialization. > And 'set is immutable' by definition. A 'set' is a specific enumeration > of things, and no others. If you add one, or take one out, you get a > different 'set' -- a distinguishably different instance of the concept > 'set'. > > > Responding to Ed's comments: > > > > * I don't think the distinction between "is complete" and "is > > authoritative" is worth the additional complexity of having two > > characteristics rather than one. > > I agree. I think 'is authoritative' is an inappropriate addition. > Business rules determine what is authoritative for what purposes, and > the 'characteristic' alone may not actually characterize anything. We > do best by not going there. > > -Ed > > > -------------------------------- > > Mark H. Linehan > > STSM, Model Driven Business Transformation > > IBM Research > > -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Thu, 13 Oct 2011 17:33:47 +0100 From: John Hall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 To: Mark H Linehan CC: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-Mailcore-Auth: 4600872 X-Mailcore-Domain: 13170 Mark, One comment in-line, Regards, John On 13/10/2011 15:17, Mark H Linehan wrote: I still think the "completely known" characteristic should be about sets, not about extensions of concepts. a) Despite what Ed says, there is nothing in SBVR that says or implies that a set is "complete". SBVR's "open world" default means that the extension of a concept is not "completely known". Since "extension" is just a role of "set", the "open world" default must mean that a set is by default open. b) I think we often talk about sets using definite descriptions, not terms. There should be a way to say that a set whose intention is given by a definite description is "completely known". As an example, the set of roads that are maintained by the Town of Yorktown is completely known to the Town. --------------------------- I disagree with the removal of the example about closure of the concept "rental". I think it's a great example and should be reworked using the new characteristic. Here's what the example means to me: * There is a semantic community consisting of EU-Rent and its customers. This community shares the concept "rental". By default, the concept "rental" is NOT "completely known" within this community. * There is a different semantic community consisting of EU-Rent only. The fact " 'rental' has completely known extension" is asserted for this community. This means that EU-Rent knows all instances of the concept 'rental' and EU-Rent can definitively decide whether an instance is a 'rental' or not. * EU-Rents customers (on the other hand) do not know about all rentals and thus cannot decide whether a given instance is a rental. In this example, 'rental' is being used in two contexts as a term for two different concepts - different because the extensions are different. In EU-Rent, the extension of 'rental' is "our (EU-Rent's) rentals". EU-Rent is interested only in its own rentals; rentals made by Hertz, Avis and other rental companies are not in EU-Rent's BOSM. In Custco (assuming that Custco rents cars only from EU-Rent) the extension of 'rental' is "our (Custco's) rentals". Custco is interested only in its own rentals; rentals made by other customers of EU-Rent are not in Custco's BOSM. The concept called "rental" by Custco would in EU-Rent be called 'Custco rental' (or something equivalent) - if EU-Rent wanted to include it explicitly in its BOSM. There is a problem with this example, which Ed pointed out: presumably a customer does know about its own rentals. To support this, we could try to extend the example by adding " 'renter is responsible for rental' has completely known extension" as a fact in the semantic community of EU-Rent and its customers. But this still doesn't quite satisfy the need (as Ed also pointed out): we don't want to say that every customer knows about all the rentals of all the customers (which is what "has completely known extension" means). So I suggest that we add another verb concept: role in verb concept has completely known extension Definition: each instance that plays the role is known by the semantic community that shares the understanding of the verb concept if and only if each other role of the verb concept is known by the semantic community Given this additional concept, the semantic community consisting of EU-Rent + its customers could assert a fact " 'rental in customer has rental' has completely known extension'. The intended meaning is that if a customer is known then the customer's rentals are known. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: Date: 10/13/2011 08:42 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Attached is an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback. [attachment "Draft Resolution for Issue 13138- 2011-10-13.doc" deleted by Mark H Linehan/Watson/IBM] --------------------------------------------------------------------------------------------------- Text inserted by Panda GP 2011: 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! --------------------------------------------------------------------------------------------------- Date: Thu, 13 Oct 2011 12:48:42 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9DGmlcs003520 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1319129332.75484@kJ0yCK1kRGzbOAYmYuJgjA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark H Linehan wrote: I still think the "completely known" characteristic should be about sets, not about extensions of concepts. a) Despite what Ed says, there is nothing in SBVR that says or implies that a set is "complete". SBVR's "open world" default means that the extension of a concept is not "completely known". Since "extension" is just a role of "set", the "open world" default must mean that a set is by default open. No. It means we may not know, or even be able to know, which set it is. There is no such thing as a 'set that is open'. The Open World Assumption means that for a given concept C, the proposition "there exists a thing x, such that x is an instance of C" may not be provably true or provably false; it could be true but not provable. ("There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Or in this case: provable in your theory.) The Closed World Assumption is that if you can't prove that it is true, then it /is false/. Using the 'boys in the band' example, knowing that John, Paul, George and Ringo are instances of 'boy in the band' doesn't give us a way to prove that "there exists a person p such that p is a boy in the band, and p is not John and p is not Paul and p is not George and p is not Ringo" is false. That string of ands defines a concept whose instantiation is neither provable nor disprovable. So we don't know whether the extension of 'boy in the band' is the set {John, Paul, George, Ringo} or some other set that has those elements and others. That is the OWA. Put another way, "adding to a set" is like "adding to a number" -- the result is a different set. It has some relationships to the set you started with, just as 3 has some relationships to 2, but it is a different thing. b) I think we often talk about sets using definite descriptions, not terms. There should be a way to say that a set whose intention is given by a definite description is "completely known". As an example, the set of roads that are maintained by the Town of Yorktown is completely known to the Town. Yes. A definite description is the definition of a concept, always. Thus you are referring to the set by a definite description of the set -- it is "the extension of the concept 'road that is maintained by the Town of Yorktown'". We call the concept 'road that is maintained by the Town of Yorktown' the "intension" of the set. The intension is not the description of the set, it is the description of each member of the set: A thing R is in the set if and only if R is a 'road that is maintained by the Town of Yorktown'. Again, this is about making careful distinctions between common English usage and the formal meaning of that usage. --------------------------- I disagree with the removal of the example about closure of the concept "rental". I think it's a great example and should be reworked using the new characteristic. Here's what the example means to me: * There is a semantic community consisting of EU-Rent and its customers. This community shares the concept "rental". By default, the concept "rental" is NOT "completely known" within this community. Well, if EU-Rent is in the community, and EU-Rent knows who all of its actual customers are, then it seems to me that the concept 'rental' must be completely known "within" the community. What you mean is that it is not completely known by every member of the community. Do you intend to define "is completely known" to mean "is completely known by every member of the community"? * There is a different semantic community consisting of EU-Rent only. The fact " 'rental' has completely known extension" is asserted for this community. This means that EU-Rent knows all instances of the concept 'rental' and EU-Rent can definitively decide whether an instance is a 'rental' or not. * EU-Rents customers (on the other hand) do not know about all rentals and thus cannot decide whether a given instance is a rental. Agree. This is a clear example. Now, what is the relationship of these distinct communities to the concept 'rental'? If it is only completely known by the EU-Rent internal community, the fact model that declares the extension to be completely known is not a fact model that is used by the customers. Which means that the fact type cannot be used in a customer fact model to say that the EU-Rent folk know the extension. If you don't know, you are not in the community to which the fact model applies, and you can't say who does know. There is a problem with this example, which Ed pointed out: presumably a customer does know about its _own _rentals. To support this, we could try to extend the example by adding " 'renter is responsible for rental' has completely known extension" as a fact in the semantic community of EU-Rent and its customers. But this still doesn't quite satisfy the need (as Ed also pointed out): we don't want to say that every customer knows about all the rentals of _all _the customers (which is what "has completely known extension" means). So I suggest that we add another verb concept: *_role_** **/in/** _verb concept_** **/has completely known extension/* Definition: each _instance_ that plays the _role_ is known by the _semantic community_ that /shares the understanding of/ the _verb concept_ if and only if each other _role _of the _verb concept_ is known by the _semantic community_ Given this additional concept, the semantic community consisting of EU-Rent + its customers could assert a fact " 'rental in customer has rental' has completely known extension'. The intended meaning is that if a customer is known then the customer's rentals are known. This is analogous to one of the other closure rules for the conceptual schema. It essentially asserts that every involvement of a thing in a given fact type role is explicit in the fact model. But again, that is about fact models -- explicit bodies of information -- not about communities knowing information. Knowing assists the knower in making decisions. It doesn't help anyone else if s/he doesn't also communicate the knowledge. So saying that someone unspecified knows doesn't provide any useful information. Saying that everyone knows means you are not a part of the community if you don't, which is only useful information in a very different way. Back to Ron's question: Why are we talking about this? -Ed 2 is not equal to 3 - not even for very large values of 2. - Grabel's Law -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: Date: 10/13/2011 08:42 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) ------------------------------------------------------------------------ Attached is an updated draft resolution to Issue 13138 that incorporates yesterdayâs feedback. [attachment "Draft Resolution for Issue 13138- 2011-10-13.doc" deleted by Mark H Linehan/Watson/IBM] -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." To: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-KeepSent: A2BD2300:4633E729-85257928:005CB7F7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 13 Oct 2011 13:13:01 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/13/2011 13:13:02, Serialize complete at 10/13/2011 13:13:02 x-cbid: 11101317-5930-0000-0000-0000004E20C3 Ah, John's comments imply a slightly-different scenario than I assumed from the text in 8.5: a) I thought that both the term "rental" and the definition of "rental" would be shared among EU-Rent and its customers. b) John's comment implies that both EU-Rent and its customer use the term "rental" but with different definitions. In (b), a customer could define "rental" to be something like "contract by me to rent a car", where "me" is an individual concept. In this case, the "role in verb concept has completely known extension" verb concept would not be required. Instead, one could use " 'rental' has completely known extension". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: John Hall To: Mark H Linehan/Watson/IBM@IBMUS Cc: sbvr-rtf@omg.org Date: 10/13/2011 12:37 PM Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Mark, One comment in-line, Regards, John On 13/10/2011 15:17, Mark H Linehan wrote: I still think the "completely known" characteristic should be about sets, not about extensions of concepts. a) Despite what Ed says, there is nothing in SBVR that says or implies that a set is "complete". SBVR's "open world" default means that the extension of a concept is not "completely known". Since "extension" is just a role of "set", the "open world" default must mean that a set is by default open. b) I think we often talk about sets using definite descriptions, not terms. There should be a way to say that a set whose intention is given by a definite description is "completely known". As an example, the set of roads that are maintained by the Town of Yorktown is completely known to the Town. --------------------------- I disagree with the removal of the example about closure of the concept "rental". I think it's a great example and should be reworked using the new characteristic. Here's what the example means to me: * There is a semantic community consisting of EU-Rent and its customers. This community shares the concept "rental". By default, the concept "rental" is NOT "completely known" within this community. * There is a different semantic community consisting of EU-Rent only. The fact " 'rental' has completely known extension" is asserted for this community. This means that EU-Rent knows all instances of the concept 'rental' and EU-Rent can definitively decide whether an instance is a 'rental' or not. * EU-Rents customers (on the other hand) do not know about all rentals and thus cannot decide whether a given instance is a rental. In this example, 'rental' is being used in two contexts as a term for two different concepts - different because the extensions are different. In EU-Rent, the extension of 'rental' is "our (EU-Rent's) rentals". EU-Rent is interested only in its own rentals; rentals made by Hertz, Avis and other rental companies are not in EU-Rent's BOSM. In Custco (assuming that Custco rents cars only from EU-Rent) the extension of 'rental' is "our (Custco's) rentals". Custco is interested only in its own rentals; rentals made by other customers of EU-Rent are not in Custco's BOSM. The concept called "rental" by Custco would in EU-Rent be called 'Custco rental' (or something equivalent) - if EU-Rent wanted to include it explicitly in its BOSM. There is a problem with this example, which Ed pointed out: presumably a customer does know about its own rentals. To support this, we could try to extend the example by adding " 'renter is responsible for rental' has completely known extension" as a fact in the semantic community of EU-Rent and its customers. But this still doesn't quite satisfy the need (as Ed also pointed out): we don't want to say that every customer knows about all the rentals of all the customers (which is what "has completely known extension" means). So I suggest that we add another verb concept: role in verb concept has completely known extension Definition: each instance that plays the role is known by the semantic community that shares the understanding of the verb concept if and only if each other role of the verb concept is known by the semantic community Given this additional concept, the semantic community consisting of EU-Rent + its customers could assert a fact " 'rental in customer has rental' has completely known extension'. The intended meaning is that if a customer is known then the customer's rentals are known. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: Date: 10/13/2011 08:42 AM Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Attached is an updated draft resolution to Issue 13138 that incorporates yesterdayâs feedback. [attachment "Draft Resolution for Issue 13138- 2011-10-13.doc" deleted by Mark H Linehan/Watson/IBM] --------------------------------------------------------------------------------------------------- Text inserted by Panda GP 2011: 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! --------------------------------------------------------------------------------------------------- X-Yahoo-Newman-Id: 202076.89247.bm@omp1018.access.mail.sp2.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1318526439; bh=25Z2A77YBLR5co9URsEbN2pBmHRsJXox/G2RPGYHBtU=; h=Message-ID:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-Mailer:Date:To:From:Subject:In-Reply-To:References:Mime-Version:Content-Type; b=mGpd/aeQY+Xcm2l2IvOCrrlZkWq1IQYTpiP0iQh4Yq6iVd6iUBTUz4+iwJiHNmJozVE373xYKxieitclKQymWaEHnqlaiQ7cgDlEoVHfr1cZwkezTCcEn8I+FVJYwiPm7Fnro4vXDKGH8sEBjjxOLkOibqWblXgoymYIW+UfWE4= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: lJtUqYYVM1lpkfODmi8KfqhowfNdHW9kDmXJebpqYht9Y4U WLKtBqY3sq_XFUelZPWu4kOKRbw5OdV3zVv_PJSGp0UhNKCHZbJu4LvrzgAf uJj56D8WOBBtjQbScRE2V7hbvI4WeYeKONDf9MJIZX.iOpIn9BnmQaSErR0. ctz7s21CsATO4VdzLyESPCNl5d8R1Mmm9fam72sYq8v095eHq2ElhzLzn4Az YzTgfXhJJ4OzVFyGQ0hr5eeVgsmIvXBZ.N9IjPnhcPFPIFxlvoTaEYzCkioU adHlFe1YPkyoQJnI7DYLGRjL3SmU416VpV11nrFQMI17OFQJEZNCY26989gJ tKxDlOkPsxonmpCVeGlkSJgHZx3ef6qYsqpDseqczbZn8YQ.PKB6xTAXzcZK PskW4Z7aQ9lB.HLVoKqf7.CYQp.5zhU7V7pWZVbKUrIdh889.qPGihNqrhoB tOlAKABpFKkayB2KHtvfWV4vI.S9wANKVaAcBdf9I61j2askp_GO4xiEFfGU ptXHnfE4E0wDxQ1mEsv0whM13AbiqdKZPxk10Nvcid.PRZth8LvD3x3_mkP5 Ev3WWpVsx2.tvWdAm8hI- X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Oct 2011 12:20:17 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Mark, Thanks for taking the time to look this over. I appreciate it. A revised version is attached addressing some of your suggestions below. Also, last night I realized that the scheme isn't complete until it dealt with communication and communication content. I looked at that section in SBVR and it really needs improvement or repositioning. I think I have a good, more natural idea for it. See new additions at the end of the attached, FWIW. More like this below ... Ron P.S. I repeat. Why are we still talking about this now if it doesn't have to do with state of affairs and can be finalized for 1.1?? At 08:18 AM 10/13/2011, Mark H Linehan wrote: Comments: 1) Whether we call these things "aggregations" or "containers" or "collections" makes very little difference to me. Business people (and data modelers) wouldn't use "set". But they would use "aggregation". But we already have the concept "set". Why not use that? Not going to connect with business people. 2) I would not want to see us add new "aggregation" concepts without cleaning up the confusion of existing ones. We should be trying to delete some of these. And probably we should be reusing/redefining existing signifiers. Agree entirely. My position is if an existing signifier/concept (in your list) doesn't fit into Clause 10 or this new "aggregation" Clause in Clause 11 we should be rid of it. That was one *big* reason for putting this scheme together. 3) I am particularly interested in applying the "completely known" idea to the extension of a concept: a way to say that a company "completely knows" all its employees. As discussed, I think trying to say "completely knows" on the meaning side leads into never-never land. But I'll leave that question in more qualified hands (minds). 4) I believe that it makes sense to talk about BOTH "aggregation of representations is specified completely" and the corresponding concept applied to meanings. You can "know" the complete extension of a concept without representing the instances. Ditto above. However, it could be added with little disruption. 5) Regarding the " authoritative until date-time" idea -- if you're going to do that, I suggest specifying it with both a "from" date and a "to" date. The product catalog for 2012 is not authoritative until January 1, 2012. Agree. Modified. 6) I think " aggregation of representations is immutable" is not what you want for a "snapshot in time". Suggest "aggregation of representations as of date-time" -- that is, a basic versioning concept. Agree. Modified. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Ronald G. Ross" To: edbark@nist.gov, Donald Chapin Cc: sbvr-rtf Date: 10/12/2011 11:59 PM Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution All, Off-line I was told politely to put up or shut up about my response below, and several other I've written recently. Unless you read the below and the others first, the attached may not make much sense. It's very rough. It proposes a new section for Clause 11. So best to look at the responses first. Even though I have spent this evening working on this (I didn't want to lose the thoughts), I stick with my bottom line below: 1. None of this has anything to do with states of affairs, which we agreed would be the focus of 1.1. 2. We are not going to resolve all this in time for 1.1. **So why the heck are we still talking about it??** Ron At 08:26 PM 10/12/2011, Ronald G. Ross wrote: My 2 cents, below like this ... At 06:30 PM 10/12/2011, Ed Barkmeyer wrote: Donald Chapin wrote: Attached is an updated draft resolution to Issue 13138 that incorporates yesterdayâs feedback from Mark, Ed and Don. Not that it matters really, but these are my comments on the draft of 12 Oct Change 2. extension is completely known This is very strange. 'extension' is a role of set, but a set can be the extension of any number of concepts. What is intended here is either '_set_ /is completely known/' or '//_concept_ /has completely known extension/'. That is, the intent is that an instance of type 'set' will be identified by a definite description as the extension of a specific concept. So either, 'set' is the range of the subject, or 'concept' is the range of the subject and the reference to its extension is part of the verb phrase. That said, for the reasons I put forth in my email to Mark, I don't think that the given definition is of any use to business. One possible interpretation is that if you are part of the semantic community that uses the concept, you must know what its extension is. If you don't know the extension, you shouldn't be using the term. An alternative interpretation is that the community as a whole knows all the elements of the set, but there may be no individual who does. If you want to know all the members of the set, you may have to ask all the members of the community. The only version of this fact type that is useful to business is a binary fact type that identifies a 'party' (person or organization) as a source of the information as to what all the elements of the set are. And it has nothing to do with replacing 'concept is closed in fact model', which says that the fact model -- a specific resource -- specifies all the elements of the extension. There is no relationship between 'resource specifies extension' and 'community knows extension'. (Note: I don't care one way or the other if you keep or toss 'record', but I sure don't think it will help business or the acceptance of SBVR to create 'community knows extension' and try somehow to use it as a substitute.) Either I am completely confused (very possible), or I agree with Ed, or I'm completely confused *and* I agree with Ed. There are some other possibilities, but not worth going into here. * The only thing that is of any real-world value here is whether something is completely *specified*. How would you ever *know* that all the knowable thingees of some kind are known? ... "We know that we know what they all are ... and we're very sure about that ... even though we don't know for sure who knows which ... and of course, we've never asked about it, or recorded them, because you'd have to use words or signs to do that." To me this is looking down a rabbit hole(!). * What's useful for business purposes is to say that all the knowable thingees of some kind **have been specified". Some specified list(s) of them is/are complete. What kinds of thingees could those be? * The obvious kind is general concepts. * But business people want to have assurance that other things have been specified completely and are trustworthy in that respect. (This is partly a CYA thing.) For example, Mark wants the IBM personnel directory to be trustworthy as 'complete'. That's an example of Ed's 'record'. * Ron would want any rulebook to be specified completely (not necessarily published and distributed that way). * I suspect Donald would want any terminological dictionary to be specified completely (ditto). * What are examples of "record", "rulebook" and "terminological dictionary" respectively? Not employees, rules, or terms, but records, rulebooks and terminological dictionaries. * And in all three cases they are more than sets or lists. They are *aggregations* ... or if you prefer, *aggregate specifications*. Change 3. use of conceptual schema and fact model in conformance This is totally inappropriate. I agree entirely ... but, not understanding Ed's justification entirely, I'll have to object on other grounds. SBVR is "Semantics of Business Vocabulary and Business Rules". (Stop me if I make a mistake here.) So the 'units' of inter-operability should be things recognizable as ... uh ... business vocabulary and business rules. "Conceptual schema" and "fact model" are unrecognizable in that regard. How about ... let's see ... something having to do with terminological dictionaries or rulebooks? O.K., our ambition is to support some additional forms of semantic communication ... so maybe some more general concept like .... uh .... business communication. The serious point here is ... Let's refocus on the *business purpose* of SBVR. That's ultimately the key to its acceptance (and elegance). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Having said all that, two things are obvious: 1. None of this has anything to do with states of affairs, which we agreed would be the focus of 1.1. 2. We are not going to resolve al this in time for 1.1. **So why the heck are we still talking about it??** This would be the first time that any concept defined in clause 10 is explicitly used as an SBVR construct, and of all things, what is said to be the logical foundation is used in specifying the physical representation of the SBVR concepts. Clause 10 is supposed to be the formal background for terms used in SBVR concept definitions that are not part of the SBVR concept set itself. There is nothing wrong with the unstyled use of those terms in clause 13. But conformance must be stated in terms of concepts that are part of the SBVR concept set or part of the 'exchange concept set' that is introduced in clauses 13 and 15. Further, the concept 'fact model' is defined (in 8.5) as "combination of a conceptual schema and, for one possible world, a set of facts (defined by semantic formulations...)". This doesn't define 'fact model' to have any formal logic meaning at all. It is just some set of propositions that are true in the possible world. In formal logic, one talks about 'theories' and 'postulates'. A possible world is postulated by a set of 'postulates' (facts). Everything we can know about that world is based on the applicable theory (the conceptual schema?) and the set of postulates. 'Postulate' is a role of 'fact' that is an a priori assertion that is part of characterizing the possible world before inferencing. So, is a fact model the set of postulates that characterizes a possible world? Or just a bag of propositions that are assumed to be true in some unidentified possible world, possibly along with others that may come from another source? Does the set of facts identify the world, so that a larger set of non-redundant facts identifies a different world? The useful formal logic concept is 'the set of postulates (facts) that characterizes a possible world'. My impression is that SBVR treats 'fact model' as a bag of propositions that are taken to be true, and that is not a formal logic notion. If that is the case, it is purely a clause 13 idea -- it is just a packaging concept, and the clause 10 concept is 'possible world'. (BTW, this problem is not new with SBVR. UML had the same problem until the idea 'model' was introduced in UMLv2.) -Ed "I call that 'slop', the first big step on the road to the depths of degredation" (followed by a sequence of non sequiturs) - Meredith Wilson, "Trouble", from "The Music Man" -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info [attachment "Aggregations + Containers + Closed + Record v1.doc" deleted by Mark H Linehan/Watson/IBM] Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info Aggregations + Containers + Closed + Record v2.doc 11.x.x. Aggregations of Meanings and Representations Aggregation of representations is the unit of interoperability for SBVR. [Note: .Aggregation. should be used in place of .container. in SBVR discussions.] 11.x.x.1 Aggregations aggregation of meanings Definition: an assemblage of meanings Dictionary Basis: MWUD 2 : a group, body, or mass composed of many distinct parts : ASSEMBLAGE aggregation of representations Definition: an assemblage of representations Dictionary Basis: MWUD 2 : a group, body, or mass composed of many distinct parts : ASSEMBLAGE Note: An aggregation of representations is sometimes, but not always, based on a partial or complete list of the members of some particular set, often but not always with expression of additional facts. aggregation of representations is specified completely Definition: the aggregation of representations officially identifies every member of a set Note: Any thing that is not explicitly identified in the aggregation of representations can be assumed not to be a member. Note: Since SBVR assumes an open world, in cases where the company thinks it can close some set, it needs to make special allowance for people to act presuming as much. aggregation of representations is authoritative starting date-time throughuntil date-time Note: There will be no sanction during the time period for people acting as if it were authoritative. Note: Date-time gives .shelf life.. Example (from Ed): The product catalog for 2012 may be issued in December, be authoritative as of Jan. 1, and remain as the authoritative specification for exactly onea year. aggregation of representations is as of date-timeimmutable Note: A snapshot of facts (and rules) at a point in time is highly desirable for compliance, legal protection, traceability and other purposes. Note: Can be used to retain versions. 11.x.x.2 Aggregations of Meanings body of shared meanings Definition: set of concepts and elements of guidance for which there is a shared understanding in a given semantic community [Second More General Concept: aggregation of meanings] 11.x.x.3 Aggregations of Representations specification of extension Definition: the set of representations for the extension of a concept [Second More General Concept: aggregation of representations] terminological dictionary Definition: collection aggregation of representations including at least one designation or definition of each of a set of concepts from one or more specific subject fields, together with other representations of facts related to those concepts Source: based on ISO 1087-1 English (3.7.1) [.terminological dictionary.] Reference Scheme: a URI of the terminological dictionary rulebook Definition: the set aggregation of representations determined by a given speech community to represent in its language all meanings in its body of shared meanings Synonym: representation set Reference Scheme: the speech community that determines the rulebook record Definition: an aggregation of representations whose primary purpose is to document or report fact(s) Dictionary Basis: MWUD 2b(3): a body of known, recorded, or available facts about something : the sum of something done or achieved or the body of data known, recorded, or available about something Examples (from Ed): the DUNS registry, a general ledger, a shipping manifest, an employee phone book, a product catalog, a team roster, an approved supplier list instrument Definition: an aggregation of representations whose primary purpose is to document or report an official business accord or action Dictionary Basis: MWUD 5a : a legal document (as a deed, will, bond, lease, agreement, mortgage, note, power of attorney, ticket on carrier, bill of lading, insurance policy, warrant, writ) evidencing legal rights or duties especially of one party to another b : something capable of being presented as evidence to a court for inspection c : an act recorded in writing by a notary : a notarial act Examples: contracts, agreements, MOUs, deals, certifications, warranties, etc. communication Definition: an aggregation of representations whose primary purpose is to inform, question or notify some business party/ies concerning some matter of interest Dictionary Basis: MWUD 2b: a letter, note, or other instance of written information Example: renewal notice, confirmation of appointment ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~` 11.2.2.3 Business Content of a Communication Sections and Subsections sectioncommunication content Definition: representation that is a subdivision of an aggregation of representations written composition that consists of one or more statements and deals with one point or gives the words of one speaker Source: MWCD (1a) Dictionary Basis: MWUD 2 : a distinct part or portion of a writing: as a : a subdivision of a chapter (as a paragraph or a series of paragraphs not separated by a heading) b : a division of a law, statute, or legislative act c : a distinct component part of a newspaper *the sports section* Synonym: message content Synonym: document content document content See: communication content message content See: communication content communication content section is composed of representation Concept Type: partitive fact type [Question: Don.t we use .is included in. for partitive fact types?] subsection [Note: A subsection is a section included in another section. A definition / definitional rule in SBVR-SE needs to be worked out for that.] Dictionary Basis: MWUD 2: a subordinate part Date: Thu, 13 Oct 2011 13:21:17 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9DHLMl1006295 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1319131285.42909@bUiPqHTXISUfLk7VEFVOUQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark/Donald, Given the proposed text about known extensions, is the following a legitimate use? There is a concept called "Fred's sales calls" The extension of Fred's sales calls is known. Therefore, I don't need to tell you about any of them. (signed) Fred Similarly, there is a concept 'boy in the band' John is a boy in the band Paul is a boy in the band. The extension of 'boy in the band' is known. You have to pay the band. Do you have to pay George? Well, since the extension of 'boy in the band is known', you must know whether George is in the band or not. Now, if your software has to actually process the invoice from George, and decide whether to further it for payment or reject it, how does it use this communal knowledge? Is this fact type useful to business? -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Yahoo-Newman-Id: 321238.51103.bm@smtp101.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: w9__TfAVM1lHIBUjIYpdWmUw_cSM7UPvzmGL2.un2GtlGzG xVLeN2AuxtldEHYpzUR4ehNvQnHgVon2xRh67JPByz_I3bO6JvktuFJXEPh6 P8q5JNk12lqosGBd1SDLo.5IdiYzj3K9OHe4dKJouGSoXkVZDbSdBGsjaQCR CxLXpRYu4v1JUV6j63Q4h4yKhkCajiSs491fLlProR7U_tnwq8FBRbcltf4_ V7qqmV9U4a4vBBjfWc00RP0_EKp0hHHNzerrAdTUFqjhWw2PL2UENy0MDJCp asby06JmbPb8n7DzX2pPIeoGIPvKOl4UM.EJ3aasbeeqZwd2DycsjuRLAwAU JTE829Zz0DpChQwUeZ6epqjF6Le4iwOE6alZtr7AnSJhcauzrUlZ1aaENeQj ZX2HgJqoREMXodcPV_m8v7YDop4O_XaDAYsY.m.lxGHUIjoya2NnblvO3uWz KeqYiJ5GXD8r1xg6S3Y.kZkdrF9Cla4Qb6SiiFrOE1jkbeWuKri1rnKJ8MYB F.Z7hRNGh4wiJ.KpsouJ.le2e6XCIvEwAE5kP544l5N8yqj4v1p4tzl5D66Y 3o1CGu.mMdtGa_qjLSal51z2K0BUkrMWJiCFF7PnILCAqJMLOJ3PCfwy6ZAo GqllnvyUALszbk2LtQFSmgjbAeojlgjaRM1InbM1P1W31NNUbjS6u4OxMfVw d4bwykIJPcnNmM1jX X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Oct 2011 12:29:28 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution At 08:18 AM 10/13/2011, Mark H Linehan wrote: Comments: 1) Whether we call these things "aggregations" or "containers" or "collections" makes very little difference to me. But we already have the concept "set". Why not use that? Mark, I am sure that in "aggregations of representations" the same fact or representation could be included more than one time for whatever reason. Example: The same fact could appear in both a summary section and a detail section. I'm pretty sure there are many other examples ... just haven't thought about it. I'll leave the question about "aggregations of meanings" being sets in more qualified hands ... Ron Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info To: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-KeepSent: F7A0D1D3:BFE45BD0-85257928:005F009B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 13 Oct 2011 13:36:35 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/13/2011 13:36:36, Serialize complete at 10/13/2011 13:36:36 x-cbid: 11101317-6078-0000-0000-000001BA4736 Sigh, MHL>> I think further comments are needed ... -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/13/2011 12:50 PM Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Mark H Linehan wrote: > I still think the "completely known" characteristic should be about > sets, not about extensions of concepts. > > a) Despite what Ed says, there is nothing in SBVR that says or > implies that a set is "complete". SBVR's "open world" default means > that the extension of a concept is not "completely known". Since > "extension" is just a role of "set", the "open world" default must > mean that a set is by default open. No. It means we may not know, or even be able to know, which set it is. There is no such thing as a 'set that is open'. The Open World Assumption means that for a given concept C, the proposition "there exists a thing x, such that x is an instance of C" may not be provably true or provably false; it could be true but not provable. ("There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Or in this case: provable in your theory.) The Closed World Assumption is that if you can't prove that it is true, then it /is false/. Using the 'boys in the band' example, knowing that John, Paul, George and Ringo are instances of 'boy in the band' doesn't give us a way to prove that "there exists a person p such that p is a boy in the band, and p is not John and p is not Paul and p is not George and p is not Ringo" is false. That string of ands defines a concept whose instantiation is neither provable nor disprovable. So we don't know whether the extension of 'boy in the band' is the set {John, Paul, George, Ringo} or some other set that has those elements and others. That is the OWA. Put another way, "adding to a set" is like "adding to a number" -- the result is a different set. It has some relationships to the set you started with, just as 3 has some relationships to 2, but it is a different thing. > b) I think we often talk about sets using definite descriptions, not > terms. There should be a way to say that a set whose intention is > given by a definite description is "completely known". As an example, > the set of roads that are maintained by the Town of Yorktown is > completely known to the Town. Yes. A definite description is the definition of a concept, always. Thus you are referring to the set by a definite description of the set -- it is "the extension of the concept 'road that is maintained by the Town of Yorktown'". We call the concept 'road that is maintained by the Town of Yorktown' the "intension" of the set. The intension is not the description of the set, it is the description of each member of the set: A thing R is in the set if and only if R is a 'road that is maintained by the Town of Yorktown'. Again, this is about making careful distinctions between common English usage and the formal meaning of that usage. MHL>>We certainly agree about the need for "careful distinctions". MHL>>I believe this debate is related to the new "unitary concept" concept. MHL>>"the set of roads that are maintained by the Town of Yorktown" MHL>>has at most one instance. Ed says that the instance changes from one set MHL>>to another set. Technically that may be true in some reasoning schemes. MHL>>I think most people would say that "the set of roads ..." MHL>>is what changes when the Town officially drops or adds a road to the set. MHL>>I don't think this is worth further debate. > > --------------------------- > > I disagree with the removal of the example about closure of the > concept "rental". I think it's a great example and should be reworked > using the new characteristic. Here's what the example means to me: > > * There is a semantic community consisting of EU-Rent and its > customers. This community shares the concept "rental". By default, > the concept "rental" is NOT "completely known" within this community. Well, if EU-Rent is in the community, and EU-Rent knows who all of its actual customers are, then it seems to me that the concept 'rental' must be completely known "within" the community. What you mean is that it is not completely known by every member of the community. Do you intend to define "is completely known" to mean "is completely known by every member of the community"? MHL>>What I mean is that this community shares the concept "rental" but not the fact MHL>>that asserts that the extension of the concept is "completely known". > * There is a different semantic community consisting of EU-Rent only. > The fact " 'rental' has completely known extension" is asserted for > this community. This means that EU-Rent knows all instances of the > concept 'rental' and EU-Rent can definitively decide whether an > instance is a 'rental' or not. > * EU-Rents customers (on the other hand) do not know about all rentals > and thus cannot decide whether a given instance is a rental. Agree. This is a clear example. Now, what is the relationship of these distinct communities to the concept 'rental'? If it is only completely known by the EU-Rent internal community, the fact model that declares the extension to be completely known is not a fact model that is used by the customers. Which means that the fact type cannot be used in a customer fact model to say that the EU-Rent folk know the extension. If you don't know, you are not in the community to which the fact model applies, and you can't say who does know. MHL>>I meant for this second community to be a sub-community of the first, via "community MHL>>has subcommunity". So that they all share the concept "rental" but only the EU-Rent MHL>>subcommunity has the "completely known" fact. MHL>>I do not see a reason why "a customer fact model [needs to] to say that MHL>> the EU-Rent folk know the extension". I think a customer fact model will be mostly about MHL>>what the customer knows, not what EU-Rent knows. In the rare case where the customer MHL>>wants to say that EU-Rent knows things that the customer doesn not know, the customer MHL>>can have verb concepts and facts about that. > There is a problem with this example, which Ed pointed out: presumably > a customer does know about its _own _rentals. To support this, we > could try to extend the example by adding " 'renter is responsible for > rental' has completely known extension" as a fact in the semantic > community of EU-Rent and its customers. But this still doesn't quite > satisfy the need (as Ed also pointed out): we don't want to say that > every customer knows about all the rentals of _all _the customers > (which is what "has completely known extension" means). So I suggest > that we add another verb concept: > > *_role_** **/in/** _verb concept_** **/has completely known extension/* > Definition: each _instance_ that plays the _role_ is known by > the _semantic community_ that /shares the understanding of/ the _verb > concept_ if and only if each other _role _of the _verb concept_ is > known by the _semantic community_ > > Given this additional concept, the semantic community consisting of > EU-Rent + its customers could assert a fact " 'rental in customer has > rental' has completely known extension'. The intended meaning is that > if a customer is known then the customer's rentals are known. This is analogous to one of the other closure rules for the conceptual schema. It essentially asserts that every involvement of a thing in a given fact type role is explicit in the fact model. But again, that is about fact models -- explicit bodies of information -- not about communities knowing information. Knowing assists the knower in making decisions. It doesn't help anyone else if s/he doesn't also communicate the knowledge. So saying that someone unspecified knows doesn't provide any useful information. MHL>>The intent is to say that everyone in the semantic community that asserts the fact knows. MHL>>Not "someone unspecified". Saying that everyone knows means you are not a part of the community if you don't, which is only useful information in a very different way. MHL>>Yes, that is a consequence of stating a "completely known" fact. People or organizations MHL>>that don't know about all of EU-Rents rentals are definitely not part of EU-Rent. Back to Ron's question: Why are we talking about this? MHL>>That's a question for Donald, not me. He sets the agenda. -Ed 2 is not equal to 3 - not even for very large values of 2. - Grabel's Law > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > > > From: "Donald Chapin" > To: > Date: 10/13/2011 08:42 AM > Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft > Resolution (2011-10-13) > ------------------------------------------------------------------------ > > > > > Attached is an updated draft resolution to Issue 13138 that > incorporates yesterdayâs feedback. > > > [attachment "Draft Resolution for Issue 13138- 2011-10-13.doc" > deleted by Mark H Linehan/Watson/IBM] -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-13_05:2011-10-13,2011-10-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110130205 Subject: Re: [containers and bigger problems] RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution From: keri Date: Thu, 13 Oct 2011 11:55:26 -0700 Cc: sbvr-rtf@omg.org To: Donald Chapin X-Mailer: Apple Mail (2.1084) On Oct 13, 2011, at 1:49 AM, Donald Chapin wrote: Ron, The resolution of the Issues you listed below depends on the resolution of Issue 13138. I included Issues 12540/41 (which were submitted as one Issue) in the list of seven critical issues Keri recently requested. To be clear, I requested that a list of the items critical to 1.1. be provided ... NOT that any listed items be deemed "critical". So there is agreement that there are important. Actually, I don't agree. I looked back through the notes to see where the "seven" arose from. In the minutes (from Sept. 22) I found a list of seven that seems to be this list. This is how they were then characterized: "The most important Issues from the point of view of facilitating and gaining agreed Issue Resolutions is a reasonably efficient and expeditious manner are the 7 (exisitng already triaged) Issues in today.s meeting agenda." I do not recall (or see supported by the notes) that we discussed/voted on the criticality of these items, individually, for their role in 1.1 completion. IAC, we are now where we are. I suggest we spend some time at the beginning of tomorrow's meeting taking stock of how we have progressed since Sept. 22 and what we now assess as the criticality for 1.1 of each remaining item vis-a-vis the likelihood of reaching a resolution of that item in time for our Dec. target. Here is the list of 7 that I captured from the Sept. 22 agenda. If this is not THE "seven" please adjust the list accordingly: 1. Issue 13138 .Move Fact Model Container Concepts from Clause 8 to Clause 10 2. Issue 13835 .Use of Signifier.Fact Model.. 3. Issue 10577 .Need to be Able to Distinguish between Concepts that have No Instnaces in an SBVR Model and Thaose that Do. 4. Issue 16526 .Definition of Proposition. 5. Issue 16486 .Relationships between States of Affairs. 6. Issue 14849 .Instances of Clause 8 fact type should be states of affairs. 7. Issues 12540/41 .SBVR Currently has Multiple Concepts for Organizing Vocabularies and Rules. ~ Keri Donald X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-13_05:2011-10-13,2011-10-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110130213 From: keri Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) Date: Thu, 13 Oct 2011 12:19:25 -0700 To: Donald Chapin , sbvr-ftf@omg.org X-Mailer: Apple Mail (2.1084) On Oct 13, 2011, at 5:35 AM, Donald Chapin wrote: Attached is an updated draft resolution to Issue 13138 that incorporates yesterday.s feedback. As I understand the point of this far-ranging discussion it is to put something in place, in business-facing Clause 11 terms, that will replace what will be lost when two fact types are moved from Clause 8.5 into Clause 10 -- the fact types: fact type is internally closed in conceptual schema and concept is closed in conceptual schema . (Is that correct? If not, please clarify.) In this latest Resolution, Donald has written up the addition of a fact type "concept has completely known extension" - with notes and examples that strive to make this a business-facing equivalent. For the sake of our 1.1 scope can we please focus on that question alone -- "is this adequate to reflect what business folks need for this notion?" (What simple, straightforward improvements, if any, might be made?) Alternatively, we might decide that nothing needs to be added for business purposes (and the items can simply move into Clause 10). IOW, keep it simple. The farther-ranging questions, including the very interesting points Ed has raised which could improve some of the "communication content" items, can be continued in our 1.2 work. ~ Keri To: sbvr-rtf@omg.org Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-KeepSent: ADFC0DAF:3016E1C9-85257928:0071D71C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Thu, 13 Oct 2011 16:51:02 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/13/2011 16:51:04, Serialize complete at 10/13/2011 16:51:04 MHL>> My answers like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/13/2011 01:26 PM Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Mark/Donald, Given the proposed text about known extensions, is the following a legitimate use? There is a concept called "Fred's sales calls" The extension of Fred's sales calls is known. Therefore, I don't need to tell you about any of them. (signed) Fred MHL>>I'm not sure what the question is about the example given above. MHL>>It appears that the example is a letter directed, but there's no indication MHL>>who it is directed. More importantly, are Fred and the addressee in the same MHL>>semantic community? If they are, then the line "The extension of Fred's sales calls is known" MHL>>makes sense to me. If they are not in the same semantic community, then MHL>>this line is not very meaningful. Similarly, there is a concept 'boy in the band' John is a boy in the band Paul is a boy in the band. The extension of 'boy in the band' is known. You have to pay the band. Do you have to pay George? Well, since the extension of 'boy in the band is known', you must know whether George is in the band or not. MHL>>Yes. Now, if your software has to actually process the invoice from George, and decide whether to further it for payment or reject it, how does it use this communal knowledge? MHL>>The software operates within or on behalf of the semantic community for which MHL>>the "is known" statement is made -- right? After all, the software just automates MHL>>what otherwise could be done by hand, so it should have the same knowledge that MHL>>"I" have. So what's the issue? It seems obvious that the software will consult the MHL>>extension of "boy in the band" to decide whether George is in the band, and MHL>>pay or not based on the result of that consultation. Is this fact type useful to business? MHL>>I think so. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-13_06:2011-10-13,2011-10-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110130278 Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) From: keri Date: Thu, 13 Oct 2011 15:34:04 -0700 Cc: sbvr-rtf@omg.org To: Mark Linehan , Ed Barkmeyer X-Mailer: Apple Mail (2.1084) Mark, Ed, Did these same questions arise for the fact types: fact type is internally closed in conceptual schema and concept is closed in conceptual schema ? If Donald's proposed replacement fact type were worded "concept is closed in body of shared concepts" would these questions still apply? ~ Keri On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: MHL>> My answers like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/13/2011 01:26 PM Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Mark/Donald, Given the proposed text about known extensions, is the following a legitimate use? There is a concept called "Fred's sales calls" The extension of Fred's sales calls is known. Therefore, I don't need to tell you about any of them. (signed) Fred MHL>>I'm not sure what the question is about the example given above. MHL>>It appears that the example is a letter directed, but there's no indication MHL>>who it is directed. More importantly, are Fred and the addressee in the same MHL>>semantic community? If they are, then the line "The extension of Fred's sales calls is known" MHL>>makes sense to me. If they are not in the same semantic community, then MHL>>this line is not very meaningful. Similarly, there is a concept 'boy in the band' John is a boy in the band Paul is a boy in the band. The extension of 'boy in the band' is known. You have to pay the band. Do you have to pay George? Well, since the extension of 'boy in the band is known', you must know whether George is in the band or not. MHL>>Yes. Now, if your software has to actually process the invoice from George, and decide whether to further it for payment or reject it, how does it use this communal knowledge? MHL>>The software operates within or on behalf of the semantic community for which MHL>>the "is known" statement is made -- right? After all, the software just automates MHL>>what otherwise could be done by hand, so it should have the same knowledge that MHL>>"I" have. So what's the issue? It seems obvious that the software will consult the MHL>>extension of "boy in the band" to decide whether George is in the band, and MHL>>pay or not based on the result of that consultation. Is this fact type useful to business? MHL>>I think so. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: "Donald Chapin" To: "sbvr-rtf " Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-14) Date: Fri, 14 Oct 2011 12:09:32 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyKYb/LyIRfy0PGSxWNuRJxZnBXWA== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E981871.0010, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.14.95414:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __FRAUD_CONTACT_NAME, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_90_100, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E9818F5.0126,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 From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: 13 October 2011 13:35 To: sbvr-ftf@omg.org Subject: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) Attached is an updated draft resolution to Issue 13138 that incorporates yesterday.s (Thursday.s) feedback. Draft Resolution for Issue 13138- 2011-10-14.doc Disposition: Resolved OMG Issue No: 13138 Title: Move fact model container concepts from Clause 8 to Clause 10 Source: Business Semantics Ltd, Donald Chapin, (Donald.Chapin@btinternet.com) Summary: In resolution of Issue 12540 (Clause 8 does not include the concepts needed to represent itself) it was recognized that subclause 8.5 defines containers that are not part of the SBVR metamodel, but are relevant to the formal semantics concepts in Clause 10. They would be more appropriately placed in Clause 10. Resolution: 1. Sub-clause 8.5 is, for all practical purposes, disconnected from the rest of Clauses 7, 8, 9, 11 & 12 in that the terms (i.e. conceptual schema, fact model) defined in Sub-clause 8.5 are hardly used at all in Clauses 7, 8, 9, 11 & 12, and none of those uses are styled. Conversely Clause 2 .ScopeConformance. and Clause 13 .SBVR.s Use of MOF and XMI. make high use of the terms defined Sub-clause 8.5. The vocabulary entries in Sub-clause 8.5 are moved to the context where they are used normatively i.e. in Clause 13. 2. The .closed in fact model. concepts in clause 8.5 could be read to include a .business-oriented ability to specify the availability of knowledge about instances of SBVR concepts.. To preserve this function when Clause 8.5 is moved to Clause 10, add a characteristic to concept that specifies this. 3. Clarify that the uses of .conceptual schema. and .fact model. in Clause 2 .Conformance. refer to their use in Clause 13 .SBVR.s Use of MOF and XMI. as defined in Clause 13.7 4. Make clear that the uses of .conceptual schema. and .fact model. in Clause 13 .SBVR.s Use of MOF and XMI. are as defined in Sub-clause 13.7 5. Clarify that the Sub-clause 8.6.2 necessities are about the distinction between what is in the SBVR model and what is the Universe of Discourse of the SBVR Model. Revised Text: 1. Move Sub-clause 8.5 a. MOVE the entire Sub-clause 8.5 as is to Clause 13 as a new Sub-clause 13.7 .Conceptual Schemas and Models.. b. REMOVE all styling on all text within the entry headings and subentries in Sub-clause 13.7. c. REMOVE the diagram (currently Figure 8.8) from Sub-clause 13.7 c.d. REMOVE the .FL. markings on all the entries in Sub-clause 13.7 d.e. REMOVE the following example sentences from the Note under .concept is closed in conceptual schema. in Sub-clause 13:.7 as it doesn.t make business sense. Ed Barkmeyer pointed out in one of his emails that the corporate customer has only its own rentals in its universe of discourse, .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 concept .rental. as not closed because the customer is not aware of all rentals, but EU-Rent.s conceptual schema has the concept as closed.. e.f. REMOVE the item .5. Conceptual Schemas and Models. from the list of subjects at the end of the introductory paragraphs of Clause 8 on printed page 18 2. ADD the following entry to Clause 11.1.1 directly after .semantic community shares understanding of concept.: concept has completely known extension Definition: each instance in the extension of the concept is known by the semantic community that shares the understanding of the concept Note: The means and source of .completely knowing. is outside the scope of SBVR. It could be knowledge that people have; it could be recorded information; and/or it could be direct observation. All that this characteristic asserts is that all the instances in the extension of the concept are completely known -- as in .taken to be true. or .believed to be a fact.. Errors in the recorded data or knowledge and observations of people are outside the scope of SBVR. Note: If this characteristic is not specified for a given concept, is it assumed to be .false. by default as per SBVR's normal 'open world' semantics. Note: Under SBVR's normal 'open world' semantics, there could be instances in the extension of the concept that exist but are unknown. "Concept is completely known" reverses the 'open world' assumption with respect to the concept. If a concept is completely known, then an existential quantification such as "if there does not exist an instance of the concept that " can be relied upon to conclusively determine that there is no instance that meets the given condition. Example: .is completely known. is specified as a metafact for the concept .rental. in the SBVR Terminological Dictionary contain it. Example: In EU-Rent, the extension of the concept .rental customer. is completely known, but the extension of the concept .person interested in discounted weekend rental rates. is not. Note: Often, different kinds of business process are needed for dealing with known populations and populations that are unknown or only partly-known. EU-Rent can recognize that a person is a rental customer, but has to find out more about a person in order to decide whether he/she is interested in discounted weekend rental rates. 3. Clarify that the uses of .conceptual schema. and .fact model. in Clause 2 a. ADD the following as the third paragraph immediately following the Clause 2 .Conformance. heading: .All references to .conceptual schema. and .fact model. in this clause are references to their use in Clause 13 .SBVR.s Use of MOF and XMI. as they are defined in subclause 13.7.. b. REPLACE the first paragraph in Sub-clause 2.3 .Conformance of an SBVR exchange document.: .An exchange document that conforms to this specification (an .SBVR exchange document.) shall be an XML document that represents a .fact model. as defined in subclause 8.5.. WITH .An exchange document that conforms to this specification (an .SBVR exchange document.) shall be an XML document that represents a .fact model. as used in Clause 13 .SBVR.s Use of MOF and XMI. and defined in subclause 13.7.. c. REPLACE at the end of paragraph 2 under .EXAMPLE. in Sub-clause 2.3: .(see 8.5). WITH .(see subclause 13.7). 4. ADD the following at the end of last introductory paragraph of Clause 13.1.2 .SBVR.s Use of MOF and XMI.: All references to .conceptual schema. and .fact model. in this clause are as defined in subclause 13,7. 5. REPLACE the last two sentences in the introductory paragraph to Sub-clause 8.6.2 .Necessities Concerning Extension.: Other necessities stated in the context of the Meaning and Representation Vocabulary concern the contents of conceptual schemas and their representations. But the following necessities concern each fact model in relation to the conceptual schema that underlies it. WITH Other necessities stated in the context of the Meaning and Representation Vocabulary concern meanings and their representations. But the following necessities are about the correspondence of meanings to things in the universe of discourse. Disposition: Resolved To: sbvr-rtf@omg.org Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-KeepSent: 73040252:9595503D-85257929:003DBDCC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Fri, 14 Oct 2011 07:19:51 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/14/2011 07:19:52, Serialize complete at 10/14/2011 07:19:52 Good question. My answers, which are probably not the same as Ed's: * Specifying the "conceptual schema" or the "body of shared meanings" is not the same as the "WHERE" in Ed's email. He means the "record" where the information is stored -- which is not the same as the "conceptual schema" or "body of shared meanings". * My understanding is that when you define a terminological dictionary, the "body of shared meanings" is implied. In Structured English, you define a "vocabulary" concept and then the following glossary entries belong to that vocabulary. I think the same mechanism can apply to facts asserted as I have suggested. That eliminates the need to explicitly mention the "body of shared meanings". (Actually, the start and end of the glossary entries for a vocabulary are delimited by a horizontal line in SBVR and in Date-Time -- but that is not documented in Annex C.) -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: keri To: Mark H Linehan/Watson/IBM@IBMUS, Ed Barkmeyer Cc: sbvr-rtf@omg.org Date: 10/13/2011 06:34 PM Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Mark, Ed, Did these same questions arise for the fact types: fact type is internally closed in conceptual schema and concept is closed in conceptual schema ? If Donald's proposed replacement fact type were worded "concept is closed in body of shared concepts" would these questions still apply? ~ Keri On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: MHL>> My answers like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/13/2011 01:26 PM Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Mark/Donald, Given the proposed text about known extensions, is the following a legitimate use? There is a concept called "Fred's sales calls" The extension of Fred's sales calls is known. Therefore, I don't need to tell you about any of them. (signed) Fred MHL>>I'm not sure what the question is about the example given above. MHL>>It appears that the example is a letter directed, but there's no indication MHL>>who it is directed. More importantly, are Fred and the addressee in the same MHL>>semantic community? If they are, then the line "The extension of Fred's sales calls is known" MHL>>makes sense to me. If they are not in the same semantic community, then MHL>>this line is not very meaningful. Similarly, there is a concept 'boy in the band' John is a boy in the band Paul is a boy in the band. The extension of 'boy in the band' is known. You have to pay the band. Do you have to pay George? Well, since the extension of 'boy in the band is known', you must know whether George is in the band or not. MHL>>Yes. Now, if your software has to actually process the invoice from George, and decide whether to further it for payment or reject it, how does it use this communal knowledge? MHL>>The software operates within or on behalf of the semantic community for which MHL>>the "is known" statement is made -- right? After all, the software just automates MHL>>what otherwise could be done by hand, so it should have the same knowledge that MHL>>"I" have. So what's the issue? It seems obvious that the software will consult the MHL>>extension of "boy in the band" to decide whether George is in the band, and MHL>>pay or not based on the result of that consultation. Is this fact type useful to business? MHL>>I think so. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: "Donald Chapin" To: Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Date: Thu, 22 Sep 2011 12:30:07 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acx5GvraX+JglD2jTMKNopqhUD1Mtw== X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0303.4E7B1C42.00C7, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.22.103015:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __CTYPE_MULTIPART_MIXED, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, DOC_ATTACHED, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __OEM_SOFTWARE_5, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_50_70, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, OEM_SOFTWARE_X1, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4E7B1D1A.004C,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 a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald Draft Resolution for Issue 13138- 2011-09-21.doc From: "Donald Chapin" To: "'Mark H Linehan'" , "'Don Baisley'" Cc: "sbvr-rtf " Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Date: Thu, 29 Sep 2011 20:48:16 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDjDZT3ixhxN3T1Dk0ZiN4CsibJRgKS7jj/ATjaLFOXGUcjMA== X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0303.4E84CB81.00B0, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2011.9.29.183617:17:8.129, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __HIGHBITS, __OEM_SOFTWARE_5, SUPERLONG_LINE, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_70_90, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, OEM_SOFTWARE_X1, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4E84CB84.0053,ss=1,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 Mark, Can you create 2-3 example business rules each illustrating a different case of what you want to be SBVR supports with respect to âConcept in closed in .â. It will help us to focus on exactly what business rule capability is important to you. I would like to discuss at least one example in tomorrowâs SBVR RTF telecon. Many Thanks, Donald From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: 29 September 2011 12:33 To: Don Baisley Cc: Donald Chapin Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Hi, Don. Comments like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: Mark H Linehan/Watson/IBM@IBMUS Cc: Donald Chapin Date: 09/25/2011 05:59 PM Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution -------------------------------------------------------------------------------- Hi Mark, I understand that you have an interest in the âclosedâ fact types in SBVR 8.5, which seems to Donald and others (including me) to be a database/knowledge-base technique rather than a way to formulate business meaning. The big problem I see is that it introduces a competing way to structure meaning that is not part of semantic formulations and that works only part of the time. If my model has the fact, âThe sons of Don are Nathan and Joshuaâ, then I donât need to say âis closedâ about any concept because my fact is definite. But suppose I chose the âconcept is closedâ approach so that I can use multiple indefinite facts. 1. I make the fact type âfather has sonâ closed (or semiclosed) in my conceptual schema. 2. I use two facts: âNathan is a son of Donâ, âJoshua is a son of Donâ. And the 3rd fact that you give below. Does that really work? No, because I also have a fact that âAllen is a son of Markâ and I donât know whether Mark has any other sons. I think you must not understand the implication of making the fact type closed. It says that you know ALL the sons. By definition of "closed" there are none that you do not know. The only clean approach is to use semantic formulations to formulate ALL of the facts and not rely on database tricks. I don't see why this is a problem. If you have 3 facts for a closed concept, then clearly the 3 facts constitute the complete set about the concept. What's the issue? The âis closedâ stuff adds extra complexity for anyone wanting to do logical inferencing from SBVR models. It adds no capability because we can already be definite using semantic formulations. It adds more than complexity: It connotes a database perspective that, if I understand Donald correctly, is turning away potential adoption. I disagree that it adds no capability. Consider the query "list all the employees of IBM". If we mark "IBM has employee" as closed, then we can know that the result is a complete list. If we follow the usual open-world rules, then we have to assume that the list is incomplete. Consider government regulations that require IBM to provide W-2 tax statements for all IBM employees. How do we say that in SBVR. Notice that in an open world "for each" is universal quantification over the known instances, but there is no semantic meaning that "for each" reaches all instances. For this reason, I believe your statement "It adds no capability because we can already be definite using semantic formulations. " is wrong. We need adoption and correct placement in peopleâs perceptions more than we need a second way to be definite about extensions. We also need a way to represent both open world and closed world semantics. Regards, Don From: Donald Chapin [mailto:Donald.Chapin@BusinessSemantics.com] Sent: Thursday, September 22, 2011 4:30 AM To: sbvr-rtf@omg.org Subject: RE: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution Attached is a simplified, updated draft resolution for Issue 13138. Donald From: Juergen Boldt [mailto:juergen@omg.org] Sent: 04 December 2008 19:02 To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 13138 -- 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=Gv74ZHAeVkFOkUQS3HBAACstocyPztqQItbPYTKl9ygzR9CZ0RqiC21HItWUXbjAMjt5PVZLLqvxjxYtxIYCilDNrKjpUn8Jp9ZQgI+cQvN90nybDVO8xeyjG+ImJWw76bUMZcm/NUDCdOmw1JDm0EWcJ9aqx8Z4fHW+mK9JJvA= ; X-YMail-OSG: wHgROH8VM1nWIAUjXUaALS1AxJyB_P8NimYXYAYBkEFmiSQi56M4y5pxWt7PdApqp9GU1ZvmpDegK6XCBq0q0gDXWgQqHxVDgP1vLcZYLiGbEw11VQNnxovCzDA2P5Sv9GxW8CXvfLIGwl85ZU6nztmdMn6yOy0LfyN66ag- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: , Subject: SBVR Issue -- Move Fact Model Container Concepts from Clause 8 to Clause 10 (Spin-off from Issue 12540) Date: Thu, 4 Dec 2008 13:15:42 -0000 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclWEj6qd+4UwtfrRd2PY269guJlPQ== 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 11296-1a / 11303-b spin-off Issue which will be posted when it has a number. Donald Date: Fri, 14 Oct 2011 18:02:21 -0400 From: Ed Barkmeyer Reply-To: edward.barkmeyer@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: keri CC: Mark Linehan , "sbvr-rtf@omg.org" Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov keri wrote: Mark, Ed, Did these same questions arise for the fact types: *fact type is internally closed in conceptual schema * and *concept /is closed in /conceptual schema *? No. But it is a good question, because the answer is revealing. If a concept is closed in a conceptual schema, then every fact model that uses that conceptual schema explicitly identifies every instance of the concept. That is, there is a thing -- a fact model -- and that thing is the unit of communication between SBVR tools, any receiving tool can know that every instance of that concept in the possible world described by that fact model is explicitly identified as an instance of that concept in that fact model. The meaning of 'concept is closed in conceptual schema' provides a very clear way for software supporting SBVR to know exactly what set of things constitutes the extension of that concept. It explicitly says that you cannot 'share' ("exchange") the concept without explicitly sharing the specification of each of its instances. If the 'fact model' is taken to be a "meaning", then it is the body of knowledge about a possible world, which can be modeled as a set of facts about that world. In Mark's terms, that means that the person who conceives the possible world must know all of the instances of the concept, and have corresponding mental facts that correspond to those instantiations. But that creates a community of one person for the possible world. But the 'fact model' is also the unit of information exchange between SBVR tools, per clause 2. And the consequent requirement is that the exchange of a 'fact model' -- the representation of the fact model in XML -- must contain representations of all those facts, including all the instantiation facts. In that way, any recipient can also know exactly the set of things that is the extension of the concept in the possible world being described. The totality of clause 2 and clause 8.5 is not just that someone has to know the instances of the concept, but rather that s/he must express all those instances when s/he communicates about a possible world that makes use of the concept. In this area, SBVR is written to tie the conceptualization of the possible world (a meaning) to the expression of that conceptualization as a set of fact representations. The problems we are having arises from trying to do the usual SBVR thing of completely separating the meanings from their representations. Mark wants to treat the 'closure of a concept' as a requirement on meanings that is completely separable from representation. It is possible to do that, but the consequence is weird: it says that you cannot actually conceive a world in which you don't know all the instances of the concept. Now, I can conceive 'member of the SBVR RTF', as a concept directly applicable to writing this email, and I don't know all the members. So the requirement that 'member of the SBVR RTF is closed' ("is known") would appear to make it impossible for me to conceive a world in which I know anything about RTF members. What that really means is that I don't use that conceptual schema in conceptualizing the world in which I am writing this email. The conceptual schema I am using does not contain Mark's would be fact. But my conceptual schema, or perhaps just my internal fact model, does tell me that the RTF membership list is available at the OMG website, if I need to know. My concern is that we provide the means of saying that a representation of the possible world includes representations of all the instantiation facts for that concept, which is the most important half of what SBVR currently specifies. You can't exchange them if you don't know them, but you can know them and not exchange them (you can keep the knowledge to yourself). So, I can't properly describe the RTF to someone without saying who all the members are. Fair enough. I agree that my 'record' concept is really something more general than what SBVR can currently support, because it doesn't restrict the 'communication content' objects to being communications of complete fact models for possible worlds. The 'record' concept is not something that SBVR v1.0 has, and we probably should not be adding it in an RTF, and almost certainly not in response to Issue 13138. At the same time, I don't see that Mark's concept is any way faithful to the intent of 'concept is closed in conceptual schema'. And that is simply because 'concept is closed in conceptual schema' is not really about meaning; it is about the content of fact models in an SBVR exchange. It is a pragmatic declaration that provides certain implementation capabilities that the 'open world assumption' undercuts. Mark is putting lily-white gloves on hands that were intended to go in the dirt. If Donald's proposed replacement fact type were worded "concept /is closed in /body of shared concepts" would these questions still apply? Maybe. Note that the meaning is expressed in terms of fact models that conform to the conceptual schema. Do we have the idea that fact models conform to a body of shared concepts? The point here is that a 'fact model' is said to be a body of knowledge, but it is used as a body of knowledge that is *expressed* in a 'communication'. It appears that the SBVR term for an expressed body of knowledge is 'communication content', but there is no link between 'communication content' and 'fact model' or 'body of shared concepts'. How much would we have to add to SBVR to support: concept is closed in body of shared concepts Definition: For each _communication content_ that is based on the _body of shared concepts_, the communication content conveys a fact model that contains a set of facts that explicitly specify the entire extension of _concept_ Then clause 13 and 15 is about the construction of SBVR-conformant communication content, which conveys a fact model and is based on a body of shared concepts. And I suspect that the closure rule is only intended to apply to the kind of communication content that is described in clauses 13 and 15. All in all, I think the RTF was unwise to pull on the 13138 thread. -Ed ~ Keri On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: *MHL>> My answers like this.* -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer > To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org " > Date: 10/13/2011 01:26 PM Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) ------------------------------------------------------------------------ Mark/Donald, Given the proposed text about known extensions, is the following a legitimate use? There is a concept called "Fred's sales calls" The extension of Fred's sales calls is known. Therefore, I don't need to tell you about any of them. (signed) Fred *MHL>>I'm not sure what the question is about the example given above.* *MHL>>It appears that the example is a letter directed, but there's no indication* *MHL>>who it is directed. More importantly, are Fred and the addressee in the same* *MHL>>semantic community? If they are, then the line "*The extension of Fred's sales calls is known*"* *MHL>>makes sense to me. If they are not in the same semantic community, then* *MHL>>this line is not very meaningful.* Similarly, there is a concept 'boy in the band' John is a boy in the band Paul is a boy in the band. The extension of 'boy in the band' is known. You have to pay the band. Do you have to pay George? Well, since the extension of 'boy in the band is known', you must know whether George is in the band or not. *MHL>>Yes.* Now, if your software has to actually process the invoice from George, and decide whether to further it for payment or reject it, how does it use this communal knowledge? *MHL>>The software operates within or on behalf of the semantic community for which* *MHL>>the "is known" statement is made -- right? After all, the software just automates* *MHL>>what otherwise could be done by hand, so it should have the same knowledge that* *MHL>>"I" have. So what's the issue? It seems obvious that the software will consult the* *MHL>>extension of "boy in the band" to decide whether George is in the band, and* *MHL>>pay or not based on the result of that consultation.* Is this fact type useful to business? *MHL>>I think so.* -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." To: sbvr-rtf@omg.org Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-KeepSent: 7442F8F5:72C5570A-8525792C:006C0B35; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 17 Oct 2011 15:50:35 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/17/2011 15:50:38, Serialize complete at 10/17/2011 15:50:38 I don't agree with Ed's assertion that "In Mark's terms, that means that the person who conceives the possible world must know all of the instances of the concept, and have corresponding mental facts that correspond to those instantiations. But that creates a community of one person for the possible world." And "Mark wants to treat the 'closure of a concept' as a requirement on meanings that is completely separable from representation. It is possible to do that, but the consequence is weird: it says that you cannot actually conceive a world in which you don't know all the instances of the concept." Please note that defining a concept is independent of asserting a fact about the concept being "closed". One can do the former without the latter. For example, OMG can define the concept "SBVR-RTF" and say nothing about who knows or exchanges any information about the SBVR-RTF. OMG can then separately assert the "closed in conceptual schema" attribute of "SBVR-RTF" for itself, meaning that the OMG knows all the members of the SBVR-RTF but not that everyone else has that knowledge. In summary: Ed assumes that definition and assertion of the existing "concept is closed in conceptual schema" verb concept (or my proposed "completely known" characteristic) will be accomplished in one conceptual schema. I suggest that, in many useful cases, facts about closure of concepts will be done in subordinate conceptual schemas that are shared by a subset semantic community. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: keri Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" Date: 10/14/2011 06:07 PM Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- keri wrote: > Mark, Ed, > > Did these same questions arise for the fact types: *fact type is > internally closed in conceptual schema * and *concept /is closed > in /conceptual schema *? No. But it is a good question, because the answer is revealing. If a concept is closed in a conceptual schema, then every fact model that uses that conceptual schema explicitly identifies every instance of the concept. That is, there is a thing -- a fact model -- and that thing is the unit of communication between SBVR tools, any receiving tool can know that every instance of that concept in the possible world described by that fact model is explicitly identified as an instance of that concept in that fact model. The meaning of 'concept is closed in conceptual schema' provides a very clear way for software supporting SBVR to know exactly what set of things constitutes the extension of that concept. It explicitly says that you cannot 'share' ("exchange") the concept without explicitly sharing the specification of each of its instances. If the 'fact model' is taken to be a "meaning", then it is the body of knowledge about a possible world, which can be modeled as a set of facts about that world. In Mark's terms, that means that the person who conceives the possible world must know all of the instances of the concept, and have corresponding mental facts that correspond to those instantiations. But that creates a community of one person for the possible world. But the 'fact model' is also the unit of information exchange between SBVR tools, per clause 2. And the consequent requirement is that the exchange of a 'fact model' -- the representation of the fact model in XML -- must contain representations of all those facts, including all the instantiation facts. In that way, any recipient can also know exactly the set of things that is the extension of the concept in the possible world being described. The totality of clause 2 and clause 8.5 is not just that someone has to know the instances of the concept, but rather that s/he must express all those instances when s/he communicates about a possible world that makes use of the concept. In this area, SBVR is written to tie the conceptualization of the possible world (a meaning) to the expression of that conceptualization as a set of fact representations. The problems we are having arises from trying to do the usual SBVR thing of completely separating the meanings from their representations. Mark wants to treat the 'closure of a concept' as a requirement on meanings that is completely separable from representation. It is possible to do that, but the consequence is weird: it says that you cannot actually conceive a world in which you don't know all the instances of the concept. Now, I can conceive 'member of the SBVR RTF', as a concept directly applicable to writing this email, and I don't know all the members. So the requirement that 'member of the SBVR RTF is closed' ("is known") would appear to make it impossible for me to conceive a world in which I know anything about RTF members. What that really means is that I don't use that conceptual schema in conceptualizing the world in which I am writing this email. The conceptual schema I am using does not contain Mark's would be fact. But my conceptual schema, or perhaps just my internal fact model, does tell me that the RTF membership list is available at the OMG website, if I need to know. My concern is that we provide the means of saying that a representation of the possible world includes representations of all the instantiation facts for that concept, which is the most important half of what SBVR currently specifies. You can't exchange them if you don't know them, but you can know them and not exchange them (you can keep the knowledge to yourself). So, I can't properly describe the RTF to someone without saying who all the members are. Fair enough. I agree that my 'record' concept is really something more general than what SBVR can currently support, because it doesn't restrict the 'communication content' objects to being communications of complete fact models for possible worlds. The 'record' concept is not something that SBVR v1.0 has, and we probably should not be adding it in an RTF, and almost certainly not in response to Issue 13138. At the same time, I don't see that Mark's concept is any way faithful to the intent of 'concept is closed in conceptual schema'. And that is simply because 'concept is closed in conceptual schema' is not really about meaning; it is about the content of fact models in an SBVR exchange. It is a pragmatic declaration that provides certain implementation capabilities that the 'open world assumption' undercuts. Mark is putting lily-white gloves on hands that were intended to go in the dirt. > If Donald's proposed replacement fact type were worded "concept /is > closed in /body of shared concepts" would these questions still apply? Maybe. Note that the meaning is expressed in terms of fact models that conform to the conceptual schema. Do we have the idea that fact models conform to a body of shared concepts? The point here is that a 'fact model' is said to be a body of knowledge, but it is used as a body of knowledge that is *expressed* in a 'communication'. It appears that the SBVR term for an expressed body of knowledge is 'communication content', but there is no link between 'communication content' and 'fact model' or 'body of shared concepts'. How much would we have to add to SBVR to support: concept is closed in body of shared concepts Definition: For each _communication content_ that is based on the _body of shared concepts_, the communication content conveys a fact model that contains a set of facts that explicitly specify the entire extension of _concept_ Then clause 13 and 15 is about the construction of SBVR-conformant communication content, which conveys a fact model and is based on a body of shared concepts. And I suspect that the closure rule is only intended to apply to the kind of communication content that is described in clauses 13 and 15. All in all, I think the RTF was unwise to pull on the 13138 thread. -Ed > > ~ Keri > > > On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: >> *MHL>> My answers like this.* >> -------------------------------- >> Mark H. Linehan >> STSM, Model Driven Business Transformation >> IBM Research >> >> >> >> From: Ed Barkmeyer > >> To: Mark H Linehan/Watson/IBM@IBMUS >> Cc: "sbvr-rtf@omg.org " >> > >> Date: 10/13/2011 01:26 PM >> Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft >> Resolution (2011-10-13) >> ------------------------------------------------------------------------ >> >> >> >> Mark/Donald, >> >> Given the proposed text about known extensions, is the following a >> legitimate use? >> >> There is a concept called "Fred's sales calls" >> The extension of Fred's sales calls is known. >> Therefore, I don't need to tell you about any of them. >> (signed) Fred >> >> *MHL>>I'm not sure what the question is about the example given above.* >> *MHL>>It appears that the example is a letter directed, but there's no >> indication* >> *MHL>>who it is directed. More importantly, are Fred and the >> addressee in the same* >> *MHL>>semantic community? If they are, then the line "*The extension >> of Fred's sales calls is known*"* >> *MHL>>makes sense to me. If they are not in the same semantic >> community, then* >> *MHL>>this line is not very meaningful.* >> >> Similarly, >> there is a concept 'boy in the band' >> John is a boy in the band >> Paul is a boy in the band. >> The extension of 'boy in the band' is known. >> >> You have to pay the band. Do you have to pay George? >> Well, since the extension of 'boy in the band is known', you must know >> whether George is in the band or not. >> >> *MHL>>Yes.* >> >> Now, if your software has to actually process the invoice from George, >> and decide whether to further it for payment or reject it, how does it >> use this communal knowledge? >> >> *MHL>>The software operates within or on behalf of the semantic >> community for which* >> *MHL>>the "is known" statement is made -- right? After all, the >> software just automates* >> *MHL>>what otherwise could be done by hand, so it should have the same >> knowledge that* >> *MHL>>"I" have. So what's the issue? It seems obvious that the >> software will consult the* >> *MHL>>extension of "boy in the band" to decide whether George is in >> the band, and* >> *MHL>>pay or not based on the result of that consultation.* >> >> Is this fact type useful to business? >> >> *MHL>>I think so.* >> >> -Ed >> >> >> >> >> -- >> Edward J. Barkmeyer Email: edbark@nist.gov >> >> National Institute of Standards & Technology >> Manufacturing Systems Integration Division >> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 >> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 >> >> "The opinions expressed above do not reflect consensus of NIST, >> and have not been reviewed by any Government authority." >> >> > -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Tue, 18 Oct 2011 17:11:59 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9ILC2Nx017865 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1319577123.96868@FUMmOnk2bg+xxnnb0MqGDQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark H Linehan wrote: I don't agree with Ed's assertion that "In Mark's terms, that means that the person who conceives the possible world must know all of the instances of the concept, and have corresponding mental facts that correspond to those instantiations. But that creates a community of one person for the possible world." And "Mark wants to treat the 'closure of a concept' as a requirement on meanings that is completely separable from representation. It is possible to do that, but the consequence is weird: it says that you cannot actually conceive a world in which you don't know all the instances of the concept." Please note that defining a concept is independent of asserting a fact about the concept being "closed". One can do the former without the latter. For example, OMG can define the concept "SBVR-RTF" and say nothing about who knows or exchanges any information about the SBVR-RTF. OMG can then separately assert the "closed in conceptual schema" attribute of "SBVR-RTF" for itself, meaning that the OMG knows all the members of the SBVR-RTF but not that everyone else has that knowledge. All of this is quite true. What I was trying to say is that if OMG asserts in its conceptual schema that the RTF concept is closed, I can' t use that conceptual schema to share knowledge with OMG, and OMG can't use it to share knowledge with me. And indeed, no one who does not know all the RTF members can use the OMG conceptual schema to share knowledge about the RTF. So, what purpose does that conceptual schema serve? The OMG conceptual schema can be used to exchange knowledge about the RTF within OMG, but the statement implies there is no need to exchange knowledge about the RTF membership within OMG. And those of us who don't know can't use the OMG schema, so it would appear to be useless for the exchange of knowledge across the OMG/ignorant member boundary. In summary: Ed assumes that definition and assertion of the existing "concept is closed in conceptual schema" verb concept (or my proposed "completely known" characteristic) will be accomplished in one conceptual schema. I suggest that, in many useful cases, facts about closure of concepts will be done in subordinate conceptual schemas that are shared by a subset semantic community. That may be so, but the problem is simply that a conceptual schema that says that the population of a given concept is known within the semantic community that uses that conceptual schema says that there is no need for that community to exchange knowledge about that population. And the conceptual schema that says the population is known cannot be used to communicate in a larger community that does not universally have that knowledge. That is, the people who would like to obtain that knowledge can only use a schema that says that the knowledge anyone provides /may be incomplete/. In short, the idea of making the 'knowing' community-wide, instead of pointing to a particular source of the information, makes the proposed fact type /useless/ for knowledge sharing. I know that I am ignorant; it would be useful to know how I can improve the situation. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: keri Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" Date: 10/14/2011 06:07 PM Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) ------------------------------------------------------------------------ keri wrote: > Mark, Ed, > > Did these same questions arise for the fact types: *fact type is > internally closed in conceptual schema * and *concept /is closed > in /conceptual schema *? No. But it is a good question, because the answer is revealing. If a concept is closed in a conceptual schema, then every fact model that uses that conceptual schema explicitly identifies every instance of the concept. That is, there is a thing -- a fact model -- and that thing is the unit of communication between SBVR tools, any receiving tool can know that every instance of that concept in the possible world described by that fact model is explicitly identified as an instance of that concept in that fact model. The meaning of 'concept is closed in conceptual schema' provides a very clear way for software supporting SBVR to know exactly what set of things constitutes the extension of that concept. It explicitly says that you cannot 'share' ("exchange") the concept without explicitly sharing the specification of each of its instances. If the 'fact model' is taken to be a "meaning", then it is the body of knowledge about a possible world, which can be modeled as a set of facts about that world. In Mark's terms, that means that the person who conceives the possible world must know all of the instances of the concept, and have corresponding mental facts that correspond to those instantiations. But that creates a community of one person for the possible world. But the 'fact model' is also the unit of information exchange between SBVR tools, per clause 2. And the consequent requirement is that the exchange of a 'fact model' -- the representation of the fact model in XML -- must contain representations of all those facts, including all the instantiation facts. In that way, any recipient can also know exactly the set of things that is the extension of the concept in the possible world being described. The totality of clause 2 and clause 8.5 is not just that someone has to know the instances of the concept, but rather that s/he must express all those instances when s/he communicates about a possible world that makes use of the concept. In this area, SBVR is written to tie the conceptualization of the possible world (a meaning) to the expression of that conceptualization as a set of fact representations. The problems we are having arises from trying to do the usual SBVR thing of completely separating the meanings from their representations. Mark wants to treat the 'closure of a concept' as a requirement on meanings that is completely separable from representation. It is possible to do that, but the consequence is weird: it says that you cannot actually conceive a world in which you don't know all the instances of the concept. Now, I can conceive 'member of the SBVR RTF', as a concept directly applicable to writing this email, and I don't know all the members. So the requirement that 'member of the SBVR RTF is closed' ("is known") would appear to make it impossible for me to conceive a world in which I know anything about RTF members. What that really means is that I don't use that conceptual schema in conceptualizing the world in which I am writing this email. The conceptual schema I am using does not contain Mark's would be fact. But my conceptual schema, or perhaps just my internal fact model, does tell me that the RTF membership list is available at the OMG website, if I need to know. My concern is that we provide the means of saying that a representation of the possible world includes representations of all the instantiation facts for that concept, which is the most important half of what SBVR currently specifies. You can't exchange them if you don't know them, but you can know them and not exchange them (you can keep the knowledge to yourself). So, I can't properly describe the RTF to someone without saying who all the members are. Fair enough. I agree that my 'record' concept is really something more general than what SBVR can currently support, because it doesn't restrict the 'communication content' objects to being communications of complete fact models for possible worlds. The 'record' concept is not something that SBVR v1.0 has, and we probably should not be adding it in an RTF, and almost certainly not in response to Issue 13138. At the same time, I don't see that Mark's concept is any way faithful to the intent of 'concept is closed in conceptual schema'. And that is simply because 'concept is closed in conceptual schema' is not really about meaning; it is about the content of fact models in an SBVR exchange. It is a pragmatic declaration that provides certain implementation capabilities that the 'open world assumption' undercuts. Mark is putting lily-white gloves on hands that were intended to go in the dirt. > If Donald's proposed replacement fact type were worded "concept /is > closed in /body of shared concepts" would these questions still apply? Maybe. Note that the meaning is expressed in terms of fact models that conform to the conceptual schema. Do we have the idea that fact models conform to a body of shared concepts? The point here is that a 'fact model' is said to be a body of knowledge, but it is used as a body of knowledge that is *expressed* in a 'communication'. It appears that the SBVR term for an expressed body of knowledge is 'communication content', but there is no link between 'communication content' and 'fact model' or 'body of shared concepts'. How much would we have to add to SBVR to support: concept is closed in body of shared concepts Definition: For each _communication content_ that is based on the _body of shared concepts_, the communication content conveys a fact model that contains a set of facts that explicitly specify the entire extension of _concept_ Then clause 13 and 15 is about the construction of SBVR-conformant communication content, which conveys a fact model and is based on a body of shared concepts. And I suspect that the closure rule is only intended to apply to the kind of communication content that is described in clauses 13 and 15. All in all, I think the RTF was unwise to pull on the 13138 thread. -Ed > > ~ Keri > > > On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: >> *MHL>> My answers like this.* >> -------------------------------- >> Mark H. Linehan >> STSM, Model Driven Business Transformation >> IBM Research >> >> >> >> From: Ed Barkmeyer > >> To: Mark H Linehan/Watson/IBM@IBMUS >> Cc: "sbvr-rtf@omg.org " >> > >> Date: 10/13/2011 01:26 PM >> Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft >> Resolution (2011-10-13) >> ------------------------------------------------------------------------ >> >> >> >> Mark/Donald, >> >> Given the proposed text about known extensions, is the following a >> legitimate use? >> >> There is a concept called "Fred's sales calls" >> The extension of Fred's sales calls is known. >> Therefore, I don't need to tell you about any of them. >> (signed) Fred >> >> *MHL>>I'm not sure what the question is about the example given above.* >> *MHL>>It appears that the example is a letter directed, but there's no >> indication* >> *MHL>>who it is directed. More importantly, are Fred and the >> addressee in the same* >> *MHL>>semantic community? If they are, then the line "*The extension >> of Fred's sales calls is known*"* >> *MHL>>makes sense to me. If they are not in the same semantic >> community, then* >> *MHL>>this line is not very meaningful.* >> >> Similarly, >> there is a concept 'boy in the band' >> John is a boy in the band >> Paul is a boy in the band. >> The extension of 'boy in the band' is known. >> >> You have to pay the band. Do you have to pay George? >> Well, since the extension of 'boy in the band is known', you must know >> whether George is in the band or not. >> >> *MHL>>Yes.* >> >> Now, if your software has to actually process the invoice from George, >> and decide whether to further it for payment or reject it, how does it >> use this communal knowledge? >> >> *MHL>>The software operates within or on behalf of the semantic >> community for which* >> *MHL>>the "is known" statement is made -- right? After all, the >> software just automates* >> *MHL>>what otherwise could be done by hand, so it should have the same >> knowledge that* >> *MHL>>"I" have. So what's the issue? It seems obvious that the >> software will consult the* >> *MHL>>extension of "boy in the band" to decide whether George is in >> the band, and* >> *MHL>>pay or not based on the result of that consultation.* >> >> Is this fact type useful to business? >> >> *MHL>>I think so.* >> >> -Ed >> >> >> >> >> -- >> Edward J. Barkmeyer Email: edbark@nist.gov >> >> National Institute of Standards & Technology >> Manufacturing Systems Integration Division >> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 >> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 >> >> "The opinions expressed above do not reflect consensus of NIST, >> and have not been reviewed by any Government authority." >> >> > -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." To: "sbvr-rtf@omg.org" Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-KeepSent: EB7F5052:B1AE6A70-8525792E:00091810; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Tue, 18 Oct 2011 21:46:52 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/18/2011 21:46:52, Serialize complete at 10/18/2011 21:46:52 x-cbid: 11101901-5112-0000-0000-0000011B7558 Ed, I do not know why we miscommunicate. I thought I was very clear that I do NOT suggest that OMG shares the fact that "RTF concept is closed" with others. So the scenario you describe is NOT the one that I am proposing. I am suggesting that the OMG would share its conceptual schema but NOT its fact that "the RTF concept is closed". So others could use a shared conceptual schema without being "burdened" with the closure of that concept. Since facts go in fact models (not conceptual schemas as I implied below), OMG can assert this fact in its own fact model that is based on the shared conceptual schema. The fact model is not shared, so others would not "see" this fact. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/18/2011 05:13 PM Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Mark H Linehan wrote: > I don't agree with Ed's assertion that > "In Mark's terms, that means that the person who > conceives the possible world must know all of the instances of the > concept, and have corresponding mental facts that correspond to those > instantiations. But that creates a community of one person for the > possible world." > > And "Mark > wants to treat the 'closure of a concept' as a requirement on meanings > that is completely separable from representation. It is possible to do > that, but the consequence is weird: it says that you cannot actually > conceive a world in which you don't know all the instances of the > concept." > > Please note that defining a concept is independent of asserting a fact > about the concept being "closed". One can do the former without the > latter. For example, OMG can define the concept "SBVR-RTF" and say > nothing about who knows or exchanges any information about the > SBVR-RTF. OMG can then separately assert the "closed in conceptual > schema" attribute of "SBVR-RTF" for itself, meaning that the OMG knows > all the members of the SBVR-RTF but not that everyone else has that > knowledge. All of this is quite true. What I was trying to say is that if OMG asserts in its conceptual schema that the RTF concept is closed, I can' t use that conceptual schema to share knowledge with OMG, and OMG can't use it to share knowledge with me. And indeed, no one who does not know all the RTF members can use the OMG conceptual schema to share knowledge about the RTF. So, what purpose does that conceptual schema serve? The OMG conceptual schema can be used to exchange knowledge about the RTF within OMG, but the statement implies there is no need to exchange knowledge about the RTF membership within OMG. And those of us who don't know can't use the OMG schema, so it would appear to be useless for the exchange of knowledge across the OMG/ignorant member boundary. > In summary: Ed assumes that definition and assertion of the existing > "concept is closed in conceptual schema" verb concept (or my proposed > "completely known" characteristic) will be accomplished in one > conceptual schema. I suggest that, in many useful cases, facts about > closure of concepts will be done in subordinate conceptual schemas > that are shared by a subset semantic community. That may be so, but the problem is simply that a conceptual schema that says that the population of a given concept is known within the semantic community that uses that conceptual schema says that there is no need for that community to exchange knowledge about that population. And the conceptual schema that says the population is known cannot be used to communicate in a larger community that does not universally have that knowledge. That is, the people who would like to obtain that knowledge can only use a schema that says that the knowledge anyone provides /may be incomplete/. In short, the idea of making the 'knowing' community-wide, instead of pointing to a particular source of the information, makes the proposed fact type /useless/ for knowledge sharing. I know that I am ignorant; it would be useful to know how I can improve the situation. -Ed > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > > > From: Ed Barkmeyer > To: keri > Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" > > Date: 10/14/2011 06:07 PM > Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft > Resolution (2011-10-13) > ------------------------------------------------------------------------ > > > > keri wrote: > > Mark, Ed, > > > > Did these same questions arise for the fact types: *fact type is > > internally closed in conceptual schema * and *concept /is closed > > in /conceptual schema *? > > No. But it is a good question, because the answer is revealing. > > If a concept is closed in a conceptual schema, then every fact model > that uses that conceptual schema explicitly identifies every instance of > the concept. That is, there is a thing -- a fact model -- and that > thing is the unit of communication between SBVR tools, any receiving > tool can know that every instance of that concept in the possible world > described by that fact model is explicitly identified as an instance of > that concept in that fact model. > > The meaning of 'concept is closed in conceptual schema' provides a very > clear way for software supporting SBVR to know exactly what set of > things constitutes the extension of that concept. It explicitly says > that you cannot 'share' ("exchange") the concept without explicitly > sharing the specification of each of its instances. > > If the 'fact model' is taken to be a "meaning", then it is the body of > knowledge about a possible world, which can be modeled as a set of facts > about that world. In Mark's terms, that means that the person who > conceives the possible world must know all of the instances of the > concept, and have corresponding mental facts that correspond to those > instantiations. But that creates a community of one person for the > possible world. > > But the 'fact model' is also the unit of information exchange between > SBVR tools, per clause 2. And the consequent requirement is that the > exchange of a 'fact model' -- the representation of the fact model in > XML -- must contain representations of all those facts, including all > the instantiation facts. In that way, any recipient can also know > exactly the set of things that is the extension of the concept in the > possible world being described. > > The totality of clause 2 and clause 8.5 is not just that someone has to > know the instances of the concept, but rather that s/he must express all > those instances when s/he communicates about a possible world that makes > use of the concept. In this area, SBVR is written to tie the > conceptualization of the possible world (a meaning) to the expression of > that conceptualization as a set of fact representations. > > The problems we are having arises from trying to do the usual SBVR thing > of completely separating the meanings from their representations. Mark > wants to treat the 'closure of a concept' as a requirement on meanings > that is completely separable from representation. It is possible to do > that, but the consequence is weird: it says that you cannot actually > conceive a world in which you don't know all the instances of the concept. > > Now, I can conceive 'member of the SBVR RTF', as a concept directly > applicable to writing this email, and I don't know all the members. So > the requirement that 'member of the SBVR RTF is closed' ("is known") > would appear to make it impossible for me to conceive a world in which I > know anything about RTF members. What that really means is that I don't > use that conceptual schema in conceptualizing the world in which I am > writing this email. The conceptual schema I am using does not contain > Mark's would be fact. But my conceptual schema, or perhaps just my > internal fact model, does tell me that the RTF membership list is > available at the OMG website, if I need to know. > > My concern is that we provide the means of saying that a representation > of the possible world includes representations of all the instantiation > facts for that concept, which is the most important half of what SBVR > currently specifies. You can't exchange them if you don't know them, > but you can know them and not exchange them (you can keep the knowledge > to yourself). So, I can't properly describe the RTF to someone without > saying who all the members are. Fair enough. > > I agree that my 'record' concept is really something more general than > what SBVR can currently support, because it doesn't restrict the > 'communication content' objects to being communications of complete fact > models for possible worlds. The 'record' concept is not something that > SBVR v1.0 has, and we probably should not be adding it in an RTF, and > almost certainly not in response to Issue 13138. > > At the same time, I don't see that Mark's concept is any way faithful to > the intent of 'concept is closed in conceptual schema'. And that is > simply because 'concept is closed in conceptual schema' is not really > about meaning; it is about the content of fact models in an SBVR > exchange. It is a pragmatic declaration that provides certain > implementation capabilities that the 'open world assumption' undercuts. > Mark is putting lily-white gloves on hands that were intended to go in > the dirt. > > > > If Donald's proposed replacement fact type were worded "concept /is > > closed in /body of shared concepts" would these questions still apply? > > > Maybe. Note that the meaning is expressed in terms of fact models that > conform to the conceptual schema. Do we have the idea that fact models > conform to a body of shared concepts? The point here is that a 'fact > model' is said to be a body of knowledge, but it is used as a body of > knowledge that is *expressed* in a 'communication'. It appears that the > SBVR term for an expressed body of knowledge is 'communication content', > but there is no link between 'communication content' and 'fact model' or > 'body of shared concepts'. > > How much would we have to add to SBVR to support: > concept is closed in body of shared concepts > Definition: For each _communication content_ that is based on the > _body of shared concepts_, the communication content conveys a fact > model that contains a set of facts that explicitly specify the entire > extension of _concept_ > > Then clause 13 and 15 is about the construction of SBVR-conformant > communication content, which conveys a fact model and is based on a body > of shared concepts. And I suspect that the closure rule is only > intended to apply to the kind of communication content that is described > in clauses 13 and 15. > > All in all, I think the RTF was unwise to pull on the 13138 thread. > > -Ed > > > > > ~ Keri > > > > > > On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: > >> *MHL>> My answers like this.* > >> -------------------------------- > >> Mark H. Linehan > >> STSM, Model Driven Business Transformation > >> IBM Research > >> > >> > >> > >> From: Ed Barkmeyer > > >> To: Mark H Linehan/Watson/IBM@IBMUS > >> Cc: "sbvr-rtf@omg.org " > >> > > >> Date: 10/13/2011 01:26 PM > >> Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft > >> Resolution (2011-10-13) > >> > ------------------------------------------------------------------------ > >> > >> > >> > >> Mark/Donald, > >> > >> Given the proposed text about known extensions, is the following a > >> legitimate use? > >> > >> There is a concept called "Fred's sales calls" > >> The extension of Fred's sales calls is known. > >> Therefore, I don't need to tell you about any of them. > >> (signed) Fred > >> > >> *MHL>>I'm not sure what the question is about the example given above.* > >> *MHL>>It appears that the example is a letter directed, but there's no > >> indication* > >> *MHL>>who it is directed. More importantly, are Fred and the > >> addressee in the same* > >> *MHL>>semantic community? If they are, then the line "*The extension > >> of Fred's sales calls is known*"* > >> *MHL>>makes sense to me. If they are not in the same semantic > >> community, then* > >> *MHL>>this line is not very meaningful.* > >> > >> Similarly, > >> there is a concept 'boy in the band' > >> John is a boy in the band > >> Paul is a boy in the band. > >> The extension of 'boy in the band' is known. > >> > >> You have to pay the band. Do you have to pay George? > >> Well, since the extension of 'boy in the band is known', you must know > >> whether George is in the band or not. > >> > >> *MHL>>Yes.* > >> > >> Now, if your software has to actually process the invoice from George, > >> and decide whether to further it for payment or reject it, how does it > >> use this communal knowledge? > >> > >> *MHL>>The software operates within or on behalf of the semantic > >> community for which* > >> *MHL>>the "is known" statement is made -- right? After all, the > >> software just automates* > >> *MHL>>what otherwise could be done by hand, so it should have the same > >> knowledge that* > >> *MHL>>"I" have. So what's the issue? It seems obvious that the > >> software will consult the* > >> *MHL>>extension of "boy in the band" to decide whether George is in > >> the band, and* > >> *MHL>>pay or not based on the result of that consultation.* > >> > >> Is this fact type useful to business? > >> > >> *MHL>>I think so.* > >> > >> -Ed > >> > >> > >> > >> > >> -- > >> Edward J. Barkmeyer Email: edbark@nist.gov > >> > >> National Institute of Standards & Technology > >> Manufacturing Systems Integration Division > >> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > >> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > >> > >> "The opinions expressed above do not reflect consensus of NIST, > >> and have not been reviewed by any Government authority." > >> > >> > > > > -- > Edward J. Barkmeyer Email: edbark@nist.gov > National Institute of Standards & Technology > Manufacturing Systems Integration Division > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > "The opinions expressed above do not reflect consensus of NIST, > and have not been reviewed by any Government authority." > > -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Wed, 19 Oct 2011 10:28:36 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9JESfks005089 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1319639326.92614@M5rFBCVZGGfF5KGlfYklCw X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark H Linehan wrote: Ed, I do not know why we miscommunicate. It is because we obviously have different concerns. I thought I was very clear that I do NOT suggest that OMG shares the fact that "RTF concept is closed" with others. So the scenario you describe is NOT the one that I am proposing. I am suggesting that the OMG would share its conceptual schema but NOT its fact that "the RTF concept is closed". So others could use a shared conceptual schema without being "burdened" with the closure of that concept. Since facts go in fact models (not conceptual schemas as I implied below), OMG can assert this fact in its own fact model that is based on the shared conceptual schema. The fact model is not shared, so others would not "see" this fact. So your proposed fact type has nothing to do with communicating the exact list of members of the set that is the extension of the concept. Do we agree on that? If we do, then (1) since 'concept is closed in conceptual schema' is entirely about communicating exactly the list of members of the extension (in fact models that use it), there is no relationship of your proposal to Issue 13138. (2) I see no value whatsoever in your proposed fact type. It provides for neither a means of communication or an identification of a source of the information. What business purpose does it serve? (2) is why we are miscommunicating. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/18/2011 05:13 PM Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) ------------------------------------------------------------------------ Mark H Linehan wrote: > I don't agree with Ed's assertion that > "In Mark's terms, that means that the person who > conceives the possible world must know all of the instances of the > concept, and have corresponding mental facts that correspond to those > instantiations. But that creates a community of one person for the > possible world." > > And "Mark > wants to treat the 'closure of a concept' as a requirement on meanings > that is completely separable from representation. It is possible to do > that, but the consequence is weird: it says that you cannot actually > conceive a world in which you don't know all the instances of the > concept." > > Please note that defining a concept is independent of asserting a fact > about the concept being "closed". One can do the former without the > latter. For example, OMG can define the concept "SBVR-RTF" and say > nothing about who knows or exchanges any information about the > SBVR-RTF. OMG can then separately assert the "closed in conceptual > schema" attribute of "SBVR-RTF" for itself, meaning that the OMG knows > all the members of the SBVR-RTF but not that everyone else has that > knowledge. All of this is quite true. What I was trying to say is that if OMG asserts in its conceptual schema that the RTF concept is closed, I can' t use that conceptual schema to share knowledge with OMG, and OMG can't use it to share knowledge with me. And indeed, no one who does not know all the RTF members can use the OMG conceptual schema to share knowledge about the RTF. So, what purpose does that conceptual schema serve? The OMG conceptual schema can be used to exchange knowledge about the RTF within OMG, but the statement implies there is no need to exchange knowledge about the RTF membership within OMG. And those of us who don't know can't use the OMG schema, so it would appear to be useless for the exchange of knowledge across the OMG/ignorant member boundary. > In summary: Ed assumes that definition and assertion of the existing > "concept is closed in conceptual schema" verb concept (or my proposed > "completely known" characteristic) will be accomplished in one > conceptual schema. I suggest that, in many useful cases, facts about > closure of concepts will be done in subordinate conceptual schemas > that are shared by a subset semantic community. That may be so, but the problem is simply that a conceptual schema that says that the population of a given concept is known within the semantic community that uses that conceptual schema says that there is no need for that community to exchange knowledge about that population. And the conceptual schema that says the population is known cannot be used to communicate in a larger community that does not universally have that knowledge. That is, the people who would like to obtain that knowledge can only use a schema that says that the knowledge anyone provides /may be incomplete/. In short, the idea of making the 'knowing' community-wide, instead of pointing to a particular source of the information, makes the proposed fact type /useless/ for knowledge sharing. I know that I am ignorant; it would be useful to know how I can improve the situation. -Ed > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > > > From: Ed Barkmeyer > To: keri > Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" > > Date: 10/14/2011 06:07 PM > Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft > Resolution (2011-10-13) > ------------------------------------------------------------------------ > > > > keri wrote: > > Mark, Ed, > > > > Did these same questions arise for the fact types: *fact type is > > internally closed in conceptual schema * and *concept /is closed > > in /conceptual schema *? > > No. But it is a good question, because the answer is revealing. > > If a concept is closed in a conceptual schema, then every fact model > that uses that conceptual schema explicitly identifies every instance of > the concept. That is, there is a thing -- a fact model -- and that > thing is the unit of communication between SBVR tools, any receiving > tool can know that every instance of that concept in the possible world > described by that fact model is explicitly identified as an instance of > that concept in that fact model. > > The meaning of 'concept is closed in conceptual schema' provides a very > clear way for software supporting SBVR to know exactly what set of > things constitutes the extension of that concept. It explicitly says > that you cannot 'share' ("exchange") the concept without explicitly > sharing the specification of each of its instances. > > If the 'fact model' is taken to be a "meaning", then it is the body of > knowledge about a possible world, which can be modeled as a set of facts > about that world. In Mark's terms, that means that the person who > conceives the possible world must know all of the instances of the > concept, and have corresponding mental facts that correspond to those > instantiations. But that creates a community of one person for the > possible world. > > But the 'fact model' is also the unit of information exchange between > SBVR tools, per clause 2. And the consequent requirement is that the > exchange of a 'fact model' -- the representation of the fact model in > XML -- must contain representations of all those facts, including all > the instantiation facts. In that way, any recipient can also know > exactly the set of things that is the extension of the concept in the > possible world being described. > > The totality of clause 2 and clause 8.5 is not just that someone has to > know the instances of the concept, but rather that s/he must express all > those instances when s/he communicates about a possible world that makes > use of the concept. In this area, SBVR is written to tie the > conceptualization of the possible world (a meaning) to the expression of > that conceptualization as a set of fact representations. > > The problems we are having arises from trying to do the usual SBVR thing > of completely separating the meanings from their representations. Mark > wants to treat the 'closure of a concept' as a requirement on meanings > that is completely separable from representation. It is possible to do > that, but the consequence is weird: it says that you cannot actually > conceive a world in which you don't know all the instances of the concept. > > Now, I can conceive 'member of the SBVR RTF', as a concept directly > applicable to writing this email, and I don't know all the members. So > the requirement that 'member of the SBVR RTF is closed' ("is known") > would appear to make it impossible for me to conceive a world in which I > know anything about RTF members. What that really means is that I don't > use that conceptual schema in conceptualizing the world in which I am > writing this email. The conceptual schema I am using does not contain > Mark's would be fact. But my conceptual schema, or perhaps just my > internal fact model, does tell me that the RTF membership list is > available at the OMG website, if I need to know. > > My concern is that we provide the means of saying that a representation > of the possible world includes representations of all the instantiation > facts for that concept, which is the most important half of what SBVR > currently specifies. You can't exchange them if you don't know them, > but you can know them and not exchange them (you can keep the knowledge > to yourself). So, I can't properly describe the RTF to someone without > saying who all the members are. Fair enough. > > I agree that my 'record' concept is really something more general than > what SBVR can currently support, because it doesn't restrict the > 'communication content' objects to being communications of complete fact > models for possible worlds. The 'record' concept is not something that > SBVR v1.0 has, and we probably should not be adding it in an RTF, and > almost certainly not in response to Issue 13138. > > At the same time, I don't see that Mark's concept is any way faithful to > the intent of 'concept is closed in conceptual schema'. And that is > simply because 'concept is closed in conceptual schema' is not really > about meaning; it is about the content of fact models in an SBVR > exchange. It is a pragmatic declaration that provides certain > implementation capabilities that the 'open world assumption' undercuts. > Mark is putting lily-white gloves on hands that were intended to go in > the dirt. > > > > If Donald's proposed replacement fact type were worded "concept /is > > closed in /body of shared concepts" would these questions still apply? > > > Maybe. Note that the meaning is expressed in terms of fact models that > conform to the conceptual schema. Do we have the idea that fact models > conform to a body of shared concepts? The point here is that a 'fact > model' is said to be a body of knowledge, but it is used as a body of > knowledge that is *expressed* in a 'communication'. It appears that the > SBVR term for an expressed body of knowledge is 'communication content', > but there is no link between 'communication content' and 'fact model' or > 'body of shared concepts'. > > How much would we have to add to SBVR to support: > concept is closed in body of shared concepts > Definition: For each _communication content_ that is based on the > _body of shared concepts_, the communication content conveys a fact > model that contains a set of facts that explicitly specify the entire > extension of _concept_ > > Then clause 13 and 15 is about the construction of SBVR-conformant > communication content, which conveys a fact model and is based on a body > of shared concepts. And I suspect that the closure rule is only > intended to apply to the kind of communication content that is described > in clauses 13 and 15. > > All in all, I think the RTF was unwise to pull on the 13138 thread. > > -Ed > > > > > ~ Keri > > > > > > On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: > >> *MHL>> My answers like this.* > >> -------------------------------- > >> Mark H. Linehan > >> STSM, Model Driven Business Transformation > >> IBM Research > >> > >> > >> > >> From: Ed Barkmeyer > > >> To: Mark H Linehan/Watson/IBM@IBMUS > >> Cc: "sbvr-rtf@omg.org " > >> > > >> Date: 10/13/2011 01:26 PM > >> Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated Draft > >> Resolution (2011-10-13) > >> > ------------------------------------------------------------------------ > >> > >> > >> > >> Mark/Donald, > >> > >> Given the proposed text about known extensions, is the following a > >> legitimate use? > >> > >> There is a concept called "Fred's sales calls" > >> The extension of Fred's sales calls is known. > >> Therefore, I don't need to tell you about any of them. > >> (signed) Fred > >> > >> *MHL>>I'm not sure what the question is about the example given above.* > >> *MHL>>It appears that the example is a letter directed, but there's no > >> indication* > >> *MHL>>who it is directed. More importantly, are Fred and the > >> addressee in the same* > >> *MHL>>semantic community? If they are, then the line "*The extension > >> of Fred's sales calls is known*"* > >> *MHL>>makes sense to me. If they are not in the same semantic > >> community, then* > >> *MHL>>this line is not very meaningful.* > >> > >> Similarly, > >> there is a concept 'boy in the band' > >> John is a boy in the band > >> Paul is a boy in the band. > >> The extension of 'boy in the band' is known. > >> > >> You have to pay the band. Do you have to pay George? > >> Well, since the extension of 'boy in the band is known', you must know > >> whether George is in the band or not. > >> > >> *MHL>>Yes.* > >> > >> Now, if your software has to actually process the invoice from George, > >> and decide whether to further it for payment or reject it, how does it > >> use this communal knowledge? > >> > >> *MHL>>The software operates within or on behalf of the semantic > >> community for which* > >> *MHL>>the "is known" statement is made -- right? After all, the > >> software just automates* > >> *MHL>>what otherwise could be done by hand, so it should have the same > >> knowledge that* > >> *MHL>>"I" have. So what's the issue? It seems obvious that the > >> software will consult the* > >> *MHL>>extension of "boy in the band" to decide whether George is in > >> the band, and* > >> *MHL>>pay or not based on the result of that consultation.* > >> > >> Is this fact type useful to business? > >> > >> *MHL>>I think so.* > >> > >> -Ed > >> > >> > >> > >> > >> -- > >> Edward J. Barkmeyer Email: edbark@nist.gov > >> > >> National Institute of Standards & Technology > >> Manufacturing Systems Integration Division > >> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > >> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > >> > >> "The opinions expressed above do not reflect consensus of NIST, > >> and have not been reviewed by any Government authority." > >> > >> > > > > -- > Edward J. Barkmeyer Email: edbark@nist.gov > National Institute of Standards & Technology > Manufacturing Systems Integration Division > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > "The opinions expressed above do not reflect consensus of NIST, > and have not been reviewed by any Government authority." > > -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." To: "sbvr-rtf@omg.org" Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-KeepSent: F5EB7776:E0AFB5E4-8525792E:004FD066; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Wed, 19 Oct 2011 10:39:13 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 10/19/2011 10:39:17, Serialize complete at 10/19/2011 10:39:17 x-cbid: 11101914-5930-0000-0000-0000006F5DFD Ed, I do not agree that " 'concept is closed in conceptual schema' is entirely about communicating exactly the list of members of the extension (in fact models that use it)". The existing SBVR definition of 'concept is closed in conceptual schema' is not about "communicating", it is about the content of fact models. Fact models need not be used for communication; they can also be used for just keeping track of facts. My intention is that asserting the fact "that "the RTF concept is closed" in a fact model means that the fact model has "exactly the list of members of the extension" of the concept. The relationship of a fact model to communities is a separate issue. In summary: you think the "closed world" concept is about communicating knowledge. I think it is about the nature of knowledge (i.e. a characteristic of the knowledge representation), regardless of whether it is communicated. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/19/2011 10:29 AM Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) -------------------------------------------------------------------------------- Mark H Linehan wrote: > Ed, > > I do not know why we miscommunicate. It is because we obviously have different concerns. > I thought I was very clear that I do NOT suggest that OMG shares the > fact that "RTF concept is closed" with others. So the scenario you > describe is NOT the one that I am proposing. > > I am suggesting that the OMG would share its conceptual schema but > NOT its fact that "the RTF concept is closed". So others could use a > shared conceptual schema without being "burdened" with the closure of > that concept. > > Since facts go in fact models (not conceptual schemas as I implied > below), OMG can assert this fact in its own fact model that is based > on the shared conceptual schema. The fact model is not shared, so > others would not "see" this fact. So your proposed fact type has nothing to do with communicating the exact list of members of the set that is the extension of the concept. Do we agree on that? If we do, then (1) since 'concept is closed in conceptual schema' is entirely about communicating exactly the list of members of the extension (in fact models that use it), there is no relationship of your proposal to Issue 13138. (2) I see no value whatsoever in your proposed fact type. It provides for neither a means of communication or an identification of a source of the information. What business purpose does it serve? (2) is why we are miscommunicating. -Ed > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > > > From: Ed Barkmeyer > To: Mark H Linehan/Watson/IBM@IBMUS > Cc: "sbvr-rtf@omg.org" > Date: 10/18/2011 05:13 PM > Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft > Resolution (2011-10-13) > ------------------------------------------------------------------------ > > > > > > Mark H Linehan wrote: > > I don't agree with Ed's assertion that > > "In Mark's terms, that means that the person who > > conceives the possible world must know all of the instances of the > > concept, and have corresponding mental facts that correspond to those > > instantiations. But that creates a community of one person for the > > possible world." > > > > And "Mark > > wants to treat the 'closure of a concept' as a requirement on meanings > > that is completely separable from representation. It is possible to do > > that, but the consequence is weird: it says that you cannot actually > > conceive a world in which you don't know all the instances of the > > concept." > > > > Please note that defining a concept is independent of asserting a fact > > about the concept being "closed". One can do the former without the > > latter. For example, OMG can define the concept "SBVR-RTF" and say > > nothing about who knows or exchanges any information about the > > SBVR-RTF. OMG can then separately assert the "closed in conceptual > > schema" attribute of "SBVR-RTF" for itself, meaning that the OMG knows > > all the members of the SBVR-RTF but not that everyone else has that > > knowledge. > > All of this is quite true. What I was trying to say is that if OMG > asserts in its conceptual schema that the RTF concept is closed, I can' > t use that conceptual schema to share knowledge with OMG, and OMG can't > use it to share knowledge with me. And indeed, no one who does not know > all the RTF members can use the OMG conceptual schema to share knowledge > about the RTF. So, what purpose does that conceptual schema serve? The > OMG conceptual schema can be used to exchange knowledge about the RTF > within OMG, but the statement implies there is no need to exchange > knowledge about the RTF membership within OMG. And those of us who > don't know can't use the OMG schema, so it would appear to be useless > for the exchange of knowledge across the OMG/ignorant member boundary. > > > In summary: Ed assumes that definition and assertion of the existing > > "concept is closed in conceptual schema" verb concept (or my proposed > > "completely known" characteristic) will be accomplished in one > > conceptual schema. I suggest that, in many useful cases, facts about > > closure of concepts will be done in subordinate conceptual schemas > > that are shared by a subset semantic community. > > That may be so, but the problem is simply that a conceptual schema that > says that the population of a given concept is known within the semantic > community that uses that conceptual schema says that there is no need > for that community to exchange knowledge about that population. And the > conceptual schema that says the population is known cannot be used to > communicate in a larger community that does not universally have that > knowledge. That is, the people who would like to obtain that knowledge > can only use a schema that says that the knowledge anyone provides /may > be incomplete/. > > In short, the idea of making the 'knowing' community-wide, instead of > pointing to a particular source of the information, makes the proposed > fact type /useless/ for knowledge sharing. I know that I am ignorant; > it would be useful to know how I can improve the situation. > > -Ed > > > -------------------------------- > > Mark H. Linehan > > STSM, Model Driven Business Transformation > > IBM Research > > > > > > > > From: Ed Barkmeyer > > To: keri > > Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" > > > > Date: 10/14/2011 06:07 PM > > Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft > > Resolution (2011-10-13) > > ------------------------------------------------------------------------ > > > > > > > > keri wrote: > > > Mark, Ed, > > > > > > Did these same questions arise for the fact types: *fact type is > > > internally closed in conceptual schema * and *concept /is closed > > > in /conceptual schema *? > > > > No. But it is a good question, because the answer is revealing. > > > > If a concept is closed in a conceptual schema, then every fact model > > that uses that conceptual schema explicitly identifies every instance of > > the concept. That is, there is a thing -- a fact model -- and that > > thing is the unit of communication between SBVR tools, any receiving > > tool can know that every instance of that concept in the possible world > > described by that fact model is explicitly identified as an instance of > > that concept in that fact model. > > > > The meaning of 'concept is closed in conceptual schema' provides a very > > clear way for software supporting SBVR to know exactly what set of > > things constitutes the extension of that concept. It explicitly says > > that you cannot 'share' ("exchange") the concept without explicitly > > sharing the specification of each of its instances. > > > > If the 'fact model' is taken to be a "meaning", then it is the body of > > knowledge about a possible world, which can be modeled as a set of facts > > about that world. In Mark's terms, that means that the person who > > conceives the possible world must know all of the instances of the > > concept, and have corresponding mental facts that correspond to those > > instantiations. But that creates a community of one person for the > > possible world. > > > > But the 'fact model' is also the unit of information exchange between > > SBVR tools, per clause 2. And the consequent requirement is that the > > exchange of a 'fact model' -- the representation of the fact model in > > XML -- must contain representations of all those facts, including all > > the instantiation facts. In that way, any recipient can also know > > exactly the set of things that is the extension of the concept in the > > possible world being described. > > > > The totality of clause 2 and clause 8.5 is not just that someone has to > > know the instances of the concept, but rather that s/he must express all > > those instances when s/he communicates about a possible world that makes > > use of the concept. In this area, SBVR is written to tie the > > conceptualization of the possible world (a meaning) to the expression of > > that conceptualization as a set of fact representations. > > > > The problems we are having arises from trying to do the usual SBVR thing > > of completely separating the meanings from their representations. Mark > > wants to treat the 'closure of a concept' as a requirement on meanings > > that is completely separable from representation. It is possible to do > > that, but the consequence is weird: it says that you cannot actually > > conceive a world in which you don't know all the instances of the > concept. > > > > Now, I can conceive 'member of the SBVR RTF', as a concept directly > > applicable to writing this email, and I don't know all the members. So > > the requirement that 'member of the SBVR RTF is closed' ("is known") > > would appear to make it impossible for me to conceive a world in which I > > know anything about RTF members. What that really means is that I don't > > use that conceptual schema in conceptualizing the world in which I am > > writing this email. The conceptual schema I am using does not contain > > Mark's would be fact. But my conceptual schema, or perhaps just my > > internal fact model, does tell me that the RTF membership list is > > available at the OMG website, if I need to know. > > > > My concern is that we provide the means of saying that a representation > > of the possible world includes representations of all the instantiation > > facts for that concept, which is the most important half of what SBVR > > currently specifies. You can't exchange them if you don't know them, > > but you can know them and not exchange them (you can keep the knowledge > > to yourself). So, I can't properly describe the RTF to someone without > > saying who all the members are. Fair enough. > > > > I agree that my 'record' concept is really something more general than > > what SBVR can currently support, because it doesn't restrict the > > 'communication content' objects to being communications of complete fact > > models for possible worlds. The 'record' concept is not something that > > SBVR v1.0 has, and we probably should not be adding it in an RTF, and > > almost certainly not in response to Issue 13138. > > > > At the same time, I don't see that Mark's concept is any way faithful to > > the intent of 'concept is closed in conceptual schema'. And that is > > simply because 'concept is closed in conceptual schema' is not really > > about meaning; it is about the content of fact models in an SBVR > > exchange. It is a pragmatic declaration that provides certain > > implementation capabilities that the 'open world assumption' undercuts. > > Mark is putting lily-white gloves on hands that were intended to go in > > the dirt. > > > > > > > If Donald's proposed replacement fact type were worded "concept /is > > > closed in /body of shared concepts" would these questions still apply? > > > > > > Maybe. Note that the meaning is expressed in terms of fact models that > > conform to the conceptual schema. Do we have the idea that fact models > > conform to a body of shared concepts? The point here is that a 'fact > > model' is said to be a body of knowledge, but it is used as a body of > > knowledge that is *expressed* in a 'communication'. It appears that the > > SBVR term for an expressed body of knowledge is 'communication content', > > but there is no link between 'communication content' and 'fact model' or > > 'body of shared concepts'. > > > > How much would we have to add to SBVR to support: > > concept is closed in body of shared concepts > > Definition: For each _communication content_ that is based on the > > _body of shared concepts_, the communication content conveys a fact > > model that contains a set of facts that explicitly specify the entire > > extension of _concept_ > > > > Then clause 13 and 15 is about the construction of SBVR-conformant > > communication content, which conveys a fact model and is based on a body > > of shared concepts. And I suspect that the closure rule is only > > intended to apply to the kind of communication content that is described > > in clauses 13 and 15. > > > > All in all, I think the RTF was unwise to pull on the 13138 thread. > > > > -Ed > > > > > > > > ~ Keri > > > > > > > > > On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: > > >> *MHL>> My answers like this.* > > >> -------------------------------- > > >> Mark H. Linehan > > >> STSM, Model Driven Business Transformation > > >> IBM Research > > >> > > >> > > >> > > >> From: Ed Barkmeyer > > > >> To: Mark H Linehan/Watson/IBM@IBMUS > > >> Cc: "sbvr-rtf@omg.org " > > >> > > > >> Date: 10/13/2011 01:26 PM > > >> Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated > Draft > > >> Resolution (2011-10-13) > > >> > > ------------------------------------------------------------------------ > > >> > > >> > > >> > > >> Mark/Donald, > > >> > > >> Given the proposed text about known extensions, is the following a > > >> legitimate use? > > >> > > >> There is a concept called "Fred's sales calls" > > >> The extension of Fred's sales calls is known. > > >> Therefore, I don't need to tell you about any of them. > > >> (signed) Fred > > >> > > >> *MHL>>I'm not sure what the question is about the example given > above.* > > >> *MHL>>It appears that the example is a letter directed, but > there's no > > >> indication* > > >> *MHL>>who it is directed. More importantly, are Fred and the > > >> addressee in the same* > > >> *MHL>>semantic community? If they are, then the line "*The extension > > >> of Fred's sales calls is known*"* > > >> *MHL>>makes sense to me. If they are not in the same semantic > > >> community, then* > > >> *MHL>>this line is not very meaningful.* > > >> > > >> Similarly, > > >> there is a concept 'boy in the band' > > >> John is a boy in the band > > >> Paul is a boy in the band. > > >> The extension of 'boy in the band' is known. > > >> > > >> You have to pay the band. Do you have to pay George? > > >> Well, since the extension of 'boy in the band is known', you must > know > > >> whether George is in the band or not. > > >> > > >> *MHL>>Yes.* > > >> > > >> Now, if your software has to actually process the invoice from > George, > > >> and decide whether to further it for payment or reject it, how > does it > > >> use this communal knowledge? > > >> > > >> *MHL>>The software operates within or on behalf of the semantic > > >> community for which* > > >> *MHL>>the "is known" statement is made -- right? After all, the > > >> software just automates* > > >> *MHL>>what otherwise could be done by hand, so it should have the > same > > >> knowledge that* > > >> *MHL>>"I" have. So what's the issue? It seems obvious that the > > >> software will consult the* > > >> *MHL>>extension of "boy in the band" to decide whether George is in > > >> the band, and* > > >> *MHL>>pay or not based on the result of that consultation.* > > >> > > >> Is this fact type useful to business? > > >> > > >> *MHL>>I think so.* > > >> > > >> -Ed > > >> > > >> > > >> > > >> > > >> -- > > >> Edward J. Barkmeyer Email: edbark@nist.gov > > >> > > >> National Institute of Standards & Technology > > >> Manufacturing Systems Integration Division > > >> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > > >> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > >> > > >> "The opinions expressed above do not reflect consensus of NIST, > > >> and have not been reviewed by any Government authority." > > >> > > >> > > > > > > > -- > > Edward J. Barkmeyer Email: edbark@nist.gov > > National Institute of Standards & Technology > > Manufacturing Systems Integration Division > > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > > Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > > > "The opinions expressed above do not reflect consensus of NIST, > > and have not been reviewed by any Government authority." > > > > > > -- > Edward J. Barkmeyer Email: edbark@nist.gov > National Institute of Standards & Technology > Manufacturing Systems Integration Division > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > "The opinions expressed above do not reflect consensus of NIST, > and have not been reviewed by any Government authority." > > -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-19_04:2011-10-19,2011-10-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110190163 Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) From: keri Date: Wed, 19 Oct 2011 08:07:20 -0700 Cc: Mark H Linehan , "sbvr-rtf@omg.org" To: edbark@nist.gov X-Mailer: Apple Mail (2.1084) On Oct 19, 2011, at 7:28 AM, Ed Barkmeyer wrote: > ... there is no relationship of your proposal to Issue 13138 ... Yes - this topic was pulled from 13138. 13138 has gone to ballot. The subject title should now read 16610 (Mark's new issue, which picks up the discussion). Keri Date: Wed, 19 Oct 2011 13:47:47 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p9JHlqtr022581 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1319651274.23931@9SfDx5RkFLnAcZ8kiZfA5Q X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark H Linehan wrote: Ed, I do not agree that " 'concept is closed in conceptual schema' is entirely about communicating exactly the list of members of the extension (in fact models that use it)". The existing SBVR definition of 'concept is closed in conceptual schema' is not about "communicating", it is about the _content _of fact models. Fact models need not be used for communication; they can also be used for just keeping track of facts. My intention is that asserting the fact "that "the RTF concept is closed" in a fact model means that the fact model has "exactly the list of members of the extension" of the concept. The relationship of a fact model to communities is a separate issue. Now we are definitely talking past each other. My comment was on 'concept has completely known extension' which is (still) in the text of the 2011-10-14 draft of the resolution to Issue13138. The idea of asserting that a 'concept is closed' within a fact model is a statement /about/ that fact model (which opens a whole new can of worms). I think the distinction here is that you see 'fact model' as 'a body of knowledge about a possible world'. But that is different from the general body of knowledge possessed by an individual or a community. That 'body of knowledge' is a delimited thing, and it needs a mechanism of reference, so that we can say that the concept is closed in that particular body of knowledge -- that particular body of knowledge includes all the instantiation facts. Ostensibly, that would make the fact type binary: 'concept is closed in fact model' or 'concept is closed in body of knowledge'. The idea that a form of expression of that fact type might imply the specific body of knowledge is in turn related to the issue of the form of expression of the body of knowledge itself. That is, the interpretation of the pseudo-unary fact type: 'concept is closed' is that the body of knowledge that is represented by this 'body of knowledge expression' is a body of knowledge in which the concept is closed. 'the body of knowledge that is represented by this body of knowledge expression' is a definite description of the thing that plays the unstated role. The concept is "pseudo-unary" because the unstated role is present, and is specific; it is not existentialized. We don't mean "/some/ body of knowledge contains all the instantiation facts"; we mean this one does. In summary: you think the "closed world" concept is about communicating knowledge. Yes. SBVR is all about communicating knowledge. Therefore, any notion of closure applies to a body of knowledge as communicated using SBVR. I think it is about the nature of knowledge (i.e. a characteristic of the knowledge representation), regardless of whether it is communicated. The nature of the knowledge is what is actually in your head. That idea applies to everything SBVR calls a 'meaning' or a 'body of meaning'. Saying that your private 'body of meaning' includes knowledge of all the instances may be useful, if you communicate the information that Mark Linehan has that knowledge. The only knowledge we share is what is communicated. That knowledge becomes part of a 'body of shared knowledge' exactly when we communicate it. The idea of separating 'meaning' from 'expression of meaning' is to support the fact that a given 'meaning' can have multiple forms of expression, and those forms of expression can appear in different packages. But we are only interested in the meanings that have at least one form of expression. An SBVR 'concept' for which no designation, definition or formulation is provided has no meaning at all. Similarly, closure of a concept is only useful as a description of a form of expression, or as a description of the knowledge of an agent that can produce such a form of expression. That is my position. If we clearly disagree, there is no need for further discussion. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Ed Barkmeyer To: Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 10/19/2011 10:29 AM Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution (2011-10-13) ------------------------------------------------------------------------ Mark H Linehan wrote: > Ed, > > I do not know why we miscommunicate. It is because we obviously have different concerns. > I thought I was very clear that I do NOT suggest that OMG shares the > fact that "RTF concept is closed" with others. So the scenario you > describe is NOT the one that I am proposing. > > I am suggesting that the OMG would share its conceptual schema but > NOT its fact that "the RTF concept is closed". So others could use a > shared conceptual schema without being "burdened" with the closure of > that concept. > > Since facts go in fact models (not conceptual schemas as I implied > below), OMG can assert this fact in its own fact model that is based > on the shared conceptual schema. The fact model is not shared, so > others would not "see" this fact. So your proposed fact type has nothing to do with communicating the exact list of members of the set that is the extension of the concept. Do we agree on that? If we do, then (1) since 'concept is closed in conceptual schema' is entirely about communicating exactly the list of members of the extension (in fact models that use it), there is no relationship of your proposal to Issue 13138. (2) I see no value whatsoever in your proposed fact type. It provides for neither a means of communication or an identification of a source of the information. What business purpose does it serve? (2) is why we are miscommunicating. -Ed > -------------------------------- > Mark H. Linehan > STSM, Model Driven Business Transformation > IBM Research > > > > From: Ed Barkmeyer > To: Mark H Linehan/Watson/IBM@IBMUS > Cc: "sbvr-rtf@omg.org" > Date: 10/18/2011 05:13 PM > Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft > Resolution (2011-10-13) > ------------------------------------------------------------------------ > > > > > > Mark H Linehan wrote: > > I don't agree with Ed's assertion that > > "In Mark's terms, that means that the person who > > conceives the possible world must know all of the instances of the > > concept, and have corresponding mental facts that correspond to those > > instantiations. But that creates a community of one person for the > > possible world." > > > > And "Mark > > wants to treat the 'closure of a concept' as a requirement on meanings > > that is completely separable from representation. It is possible to do > > that, but the consequence is weird: it says that you cannot actually > > conceive a world in which you don't know all the instances of the > > concept." > > > > Please note that defining a concept is independent of asserting a fact > > about the concept being "closed". One can do the former without the > > latter. For example, OMG can define the concept "SBVR-RTF" and say > > nothing about who knows or exchanges any information about the > > SBVR-RTF. OMG can then separately assert the "closed in conceptual > > schema" attribute of "SBVR-RTF" for itself, meaning that the OMG knows > > all the members of the SBVR-RTF but not that everyone else has that > > knowledge. > > All of this is quite true. What I was trying to say is that if OMG > asserts in its conceptual schema that the RTF concept is closed, I can' > t use that conceptual schema to share knowledge with OMG, and OMG can't > use it to share knowledge with me. And indeed, no one who does not know > all the RTF members can use the OMG conceptual schema to share knowledge > about the RTF. So, what purpose does that conceptual schema serve? The > OMG conceptual schema can be used to exchange knowledge about the RTF > within OMG, but the statement implies there is no need to exchange > knowledge about the RTF membership within OMG. And those of us who > don't know can't use the OMG schema, so it would appear to be useless > for the exchange of knowledge across the OMG/ignorant member boundary. > > > In summary: Ed assumes that definition and assertion of the existing > > "concept is closed in conceptual schema" verb concept (or my proposed > > "completely known" characteristic) will be accomplished in one > > conceptual schema. I suggest that, in many useful cases, facts about > > closure of concepts will be done in subordinate conceptual schemas > > that are shared by a subset semantic community. > > That may be so, but the problem is simply that a conceptual schema that > says that the population of a given concept is known within the semantic > community that uses that conceptual schema says that there is no need > for that community to exchange knowledge about that population. And the > conceptual schema that says the population is known cannot be used to > communicate in a larger community that does not universally have that > knowledge. That is, the people who would like to obtain that knowledge > can only use a schema that says that the knowledge anyone provides /may > be incomplete/. > > In short, the idea of making the 'knowing' community-wide, instead of > pointing to a particular source of the information, makes the proposed > fact type /useless/ for knowledge sharing. I know that I am ignorant; > it would be useful to know how I can improve the situation. > > -Ed > > > -------------------------------- > > Mark H. Linehan > > STSM, Model Driven Business Transformation > > IBM Research > > > > > > > > From: Ed Barkmeyer > > To: keri > > Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" > > > > Date: 10/14/2011 06:07 PM > > Subject: Re: issue 13138 -- SBVR RTF issue -- Updated Draft > > Resolution (2011-10-13) > > ------------------------------------------------------------------------ > > > > > > > > keri wrote: > > > Mark, Ed, > > > > > > Did these same questions arise for the fact types: *fact type is > > > internally closed in conceptual schema * and *concept /is closed > > > in /conceptual schema *? > > > > No. But it is a good question, because the answer is revealing. > > > > If a concept is closed in a conceptual schema, then every fact model > > that uses that conceptual schema explicitly identifies every instance of > > the concept. That is, there is a thing -- a fact model -- and that > > thing is the unit of communication between SBVR tools, any receiving > > tool can know that every instance of that concept in the possible world > > described by that fact model is explicitly identified as an instance of > > that concept in that fact model. > > > > The meaning of 'concept is closed in conceptual schema' provides a very > > clear way for software supporting SBVR to know exactly what set of > > things constitutes the extension of that concept. It explicitly says > > that you cannot 'share' ("exchange") the concept without explicitly > > sharing the specification of each of its instances. > > > > If the 'fact model' is taken to be a "meaning", then it is the body of > > knowledge about a possible world, which can be modeled as a set of facts > > about that world. In Mark's terms, that means that the person who > > conceives the possible world must know all of the instances of the > > concept, and have corresponding mental facts that correspond to those > > instantiations. But that creates a community of one person for the > > possible world. > > > > But the 'fact model' is also the unit of information exchange between > > SBVR tools, per clause 2. And the consequent requirement is that the > > exchange of a 'fact model' -- the representation of the fact model in > > XML -- must contain representations of all those facts, including all > > the instantiation facts. In that way, any recipient can also know > > exactly the set of things that is the extension of the concept in the > > possible world being described. > > > > The totality of clause 2 and clause 8.5 is not just that someone has to > > know the instances of the concept, but rather that s/he must express all > > those instances when s/he communicates about a possible world that makes > > use of the concept. In this area, SBVR is written to tie the > > conceptualization of the possible world (a meaning) to the expression of > > that conceptualization as a set of fact representations. > > > > The problems we are having arises from trying to do the usual SBVR thing > > of completely separating the meanings from their representations. Mark > > wants to treat the 'closure of a concept' as a requirement on meanings > > that is completely separable from representation. It is possible to do > > that, but the consequence is weird: it says that you cannot actually > > conceive a world in which you don't know all the instances of the > concept. > > > > Now, I can conceive 'member of the SBVR RTF', as a concept directly > > applicable to writing this email, and I don't know all the members. So > > the requirement that 'member of the SBVR RTF is closed' ("is known") > > would appear to make it impossible for me to conceive a world in which I > > know anything about RTF members. What that really means is that I don't > > use that conceptual schema in conceptualizing the world in which I am > > writing this email. The conceptual schema I am using does not contain > > Mark's would be fact. But my conceptual schema, or perhaps just my > > internal fact model, does tell me that the RTF membership list is > > available at the OMG website, if I need to know. > > > > My concern is that we provide the means of saying that a representation > > of the possible world includes representations of all the instantiation > > facts for that concept, which is the most important half of what SBVR > > currently specifies. You can't exchange them if you don't know them, > > but you can know them and not exchange them (you can keep the knowledge > > to yourself). So, I can't properly describe the RTF to someone without > > saying who all the members are. Fair enough. > > > > I agree that my 'record' concept is really something more general than > > what SBVR can currently support, because it doesn't restrict the > > 'communication content' objects to being communications of complete fact > > models for possible worlds. The 'record' concept is not something that > > SBVR v1.0 has, and we probably should not be adding it in an RTF, and > > almost certainly not in response to Issue 13138. > > > > At the same time, I don't see that Mark's concept is any way faithful to > > the intent of 'concept is closed in conceptual schema'. And that is > > simply because 'concept is closed in conceptual schema' is not really > > about meaning; it is about the content of fact models in an SBVR > > exchange. It is a pragmatic declaration that provides certain > > implementation capabilities that the 'open world assumption' undercuts. > > Mark is putting lily-white gloves on hands that were intended to go in > > the dirt. > > > > > > > If Donald's proposed replacement fact type were worded "concept /is > > > closed in /body of shared concepts" would these questions still apply? > > > > > > Maybe. Note that the meaning is expressed in terms of fact models that > > conform to the conceptual schema. Do we have the idea that fact models > > conform to a body of shared concepts? The point here is that a 'fact > > model' is said to be a body of knowledge, but it is used as a body of > > knowledge that is *expressed* in a 'communication'. It appears that the > > SBVR term for an expressed body of knowledge is 'communication content', > > but there is no link between 'communication content' and 'fact model' or > > 'body of shared concepts'. > > > > How much would we have to add to SBVR to support: > > concept is closed in body of shared concepts > > Definition: For each _communication content_ that is based on the > > _body of shared concepts_, the communication content conveys a fact > > model that contains a set of facts that explicitly specify the entire > > extension of _concept_ > > > > Then clause 13 and 15 is about the construction of SBVR-conformant > > communication content, which conveys a fact model and is based on a body > > of shared concepts. And I suspect that the closure rule is only > > intended to apply to the kind of communication content that is described > > in clauses 13 and 15. > > > > All in all, I think the RTF was unwise to pull on the 13138 thread. > > > > -Ed > > > > > > > > ~ Keri > > > > > > > > > On Oct 13, 2011, at 1:51 PM, Mark H Linehan wrote: > > >> *MHL>> My answers like this.* > > >> -------------------------------- > > >> Mark H. Linehan > > >> STSM, Model Driven Business Transformation > > >> IBM Research > > >> > > >> > > >> > > >> From: Ed Barkmeyer > > > >> To: Mark H Linehan/Watson/IBM@IBMUS > > >> Cc: "sbvr-rtf@omg.org " > > >> > > > >> Date: 10/13/2011 01:26 PM > > >> Subject: Re: FW: issue 13138 -- SBVR RTF issue -- Updated > Draft > > >> Resolution (2011-10-13) > > >> > > ------------------------------------------------------------------------ > > >> > > >> > > >> > > >> Mark/Donald, > > >> > > >> Given the proposed text about known extensions, is the following a > > >> legitimate use? > > >> > > >> There is a concept called "Fred's sales calls" > > >> The extension of Fred's sales calls is known. > > >> Therefore, I don't need to tell you about any of them. > > >> (signed) Fred > > >> > > >> *MHL>>I'm not sure what the question is about the example given > above.* > > >> *MHL>>It appears that the example is a letter directed, but > there's no > > >> indication* > > >> *MHL>>who it is directed. More importantly, are Fred and the > > >> addressee in the same* > > >> *MHL>>semantic community? If they are, then the line "*The extension > > >> of Fred's sales calls is known*"* > > >> *MHL>>makes sense to me. If they are not in the same semantic > > >> community, then* > > >> *MHL>>this line is not very meaningful.* > > >> > > >> Similarly, > > >> there is a concept 'boy in the band' > > >> John is a boy in the band > > >> Paul is a boy in the band. > > >> The extension of 'boy in the band' is known. > > >> > > >> You have to pay the band. Do you have to pay George? > > >> Well, since the extension of 'boy in the band is known', you must > know > > >> whether George is in the band or not. > > >> > > >> *MHL>>Yes.* > > >> > > >> Now, if your software has to actually process the invoice from > George, > > >> and decide whether to further it for payment or reject it, how > does it > > >> use this communal knowledge? > > >> > > >> *MHL>>The software operates within or on behalf of the semantic > > >> community for which* > > >> *MHL>>the "is known" statement is made -- right? After all, the > > >> software just automates* > > >> *MHL>>what otherwise could be done by hand, so it should have the > same > > >> knowledge that* > > >> *MHL>>"I" have. So what's the issue? It seems obvious that the > > >> software will consult the* > > >> *MHL>>extension of "boy in the band" to decide whether George is in > > >> the band, and* > > >> *MHL>>pay or not based on the result of that consultation.* > > >> > > >> Is this fact type useful to business? > > >> > > >> *MHL>>I think so.* > > >> > > >> -Ed > > >> > > >> > > >> > > >> > > >> -- > > >> Edward J. Barkmeyer Email: edbark@nist.gov > > >> > > >> National Institute of Standards & Technology > > >> Manufacturing Systems Integration Division > > >> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > > >> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > >> > > >> "The opinions expressed above do not reflect consensus of NIST, > > >> and have not been reviewed by any Government authority." > > >> > > >> > > > > > > > -- > > Edward J. Barkmeyer Email: edbark@nist.gov > > National Institute of Standards & Technology > > Manufacturing Systems Integration Division > > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > > Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > > > "The opinions expressed above do not reflect consensus of NIST, > > and have not been reviewed by any Government authority." > > > > > > -- > Edward J. Barkmeyer Email: edbark@nist.gov > National Institute of Standards & Technology > Manufacturing Systems Integration Division > 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 > Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 > > "The opinions expressed above do not reflect consensus of NIST, > and have not been reviewed by any Government authority." > > -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: "Donald Chapin" To: "sbvr-rtf " Subject: RE: [containers and bigger problems] Date: Thu, 13 Oct 2011 13:52:09 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyJputvtEU/cpMUTYuFdaBmyx6VfQ== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E96DEFA.00D9, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.13.113020:17:7.944, ip=81.149.51.65, rules=__TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __HAS_MSGID, __SANE_MSGID, __MIME_VERSION, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, LINK_TO_IMAGE, INFO_TLD, __CP_URI_IN_BODY, __CP_MEDIA_2_BODY, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_70_90, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E96DF6F.0049,ss=1,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 Ron, The following Issues mentioned in your email below have already been disposed and balloted successfully: Issue 12542 SBVR RTF-1 Ballot 1 Issue 15151 SBVR RTF-1 Ballot 4 Donald From: Ronald G. Ross [mailto:rross@brsolutions.com] Sent: 12 October 2011 21:25 To: sbvr-rtf@omg.org Subject: [containers and bigger problems] RE: FW: issue 13138 -- SBVR RTF issue -- Updated Draft Resolution All, [The important part is at the bottom.] For some time we have been using the word "container" as a catch-all term to talk about various things in SBVR, including (as I understand): * body of shared meanings * body of shared concepts * body of shared guidance * vocabulary * business vocabulary * terminological dictionary * rulebook * conceptual schema * fact model "Container" is a misleading term. MWUD defines "container" as: "one that contains: as (a): a receptacle (as a box or jar) or a formed or flexible covering for the packing or shipment of articles, goods, or commodities". MWUD gives conflicting definitions for "contain", includng: 2a: to have within : HOLD *the box contained only some old papers and a few odds and ends* 2b: to consist of wholly or in part : COMPRISE, INCLUDE *the bill contains several new clauses* 2c: ENCLOSE *the building contains classrooms and an auditorium*". The term we should be using is "aggregation". This is the closest business term that fits things of this nature. (See my issue 19523.) Here is the relevant MWUD definition: 2: a group, body, or mass composed of many distinct parts : ASSEMBLAGE. Yes, it's Ron being Ron, but we should call things by the closest real-world terms wherever possible. Mark has had outstanding issues (e.g., 12540, 12541, 12542, 15151) pending since 2008 about how these aggregations (my word) relate to each other and how they should be used by tools. I have also raised various related issues. But the problem is even more fundamental. Ed made the following comment in a recent e-mail which has really stuck with my like a burr under a saddle: "For the record, this is why SBVR is useless for the exchange of 'vocabularies'. There is no agreement on which of these collections a business vocabulary management tool should exchange. Compare with SKOS, which has one structure with some (not many) content options. The consequence of supporting every special nuance is defeating interoperability. We would suggest that SBVR needs terminological dictionary, rulebook and fact model, and the rest are academic." This is *very* discouraging ... and I don't think I'm speaking just for Ed and myself. I want some resolution and progress NOW on these issues. How can we resolve them for 1.1? First let me say that I am appalled by the lack of thought given to presentation, organization and explanation in Clauses 8, 9, and 11. (Yes, again Ron being Ron, but it is inexcusably naive to think that good idea sell themselves just because they are good.) Can we create a new section in Clause 11 and put at least the specific aggregations SBVR is meant to exchange in it (and say so clearly) and work out how they relate? Three years is too long for issues like these to sit on the table. WE DON'T HAVE FOREVER. Ron Blog || http://www.RonRoss.info/blog/ LinkedIn || http://www.linkedin.com/pub/ronald-ross/1/3b/346 Twitter || https://twitter.com/Ronald_G_Ross Homepage || http://www.RonRoss.info