Issue 14241: Coexistence approach to SBVR (sbvr-rtf) Source: PNA Group (Dr. Sjir Nijssen, sjir.nijssen(at)pna-group.com) Nature: Clarification Severity: Critical Summary: According to our observations, more than 95% of all business applications operate under the closed world assumption and the state of affairs interpretation. In order to give other approaches (standards) the option to work with SBVR, it is proposed to offer the following: for each fact type one of the following combinations can be selected: 1. Closed world assumption; state of affairs interpretation 2. Closed world assumption; actuality interpretation 3. Open world assumption; state of affairs interpretation 4. Open world assumption; actuality interpretation. For convenience it is recommended to add the following four meta fact types: 1. The population of all fact types in <conceptual schema> is considered <closed_or_open> 2. The population of all fact types in <conceptual schema> is considered <state-of-affairs_or_actuality> 3. The population of <fact type> is considered <closed_or_open> 4. The population of <fact type> is considered <state-of-affairs_or_actuality> Note that a fact type overrides a conceptual schema specification. Note that there is a business rule that for each fact type it holds that it can have only one value of closed_or_open and one value of state-of-affairs_or_actuality. Resolution: Revised Text: Actions taken: September 2, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 02 Sep 2009 06:28:04 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Sjir Nijssen Company: PNA University mailFrom: Sjir.Nijssen@PNA-Group.NL Notification: Yes Specification: SBVR Section: 8.5, 8.6, 10.1.1.3 FormalNumber: formal/2008-01-02 Version: 1.0 RevisionDate: 01/02/2008 Page: 37, 39, 91-96 Title: Coexistence approach to SBVR Nature: Clarification Severity: Critical test: 3qw8 B1: Report Issue Description: According to our observations, more than 95% of all business applications operate under the closed world assumption and the state of affairs interpretation. In order to give other approaches (standards) the option to work with SBVR, it is proposed to offer the following: for each fact type one of the following combinations can be selected: 1. Closed world assumption; state of affairs interpretation 2. Closed world assumption; actuality interpretation 3. Open world assumption; state of affairs interpretation 4. Open world assumption; actuality interpretation. For convenience it is recommended to add the following four meta fact types: 1. The population of all fact types in is considered 2. The population of all fact types in is considered 3. The population of is considered 4. The population of is considered Subject: RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 X-KeepSent: 32E5AAEA:CE931DEC-85257634:006D44D8; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Thu, 17 Sep 2009 16:46:58 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.2FP1 ZOS802FP1HF3|June 25, 2009) at 09/17/2009 16:47:02 Sjir, Regarding 14241 -- by default, fact types are open-world, but SBVR does have the ability to identify specific fact types as closed world. See clause 8.5, "fact type is internally closed in conceptual schema" and "concept is closed in conceptual schema". I think that address part of what you ask. I'm not sure what you mean by "state of affairs interpretation" versus "actuality interpretation" of a fact type. I think it is important that an individual fact type can be used with both interpretations. "Don visits Poland" is a state of affairs before he does the visiting, but becomes an actuality once he visits. To put it another way, interpretations apply to instances of fact types, not fact types themselves. Regarding your comment "Suppose we add to these two facts the third fact: Don Basley has not visited, we get in both worlds the answer No. In fact this option is avaialable in clause 10 but there is no fact type in Clause 8 to declare it." This statement can be formulated using clause 9. It is simply the negation of the formulation "Don Baisley has visited". I am interested in your statement that "More than 95 percent of the business systems work on the state of affairs view". I think what you are saying is that in most cases, businesses take what is recorded in information systems as facts (i.e. "propositions taken to be true"). They treat the information records as facts independent of the state of the real world. I don't think I would call this the "state of affairs view". The issue here is about belief, not really about actualities versus states of affairs. I agree that ground fact examples really help the discussion. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Sjir Nijssen" ---09/17/2009 03:23:01 PM---To all, "Sjir Nijssen" 09/17/2009 03:21 PM To , "SBVR RTF" cc Subject RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 To all, I have proposed 14241 to give SBVR a possibility to serve more than one small community. Let the SBVR user decide which of the four options he wants to use. ([State-of-affairs, Closed-world], [State-of-affairs, Open-world], [Actuality, Closed-world], [Actuality, Open-world] I happen to have studied Larson and Segal. There are many good things in it but this book has very little to do with 14241, is my opinion. Suppose we have the following two facts in our register: Don Baisley has visited Germany; Don Baisley has visited Spain. If we ask in the closed world: has Don Baisley visited Poland, the answer will be no. If we ask the same question in the open world: the answer is: I don't know. Suppose we add to these two facts the third fact: Don Basley has not visited, we get in both worlds the answer No. In fact this option is avaialable in clause 10 but there is no fact type in Clause 8 to declare it. With respect to actuality and state of affairs. More than 95 percent of the business systems work on the state of affairs view. If you state that you have a passport of the Netherlands and a Dutch border police checks it is available in the Dutch registry of passports and he does not find it there, then you have no passport. Of course you can go to court and several months later the judge may decide on yes or no of having the passport, but these are the exceptions. There is simply not enough time to work with the actuality view in general but 14241 still makes it possible. If you are in a hospital and the last measured blood sugar is 23, then the doctors will act on this state of affairs. There is no reliable way to talk about actuality of blood sugar. Of course there are other examples where this is possible. If in EU-Rent, car A, B and C are according to the system available in the branch store, and if car B is assigned to a renter and the renter goes to the store to pick up car B and comes back and says: but only car A and C are there, not B, then I would assume that a new fact is generated: Car B is not any longer available, of course after the clerk has checked the store. I hope we will use in the future more examples at the ground fact level to illustrate a discussion. Kind regards Sjir Nijssen -------------------------------------------------------------------------------- Van: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Verzonden: do 17-9-2009 20:42 Aan: 'SBVR RTF' Onderwerp: FW: -- states of affairs An earlier discussion of how SBVR handles âstate of affairsâ. Donald -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: 20 June 2007 16:17 To: sbvr-ftf@omg.org Subject: RE: SBVR Issue 9948 -- roles and states of affairs The use of âexistsâ in logic should not be confused with the meaning of âholdsâ as it applies to states of affairs. The word âoccursâ is often a more natural word to use for âholdsâ. A state S1 that holds is an actuality. A state S2 that does not hold now, but will hold in the future, is not now an actuality. But the state S3 that S2 will hold in the future is an actuality. A state S4 that does not hold now, but did hold in the past, is not an actuality. But the state S5 that S4 did hold in the past is an actuality. The states S1, S2, S3, S4 and S5 all exist. They are all subjects of discourse regardless of whether or not they are actualities. Being able to refer to states as things that exist, even while they do not hold (occur) is vital to being able to map natural language into logic. It is necessary to the understanding of adverbs, tense and adjuncts as they occur within sentences. I recommend Knowledge of Meaning by Richard Larson and Gabriel Segal as a good book that covers this. But there are others. I donât have time to go into lots of detail on this. So please read books on the subject if you want to dig into it deeper. SBVRâs model of states of affairs and actualities works. Regards, Don Subject: RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 18-0751 1601 X-KeepSent: AB44E27F:C5BBD0E0-85257635:004E3676; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Fri, 18 Sep 2009 10:27:10 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.2FP1 ZOS802FP1HF3|June 25, 2009) at 09/18/2009 10:27:45 Sjir, Regarding changing the default in SBVR from "open world" to "closed world" -- I don't agree that this is desirable, although to some extent the default choice is arbitrary. See the discussion about this in the introduction to clause 10 and in section 10.1.1.3. Regarding your point "[Sjir: I only propose in 14241 to make it conveniently available to the business modeller, or conceptual schema specifier.]" -- I believe that making something "conveniently available" is up to the designer of the modeling tool. There's no reason why such a tool can't by default make all fact types closed and then open them up only on the request of the business modeler. Regarding your suggestion: "[Sjir: Mark, I like to propose to use a representative set of examples at the ground fact level, develop from them the domain specific and from there the generic conceptual schema. Would you be willing to agree with that procedure?]" Personally I think this could be productive, but the suggestion would need to be taken up by the RTF as a whole. So I look to the RTF leaders as to whether they would like to adopt your methodology for this discussion. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Sjir Nijssen" ---09/18/2009 10:03:06 AM---Dear Mark, "Sjir Nijssen" 09/18/2009 10:01 AM To Mark H Linehan/Watson/IBM@IBMUS, cc Subject RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 18-0751 1601 Dear Mark, See below in [ ] Sjir Nijssen Directie PNA Group Tel: +31 (0)45-56 00 222 Fax: +31 (0)45-56 00 062 E-mail: sjir.nijssen@pna-group.nl ---------------------------------------------------- http://www.pna-group.nl -------------------------------------------------------------------------------- From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: vrijdag 18 september 2009 14:51 To: sbvr-rtf@omg.org Subject: RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 18-0751 Sjir, The SBVR default is "open world" because the intended use of SBVR is modeling the real world as businesses encounter it. And the real world is "open world", meaning that businesses generally don't know everything. [Sjir: Mark, according to my experience and observations businesses rely more on the closed World than the open World. Why do I come to this conclusion? The majority of current business applications run on a relational database using SQL .] If SBVR were primarily intended to model business applications, I would agree with you about the default. But it's not. [Sjir: the question is whether this could not be changed. ]In any case, SBVR does support both "closed world" and "open world" semantics.[Sjir: I only propose in 14241 to make it conveniently available to the business modeller, or conceptual schema specifier.] I repeat that I disagree with you that Clause 8 needs special support for "Don Baisley has not visited Poland". Clause 8 defines how you model a fact type such as "person has visited place". Clause 9 defines how you formulate expressions such as "Don Baisley has visited Poland". Clause 9 also defines how you formulate the negation of such an expression. The concepts of "actualities" versus "states of affairs", "facts", and "propositions" is actually a current discussion topic of the RTF. We can't pinpoint the problem yet, but there does seem to be something wrong with how these concepts relate to each other and "fact type". Think about it this way from the point-of-view of databases: a database contains a set of what are believed to be "facts", for example my office phone number. These facts may or may not reflect reality, they may not be "actual". For example, if I have just changed offices, then my real phone number and the database entry may not be in synch. Now consider that the database might have a list of my past phone numbers. Clearly, most of the phone numbers are not "actual" as of today. SBVR would say that my "having" these phone numbers are "states of affairs". One possible problem with SBVR seems to be that "actual" is with respect to a particular time ("possible world") but the SBVR metamodel doesn't seem to reflect that. Another problem is that the relationship between "facts" and "actualities" is unclear. I agree with your point that this is quite philosophical, but I believe we need to sort this out in order to achieve consistency in this aspect of the SBVR metamodel. [Sjir: Mark, I like to propose to use a representative set of examples at the ground fact level, develop from them the domain specific and from there the generic conceptual schema. Would you be willing to agree with that procedure?] -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Sjir Nijssen" ---09/18/2009 01:51:16 AM---Hi Mark, "Sjir Nijssen" 09/18/2009 01:51 AM To Mark H Linehan/Watson/IBM@IBMUS, cc Subject RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 18-0751 Hi Mark, Thank you very much for your clear email. Closed open As the vast majority of business application operates under the closed word assumption, I propose to make the default closed. From an SBVR marketing point of view I believe it is better to show that we respect what the majority practices. See further below between [[[[[[[[[[[[[[ ]]]]]]]]]]]]]]]]]]]]]] I believe the 14241 proposal makes SBVR more attractive to a much wider business audience than it is today. Kind regards Sjir -------------------------------------------------------------------------------- Van: Mark H Linehan [mailto:mlinehan@us.ibm.com] Verzonden: do 17-9-2009 22:46 Aan: sbvr-rtf@omg.org Onderwerp: RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 Sjir, Regarding 14241 -- by default, fact types are open-world, but SBVR does have the ability to identify specific fact types as closed world. See clause 8.5, "fact type is internally closed in conceptual schema" and "concept is closed in conceptual schema". I think that address part of what you ask. I'm not sure what you mean by "state of affairs interpretation" versus "actuality interpretation" of a fact type. I think it is important that an individual fact type can be used with both interpretations. "Don visits Poland" is a state of affairs before he does the visiting, but becomes an actuality once he visits. To put it another way, interpretations apply to instances of fact types, not fact types themselves. Regarding your comment "Suppose we add to these two facts the third fact: Don Basley has not visited, we get in both worlds the answer No. In fact this option is avaialable in clause 10 but there is no fact type in Clause 8 to declare it." [[[[[[[[Sjir: Mark, This would be solved by 14241]]]]]]]]]]]]]]]This statement can be formulated using clause 9. [[[[[[[[[[[[Sjir: I believe clause 8 is the right plave to bring in the options of 14241]]]]]]]]]]]]]]]]]It is simply the negation of the formulation "Don Baisley has visited". I am interested in your statement that "More than 95 percent of the business systems work on the state of affairs view". I think what you are saying is that in most cases, businesses take what is recorded in information systems as facts (i.e. "propositions taken to be true"). They treat the information records as facts independent of the state of the real world. I don't think I would call this the "state of affairs view". The issue here is about belief, not really about actualities versus states of affairs.[[[[[[[[[[[[[[Sjir: I would propose that the SBVR explanations shift a bit more to an optimum wrt business understanding as opposed to philosophical point of view that are considered of little relevance by the business.]]]]]] I agree that ground fact examples really [[[[[[[[[[[[[[[[[[[[[[Sjir: I really like this word.Thanks very much]]]]]]]]]]]]]]]]]]]]help the discussion. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Sjir Nijssen" ---09/17/2009 03:23:01 PM---To all, "Sjir Nijssen" 09/17/2009 03:21 PM To , "SBVR RTF" cc Subject RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 To all, I have proposed 14241 to give SBVR a possibility to serve more than one small community. Let the SBVR user decide which of the four options he wants to use. ([State-of-affairs, Closed-world], [State-of-affairs, Open-world], [Actuality, Closed-world], [Actuality, Open-world] I happen to have studied Larson and Segal. There are many good things in it but this book has very little to do with 14241, is my opinion. Suppose we have the following two facts in our register: Don Baisley has visited Germany; Don Baisley has visited Spain. If we ask in the closed world: has Don Baisley visited Poland, the answer will be no. If we ask the same question in the open world: the answer is: I don't know. Suppose we add to these two facts the third fact: Don Basley has not visited, we get in both worlds the answer No. In fact this option is avaialable in clause 10 but there is no fact type in Clause 8 to declare it. With respect to actuality and state of affairs. More than 95 percent of the business systems work on the state of affairs view. If you state that you have a passport of the Netherlands and a Dutch border police checks it is available in the Dutch registry of passports and he does not find it there, then you have no passport. Of course you can go to court and several months later the judge may decide on yes or no of having the passport, but these are the exceptions. There is simply not enough time to work with the actuality view in general but 14241 still makes it possible. If you are in a hospital and the last measured blood sugar is 23, then the doctors will act on this state of affairs. There is no reliable way to talk about actuality of blood sugar. Of course there are other examples where this is possible. If in EU-Rent, car A, B and C are according to the system available in the branch store, and if car B is assigned to a renter and the renter goes to the store to pick up car B and comes back and says: but only car A and C are there, not B, then I would assume that a new fact is generated: Car B is not any longer available, of course after the clerk has checked the store. I hope we will use in the future more examples at the ground fact level to illustrate a discussion. Kind regards Sjir Nijssen -------------------------------------------------------------------------------- Van: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Verzonden: do 17-9-2009 20:42 Aan: 'SBVR RTF' Onderwerp: FW: -- states of affairs An earlier discussion of how SBVR handles âstate of affairsâ. Donald -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: 20 June 2007 16:17 To: sbvr-ftf@omg.org Subject: RE: SBVR Issue 9948 -- roles and states of affairs The use of âexistsâ in logic should not be confused with the meaning of âholdsâ as it applies to states of affairs. The word âoccursâ is often a more natural word to use for âholdsâ. A state S1 that holds is an actuality. A state S2 that does not hold now, but will hold in the future, is not now an actuality. But the state S3 that S2 will hold in the future is an actuality. A state S4 that does not hold now, but did hold in the past, is not an actuality. But the state S5 that S4 did hold in the past is an actuality. The states S1, S2, S3, S4 and S5 all exist. They are all subjects of discourse regardless of whether or not they are actualities. Being able to refer to states as things that exist, even while they do not hold (occur) is vital to being able to map natural language into logic. It is necessary to the understanding of adverbs, tense and adjuncts as they occur within sentences. I recommend Knowledge of Meaning by Richard Larson and Gabriel Segal as a good book that covers this. But there are others. I donât have time to go into lots of detail on this. So please read books on the subject if you want to dig into it deeper. SBVRâs model of states of affairs and actualities works. Regards, Don (See attached file: graycol.gif)(See attached file: pic10113.gif)(See attached file: ecblank.gif) From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: SBVR issue 14241 Thread-Topic: SBVR issue 14241 Thread-Index: Acp6AwUkFuwRC6kBTK2qQZmB9VGabA== Date: Fri, 11 Dec 2009 01:41:12 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: I was asked to write some points about issue 14241. Here they are: Part 1 . open and closed. I think the issue of open/closed world assumptions belongs outside of clause 8. These assumptions are not about concepts or concept systems. They are about information systems, so the open/closed fact types belong in clause 10 if anywhere in SBVR. Information systems often assume a closed world. I agree with Sjir in this regard. If we assume a relational foundation, then .open. and .closed. are relevant concepts with respect to relations. A relation typically would map to an SBVR verb concept plus a reference scheme for each role of the verb concept. A missing fact within a model can often be taken as implying a negation of the missing fact. Clauses 8 and 9 lead us to derive knowledge from a combination of other knowledge plus logical necessities such as those understood through definitions and structural rules. A closed world assumption for a conceptual schema or any concept within it is just a shorthand for being able to derived negative facts from the absence of positive facts within a fact model. That additional convenience of deriving knowledge from the absence of contrary facts in a fact model is handy for information systems, especially systems that fall within a rigid structure. I would prefer to see this sort of convenience separated from the concept-based semantics covered in clause 8. And, if moved to clause 10, I don.t mind having .closed. be the default and .open. be the exception, but that is because the matter is then moved cleanly away from the question of the meanings of terms. Note that natural language statements and SBVR semantic formulations, unlike relational models and RDF, make it easy to have explicit closures, so I don.t need to rely on open/closed assumptions. E.g., consider the difference between these statements (each of which can be structured using semantic formulations): 1. The sons of Don are Nathan and Josh. 2. Nathan is a son of Don. Josh is a son of Don. Number 1 tells me more than number 2. The definite article in 1 makes clear that the full extension of Don.s sons is {Nathan, Josh}. But number 2 leaves open the possibility of there being other sons. Choosing an open or closed world assumption limits me to having to pick either 1 or 2, but not both, for a whole model or for everything of some type. But semantic formulations allow me to formulate either way, even within the same model. I can formulate exactly what I mean in each case. I can mix and match in the same model. SBVR semantic formulations do not leave me in the flat world of tables where I would need to pick one or the other. I can be explicit in every case. Also, rules about what should be assumed based on lack of information should be just that, rules. E.g., this sort of thing should be handled as a rule: A person must be considered to have no passport if the person is not listed in the Dutch passport-holders registry. Part 2 . facts and actualities. In order to accommodate the case that Sjir raises, we were careful to define .fact. so that it does not necessarily correspond with an actuality. A fact is merely .taken as true.. We do not define it as .proposition that is true.. A fact need not be true. So the interpretation that Sjir wants is what we already have. Note that it is important to keep .taken as true. and not abandon it for .either true or false., which would leave us with the full breadth of .proposition.. It would not be helpful for every possible proposition to be automatically a fact. Best regards, Don Subject: Re: SBVR issue 14241 X-KeepSent: 03B22744:62E9E5AF-85257689:004F9AD9; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Fri, 11 Dec 2009 12:20:22 -0500 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 12/11/2009 12:20:32 Regarding open & closed worlds -- I think it is a mistake to drop this concept from SBVR. And if it is not in clause 8, then it really is not in SBVR. Having it in clause 10 but not clause 8 says that the universe of meanings that we understand formally is larger than the universe of meanings that we can express in the vocabulary. That seems quite wrong. Some have suggested that identifying closed vs open world aspects of a vocabulary should be performed when mapping from vocabularies to information technology systems. This is a methodological choice, and should not be presupposed by the SBVR metamodel. In some use cases, the fact that a part of a vocabulary is closed may be known **at the business level**. In some cases, the set of things that makeup the closed world concept will be a set of individual concepts and could take the form that Don suggests in example #1 below. For example, "the Ford Mustang is available in red, blue, and green" could be understand as defining the complete set of colors. But other use cases may involve concept instances that are not individual concepts. For example, "each descendent of John D. Rockefeller shall have an interest in the Rockefeller trust". This rule makes a presumption that the set of descendents of Rockefeller can be determined at any point in time, but the complete set was certainly not known when the rule was written. The reason this matters is that an SBVR tool may be able to help users write more effective rules if the vocabulary distinguishes open vs closed world concepts. Note that the open vs closed world distinction is not just about negations because it also affects quantification. Rules such as "if there exists at least one descendent of Rockefeller ...." and "if all descendents of Rockefeller ..." are meaningful only if the set of descendents can be fully enumerated when the rule is evaluated. A negation in the production rules sense is just the negative of "there exists ...". The example that Don gives, "A person must be considered to have no passport if the person is not listed in the Dutch passport-holders registry" is only meaningful if we can make a closed world assumption about "is not listed in the registry." Under the default open-world assumption, the possible answers to this proposition are "is listed" and "unknown whether it is listed". A good tool should say "not listed" is logically invalid under the open world assumption. I think the open world default that is presently used by SBVR is the right choice. And clause 8.5 already provides for "local closure" of specific concepts. I think that's exactly what we need. I agree with Don that we need to keep the current definition of facts as "propositions taken to be true". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley ---12/10/2009 08:43:37 PM---I was asked to write some points about issue 14241. Here they are: Don Baisley 12/10/2009 08:41 PM To "'SBVR RTF' (sbvr-rtf@omg.org)" cc Subject SBVR issue 14241 I was asked to write some points about issue 14241. Here they are: Part 1 . open and closed. I think the issue of open/closed world assumptions belongs outside of clause 8. These assumptions are not about concepts or concept systems. They are about information systems, so the open/closed fact types belong in clause 10 if anywhere in SBVR. Information systems often assume a closed world. I agree with Sjir in this regard. If we assume a relational foundation, then âopenâ and âclosedâ are relevant concepts with respect to relations. A relation typically would map to an SBVR verb concept plus a reference scheme for each role of the verb concept. A missing fact within a model can often be taken as implying a negation of the missing fact. Clauses 8 and 9 lead us to derive knowledge from a combination of other knowledge plus logical necessities such as those understood through definitions and structural rules. A closed world assumption for a conceptual schema or any concept within it is just a shorthand for being able to derived negative facts from the absence of positive facts within a fact model. That additional convenience of deriving knowledge from the absence of contrary facts in a fact model is handy for information systems, especially systems that fall within a rigid structure. I would prefer to see this sort of convenience separated from the concept-based semantics covered in clause 8. And, if moved to clause 10, I donât mind having âclosedâ be the default and âopenâ be the exception, but that is because the matter is then moved cleanly away from the question of the meanings of terms. Note that natural language statements and SBVR semantic formulations, unlike relational models and RDF, make it easy to have explicit closures, so I donât need to rely on open/closed assumptions. E.g., consider the difference between these statements (each of which can be structured using semantic formulations): 1. The sons of Don are Nathan and Josh. 2. Nathan is a son of Don. Josh is a son of Don. Number 1 tells me more than number 2. The definite article in 1 makes clear that the full extension of Donâs sons is {Nathan, Josh}. But number 2 leaves open the possibility of there being other sons. Choosing an open or closed world assumption limits me to having to pick either 1 or 2, but not both, for a whole model or for everything of some type. But semantic formulations allow me to formulate either way, even within the same model. I can formulate exactly what I mean in each case. I can mix and match in the same model. SBVR semantic formulations do not leave me in the flat world of tables where I would need to pick one or the other. I can be explicit in every case. Also, rules about what should be assumed based on lack of information should be just that, rules. E.g., this sort of thing should be handled as a rule: A person must be considered to have no passport if the person is not listed in the Dutch passport-holders registry. Part 2 . facts and actualities. In order to accommodate the case that Sjir raises, we were careful to define âfactâ so that it does not necessarily correspond with an actuality. A fact is merely âtaken as trueâ. We do not define it as âproposition that is trueâ. A fact need not be true. So the interpretation that Sjir wants is what we already have. Note that it is important to keep âtaken as trueâ and not abandon it for âeither true or falseâ, which would leave us with the full breadth of âpropositionâ. It would not be helpful for every possible proposition to be automatically a fact. Best regards, Don pic02147.gif Date: Mon, 14 Dec 2009 14:30:13 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Don Baisley CC: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: Re: SBVR issue 14241 X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: nBEJTN6D024335 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1261423766.30421@5kFtFjZYasZuXvUOn/XVWQ X-Spam-Status: No I agree with Mark on this point. The Open World Assumption, or the Closed World Assumption, or some other base rule, is a part of the interpretation of statements in formal logic systems. Every collection of formal statements must be understood in the light of some such rule. It applies to quantifiers, and it affects the interpretation of negation. I prefer the idea, as Don does, that the basic assumption of SBVR is "open world". But it is clear that we need to say that. Further, it is clear to me that we cannot serve business users without providing for explicit "half-open" or "closed" concepts in conceptual schemas defined in SBVR. Don Baisley wrote: I was asked to write some points about issue 14241. Here they are: Part 1 ­ open and closed. I think the issue of open/closed world assumptions belongs outside of clause 8. These assumptions are not about concepts or concept systems. This is true. They are about interpreting propositions, not concepts. They are about information systems, True, but not exclusively. They apply to formal systems of knowledge, which is a supertype of 'information system'. so the open/closed fact types belong in clause 10 if anywhere in SBVR. This does not follow. Clause 10 is supposed to be a background terminology that is used in definitions in clause 8,9,11 and 12. It should be an Annex. By comparison, clause 9 and clause 13 are about information systems. But in fact, the OWA/CWA is a necessary, or at least applicable, concept in exactly the domains addressed by 8, 9, 11, and 12. Information systems often assume a closed world. True. I agree with Sjir in this regard. If we assume a relational foundation, then .open. and .closed. are relevant concepts with respect to relations. A relation typically would map to an SBVR verb concept plus a reference scheme for each role of the verb concept. Relations are the fundamental notion in mathematical logic. They SBVR equivalent is 'fact type'. And open/closed is an important concept with respect to 'relations' (fact types), as they are used in knowledge bases (formulations of knowledge as propositions) of all kinds. The relational _algebra_ foundation is a technical algebra that generalizes the logical notion of relation to include groupings of information that represent propositions but don't have a consistent mapping to them. In particular, one row can represent multiple conjoined propositions. But it is just a special case of the general problem of open/closed. A missing fact within a model can often be taken as implying a negation of the missing fact. Exactly. Under the closed world assumption, at the time of decision, every fact is a statement in the knowledge base. So no statement implies no fact, i.e., the proposition is false. For example, the test for whether a given party is a customer may be an examination of our customer files. If the party is not in the files, he is not a customer. But we will only make that test when we are applying a rule that begins "If x is a customer...". If we apply a rule like "if x has been the target of a sales contact, x is a customer", that should cause the customer files to be modified to add x. So we can have a kind of closed world assumption about customers and still infer new facts about customer-ness. Some logics refer to this case as "half-open". Clauses 8 and 9 lead us to derive knowledge from a combination of other knowledge plus logical necessities such as those understood through definitions and structural rules. A closed world assumption for a conceptual schema or any concept within it is just a shorthand for being able to derived negative facts from the absence of positive facts within a fact model. That additional convenience of deriving knowledge from the absence of contrary facts in a fact model is handy for information systems, especially systems that fall within a rigid structure. More than that, it is related to the handling of knowledge about a world that changes. Mathematical logic is said to be "monotonic" -- nothing that is false today will be true tomorrow, and nothing that is true today will be false tomorrow. You can learn things you didn't know, but you can't learn anything that wasn't always true. But business is not monotonic: what is true now may be false later. So the closed world assumption is used to provide the necessary background for accidental properties that may change over time, like being a customer. I would prefer to see this sort of convenience separated from the concept-based semantics covered in clause 8. Well, "concept-based semantics" apparently provides an interpretation for "extension", and that interpretation relies on closed-world or open-world assumptions. And, if moved to clause 10, I don.t mind having .closed. be the default and .open. be the exception, but that is because the matter is then moved cleanly away from the question of the meanings of terms. Terms like "extension", "instance of", "actuality", etc. Do you want to move cleanly away from those? Note that natural language statements and SBVR semantic formulations, unlike relational models and RDF, make it easy to have explicit closures, so I don.t need to rely on open/closed assumptions. E.g., consider the difference between these statements (each of which can be structured using semantic formulations): 1. The sons of Don are Nathan and Josh. 2. Nathan is a son of Don. Josh is a son of Don. Number 1 tells me more than number 2. The definite article in 1 makes clear that the full extension of Don.s sons is {Nathan, Josh}. But number 2 leaves open the possibility of there being other sons. Choosing an open or closed world assumption limits me to having to pick either 1 or 2, but not both, for a whole model or for everything of some type. But semantic formulations allow me to formulate either way, even within the same model. I can formulate exactly what I mean in each case. I can mix and match in the same model. SBVR semantic formulations do not leave me in the flat world of tables where I would need to pick one or the other. I can be explicit in every case. Yes, you can. But many business rules are used to create lists of the things that can play a role, and the rules are applied incrementally, e.g.: 1. Nathan has signatory authority. 2. Josh has signatory authority. 3. Everyone who is appointed by Nathan or Josh has signatory authority. 4. No one else has signatory authority. If you have to write the expansion of rule 3 today, it will be wrong next week and will need to be rewritten. The use of closed world assumptions arises from the need to write rules like 3 and 4. There are many business rules in which the antecedent is defined by a list, and the list changes over time and in real business time. You can't get through the NIST gate today unless you have a Government badge or are (now) on the Approved Visitor list. Maybe tomorrow... Also, rules about what should be assumed based on lack of information should be just that, rules. E.g., this sort of thing should be handled as a rule: A person must be considered to have no passport if the person is not listed in the Dutch passport-holders registry. Exactly. Now, how do you tell whether the person "is not listed in the registry"? Do you have a statement in the knowledge base that Santa Claus is not listed in the registry? I would bet that there is only a list of the people who are registered. But in an open world, there could be others who are "listed in the registry" but those entries are not facts in your knowledge base. You have to say that the set of facts you have about the registry is closed, so that no such fact means "not listed". (In an open world, you have to prove that Santa is not listed. So either there is a specific statement that he isn't, or you have some way to make that inference.) The difference here is that there is no "closed-world assumption", rather there is a "closure statement" about the registry facts. This is Terry's "concept is closed in the schema". (This is like Don's rule 1 above.) This also asserts that you will not be able to infer that someone is listed; you will only have a set of assertions. Compared to the "half-open" concept above, this is the strong "closed" assumption. That is why rules engines use the half-open assumption and have 'order of evaluation' and 'stratification' and the like. In effect their rule is: if we can't use our inferencing mechanism to infer that Santa is listed, then Santa is _not_ listed. Part 2 ­ facts and actualities. In order to accommodate the case that Sjir raises, we were careful to define .fact. so that it does not necessarily correspond with an actuality. A fact is merely .taken as true.. We do not define it as .proposition that is true.. A fact need not be true. I think this is confused. SBVR is about sharing knowledge, i.e., perceptions of the real world. The relationship between knowledge/perception and reality is out of scope. An actuality is a state of affairs that is perceived to exist in the world in question; a fact is a proposition that is taken to be true of the world in question. So a fact does correspond to an 'actuality' in that sense. SBVR is (and must be) silent on the relationship between an actuality and any absolute measure of reality. There is a different issue, namely, whether every fact corresponds to a 'thing' that is an 'actuality'. That is, do we reify every actuality? Put another way, if I leave my office, I may have a proposition 'Ed has left the office', but I'm not sure the Domain of Discourse needs to have a 'thing' that is the actuality of the exit. In practice, we create the actuality things in order to phrase propositions that involve adverbial modifications: "'Ed's leaving the office' occurred at noon." So the interpretation that Sjir wants is what we already have. Note that it is important to keep .taken as true. and not abandon it for .either true or false., which would leave us with the full breadth of .proposition.. I'm not sure what this means. "true" is an assigned value in a formal logic system. It only has meaning with respect to the nature of the knowledge. A Mathematical proposition is "true" or "false" with respect to a certain set of "first principles" or "fundamental axioms". A business or scientific proposition is "true" or "false" with respect to a certain perception of reality. In both cases that is what we mean by "true", and "taken to be true" only clarifies that it has no absolute measure in reality. It would not be helpful for every possible proposition to be automatically a fact. Of course not. A proposition is a meaning. The meaning is independent of the domain of discourse that is the population of any given "world". In business, there is always the problem of the past, the planned, and the actual future being different from the present "world". And we can talk about things that are currently false, but we expect them to be true tomorrow. So we talk about "possible worlds". A 'fact' is a relationship between a proposition and a given world. A 'necessity' is a proposition that we take to be true over all 'possible worlds of interest'. That is, it is a fact in every world we care about. This is, IMO, exactly the kind of thing in which the semantic, linguistic and formal views of the problem diverge. We have to ride one horse here, and harness the others to follow. We can't please all of the ivory towers all the time. Best, -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 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 X-KeepSent: 32E5AAEA:CE931DEC-85257634:006D44D8; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Thu, 17 Sep 2009 16:46:58 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.2FP1 ZOS802FP1HF3|June 25, 2009) at 09/17/2009 16:47:02 Sjir, Regarding 14241 -- by default, fact types are open-world, but SBVR does have the ability to identify specific fact types as closed world. See clause 8.5, "fact type is internally closed in conceptual schema" and "concept is closed in conceptual schema". I think that address part of what you ask. I'm not sure what you mean by "state of affairs interpretation" versus "actuality interpretation" of a fact type. I think it is important that an individual fact type can be used with both interpretations. "Don visits Poland" is a state of affairs before he does the visiting, but becomes an actuality once he visits. To put it another way, interpretations apply to instances of fact types, not fact types themselves. Regarding your comment "Suppose we add to these two facts the third fact: Don Basley has not visited, we get in both worlds the answer No. In fact this option is avaialable in clause 10 but there is no fact type in Clause 8 to declare it." This statement can be formulated using clause 9. It is simply the negation of the formulation "Don Baisley has visited". I am interested in your statement that "More than 95 percent of the business systems work on the state of affairs view". I think what you are saying is that in most cases, businesses take what is recorded in information systems as facts (i.e. "propositions taken to be true"). They treat the information records as facts independent of the state of the real world. I don't think I would call this the "state of affairs view". The issue here is about belief, not really about actualities versus states of affairs. I agree that ground fact examples really help the discussion. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Sjir Nijssen" ---09/17/2009 03:23:01 PM---To all, "Sjir Nijssen" 09/17/2009 03:21 PM To , "SBVR RTF" cc Subject RE: -- states of affairs and open-closed world assumptions 2009-09-17-2122 To all, I have proposed 14241 to give SBVR a possibility to serve more than one small community. Let the SBVR user decide which of the four options he wants to use. ([State-of-affairs, Closed-world], [State-of-affairs, Open-world], [Actuality, Closed-world], [Actuality, Open-world] I happen to have studied Larson and Segal. There are many good things in it but this book has very little to do with 14241, is my opinion. Suppose we have the following two facts in our register: Don Baisley has visited Germany; Don Baisley has visited Spain. If we ask in the closed world: has Don Baisley visited Poland, the answer will be no. If we ask the same question in the open world: the answer is: I don't know. Suppose we add to these two facts the third fact: Don Basley has not visited, we get in both worlds the answer No. In fact this option is avaialable in clause 10 but there is no fact type in Clause 8 to declare it. With respect to actuality and state of affairs. More than 95 percent of the business systems work on the state of affairs view. If you state that you have a passport of the Netherlands and a Dutch border police checks it is available in the Dutch registry of passports and he does not find it there, then you have no passport. Of course you can go to court and several months later the judge may decide on yes or no of having the passport, but these are the exceptions. There is simply not enough time to work with the actuality view in general but 14241 still makes it possible. If you are in a hospital and the last measured blood sugar is 23, then the doctors will act on this state of affairs. There is no reliable way to talk about actuality of blood sugar. Of course there are other examples where this is possible. If in EU-Rent, car A, B and C are according to the system available in the branch store, and if car B is assigned to a renter and the renter goes to the store to pick up car B and comes back and says: but only car A and C are there, not B, then I would assume that a new fact is generated: Car B is not any longer available, of course after the clerk has checked the store. I hope we will use in the future more examples at the ground fact level to illustrate a discussion. Kind regards Sjir Nijssen -------------------------------------------------------------------------------- Van: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Verzonden: do 17-9-2009 20:42 Aan: 'SBVR RTF' Onderwerp: FW: -- states of affairs An earlier discussion of how SBVR handles âstate of affairsâ. Donald -------------------------------------------------------------------------------- From: Baisley, Donald E [mailto:Donald.Baisley@unisys.com] Sent: 20 June 2007 16:17 To: sbvr-ftf@omg.org Subject: RE: SBVR Issue 9948 -- roles and states of affairs The use of âexistsâ in logic should not be confused with the meaning of âholdsâ as it applies to states of affairs. The word âoccursâ is often a more natural word to use for âholdsâ. A state S1 that holds is an actuality. A state S2 that does not hold now, but will hold in the future, is not now an actuality. But the state S3 that S2 will hold in the future is an actuality. A state S4 that does not hold now, but did hold in the past, is not an actuality. But the state S5 that S4 did hold in the past is an actuality. The states S1, S2, S3, S4 and S5 all exist. They are all subjects of discourse regardless of whether or not they are actualities. Being able to refer to states as things that exist, even while they do not hold (occur) is vital to being able to map natural language into logic. It is necessary to the understanding of adverbs, tense and adjuncts as they occur within sentences. I recommend Knowledge of Meaning by Richard Larson and Gabriel Segal as a good book that covers this. But there are others. I donât have time to go into lots of detail on this. So please read books on the subject if you want to dig into it deeper. SBVRâs model of states of affairs and actualities works. Regards, Don From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: RE: issue 14241 -- SBVR RTF issue Thread-Topic: issue 14241 -- SBVR RTF issue Thread-Index: AQHKK9cyqzYlzZVmskaaqzPZkR3Y85IEoJyA Date: Fri, 26 Mar 2010 00:36:35 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Here is a proposed resolution to SBVR issue 13241 based on our discussion and agreement at today.s RTF meeting. Regards, Don Issue 14241.doc OMG Issue No: 14241 Title: Coexistence approach to SBVR Source: Sjir Nijssen, PNA University, Sjir.Nijssen@PNA-Group.NL Summary: According to our observations, more than 95% of all business applications operate under the closed world assumption and the state of affairs interpretation. In order to give other approaches (standards) the option to work with SBVR, it is proposed to offer the following: for each fact type one of the following combinations can be selected: 1. Closed world assumption; state of affairs interpretation 2. Closed world assumption; actuality interpretation 3. Open world assumption; state of affairs interpretation 4. Open world assumption; actuality interpretation. For convenience it is recommended to add the following four meta fact types: 1. The population of all fact types in is considered 2. The population of all fact types in is considered 3. The population of is considered 4. The population of is considered Note that a fact type overrides a conceptual schema specification. Note that there is a business rule that for each fact type it holds that it can have only one value of closed_or_open and one value of state-of-affairs_or_actuality. Resolution: SBVR works with all business applications that are based on business vocabularies and rules, regardless of open/closed assumptions and regardless of whether fact models are interpreted as corresponding to actualities or as hypothetical. Closed world assumption . SBVR supports both open and closed world assumptions. Wherever there is a desire to assert that all fact types in a given conceptual schema are closed (or open), that proposition can be formulated with existing SBVR concepts using universal quantification. For example, for a conceptual schema C: Each fact type that is in C is closed in C. Any default selections of open or closed by tools that create conceptual schemas are a matter for tool builders to decide and are not a subject of the SBVR specification. Characterizing a fact type as open or closed independently of any conceptual schema or fact model is inappropriate because the same fact type can be in multiple conceptual schemas. A fact type is a meaning. Since it is logically possible that the same meaning is in multiple conceptual schemas created by different people for different purposes, it is impractical to assume that anyone would know whether closure is universal. Therefore, no new fact type characterizing fact types as open or closed will be added. However, any tool can certainly have defaults or allow defaults to be set regarding closure for the conceptual schemas that are created by that tool. State-of-affairs interpretation . SBVR defines .fact. to be .proposition that is taken as true., not as .proposition that is true.. So facts might or might not correspond to actualities, but they always correspond to states of affairs. A fact model is for a possible world, not necessarily for the actual world. Wherever there is a desire to assert that all facts in a fact model correspond to actualities, that proposition can be formulated with existing SBVR concepts using universal quantification. For example, for a fact model F: Each fact that is in F corresponds to an actuality. Any tool can have its own default behavior with respect to such assumptions about its fact models. Defining such defaults is outside of the scope of the SBVR specification. Disposition: Resolved with NO CHANGE From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: RE: issue 14241 -- SBVR RTF issue Thread-Topic: issue 14241 -- SBVR RTF issue Thread-Index: AQHKK9cyqzYlzZVmskaaqzPZkR3Y85IEoJyAgAE4E1A= Date: Fri, 26 Mar 2010 19:15:33 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Sjir Nijssen recommended a small wording change which I have incorporated into this resolution. The updated proposed resolution for issue 14241 is attached. Best regards, Don From: Don Baisley Sent: Thursday, March 25, 2010 5:37 PM To: 'SBVR RTF' (sbvr-rtf@omg.org) Subject: RE: issue 14241 -- SBVR RTF issue Here is a proposed resolution to SBVR issue 14241 based on our discussion and agreement at today.s RTF meeting. Regards, Don Issue 142411.doc OMG Issue No: 14241 Title: Coexistence approach to SBVR Source: Sjir Nijssen, PNA University, Sjir.Nijssen@PNA-Group.NL Summary: According to our observations, more than 95% of all business applications operate under the closed world assumption and the state of affairs interpretation. In order to give other approaches (standards) the option to work with SBVR, it is proposed to offer the following: for each fact type one of the following combinations can be selected: 1. Closed world assumption; state of affairs interpretation 2. Closed world assumption; actuality interpretation 3. Open world assumption; state of affairs interpretation 4. Open world assumption; actuality interpretation. For convenience it is recommended to add the following four meta fact types: 1. The population of all fact types in is considered 2. The population of all fact types in is considered 3. The population of is considered 4. The population of is considered Note that a fact type overrides a conceptual schema specification. Note that there is a business rule that for each fact type it holds that it can have only one value of closed_or_open and one value of state-of-affairs_or_actuality. Resolution: SBVR works with all business applications that are based on business vocabularies and rules, regardless of open/closed assumptions and regardless of whether fact models are interpreted as corresponding to actualities or as corresponding to states of affairs that might not be actualities (e.g., models of hypothetical worlds). Closed world assumption . SBVR supports both open and closed world assumptions. Wherever there is a desire to assert that all fact types in a given conceptual schema are closed (or open), that proposition can be formulated with existing SBVR concepts using universal quantification. For example, for a conceptual schema C: Each fact type that is in C is closed in C. Any default selections of open or closed by tools that create conceptual schemas are a matter for tool builders to decide and are not a subject of the SBVR specification. Characterizing a fact type as open or closed independently of any conceptual schema or fact model is inappropriate because the same fact type can be in multiple conceptual schemas. A fact type is a meaning. Since it is logically possible that the same meaning is in multiple conceptual schemas created by different people for different purposes, it is impractical to assume that anyone would know whether closure is universal. Therefore, no new fact type characterizing fact types as open or closed will be added. However, any tool can certainly have defaults or allow defaults to be set regarding closure for the conceptual schemas that are created by that tool. State-of-affairs interpretation . SBVR defines .fact. to be .proposition that is taken as true., not as .proposition that is true.. So facts might or might not correspond to actualities, but they always correspond to states of affairs. A fact model is for a possible world, not necessarily for the actual world. Wherever there is a desire to assert that all facts in a fact model correspond to actualities, that proposition can be formulated with existing SBVR concepts using universal quantification. For example, for a fact model F: Each fact that is in F corresponds to an actuality. Any tool can have its own default behavior with respect to such assumptions about its fact models. Defining such defaults is outside of the scope of the SBVR specification. Disposition: Resolved with NO CHANGE Date: Mon, 29 Mar 2010 12:33:31 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: Re: issue 14241 -- SBVR RTF issue X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o2TGXaqU006877 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1270485219.56516@xv42A1T7VKbJFL3LOK0Fcw X-Spam-Status: No Don Baisley wrote: Here is a proposed resolution to SBVR issue 13241 based on our discussion and agreement at today.s RTF meeting. The Resolution text includes the following: SBVR defines .fact. to be .proposition that is taken as true., not as .proposition that is true.. So facts might or might not correspond to actualities, but they always correspond to states of affairs. A fact model is for a possible world, not necessarily for the actual world. This reflects the SBVR community confusion about 'actuality'. There is no 'actual world'; there is the world described by the fact model. A fact model asserts 'facts' -- propositions that are taken to be true. Each fact describes an 'actuality' in the world that corresponds to the fact model. The relationship between a fact model and the state of the 'real world' at the time the fact model is created is not addressed by SBVR. In the Pope's world, God created man; in Nietzsche's world, man created God. They are both fact models. A conceptual schema describes possible worlds, that is, it creates the vocabulary with which to describe a possible world in a fact model, and it states necessities: propositions that must correspond to 'actualities' in every possible world whose fact model conforms to the conceptual schema. The remaining confusion is about what a 'state of affairs' is. Sjir and I remain confused, and I am now certain that the entirety of the RTF is confused as well -- witness the agreement to write the misunderstanding quoted above. -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 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: RE: issue 14241 -- SBVR RTF issue Thread-Topic: issue 14241 -- SBVR RTF issue Thread-Index: AQHKK9cyqzYlzZVmskaaqzPZkR3Y85IEoJyAgAE4E1CAjv5DcA== Date: Fri, 25 Jun 2010 18:52:40 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Here is a resolution to SBVR issue 14241 that was revised in yesterday.s RTF meeting and was agreed to be ready for ballot. Regards, Don Issue 14241.doc OMG Issue No: 14241 Title: Coexistence approach to SBVR Source: Sjir Nijssen, PNA University, Sjir.Nijssen@PNA-Group.NL Summary: According to our observations, more than 95% of all business applications operate under the closed world assumption and the state of affairs interpretation. In order to give other approaches (standards) the option to work with SBVR, it is proposed to offer the following: for each fact type one of the following combinations can be selected: 1. Closed world assumption; state of affairs interpretation 2. Closed world assumption; actuality interpretation 3. Open world assumption; state of affairs interpretation 4. Open world assumption; actuality interpretation. For convenience it is recommended to add the following four meta fact types: 1. The population of all fact types in is considered 2. The population of all fact types in is considered 3. The population of is considered 4. The population of is considered Note that a fact type overrides a conceptual schema specification. Note that there is a business rule that for each fact type it holds that it can have only one value of closed_or_open and one value of state-of-affairs_or_actuality. Resolution: SBVR works with all business applications that are based on business vocabularies and rules, regardless of open/closed assumptions and regardless of whether fact models are interpreted as representing the real world or as representing hypothetical worlds. Closed world assumption . SBVR supports both open and closed world assumptions. Wherever there is a desire to assert that all fact types in a given conceptual schema are closed (or open), that proposition can be formulated with existing SBVR concepts using universal quantification. For example, for a conceptual schema C: Each fact type that is in C is closed in C. Any default selections of open or closed by tools that create conceptual schemas are a matter for tool builders to decide and are not a subject of the SBVR specification. Characterizing a fact type as open or closed independently of any conceptual schema or fact model is inappropriate because the same fact type can be in multiple conceptual schemas. A fact type is a meaning. Since it is logically possible that the same meaning is in multiple conceptual schemas created by different people for different purposes, it is impractical to assume that anyone would know whether closure is universal. Therefore, no new fact type characterizing fact types as open or closed will be added. However, any tool can certainly have defaults or allow defaults to be set regarding closure for the conceptual schemas that are created by that tool. State-of-affairs interpretation . SBVR defines .fact. to be .proposition that is taken as true., not as .proposition that is true.. A fact is a proposition that is taken to be true in the world that is the subject of discourse, whether that world is real or hypothetical. Any tool can have its own default behavior with respect to assumptions about possible worlds. Defining such defaults is outside of the scope of the SBVR specification. Disposition: Resolved with NO CHANGE Note that a fact type overrides a conceptual schema specification. Note that there is a business rule that for each fact type it holds that it can have only one value of closed_or_open and one value of state-of-affairs_or_actuality.