Issue 18173: Adopt ‘occurrence’ and ‘what-happens state of affairs’ from SBVR (date-time-ftf) Source: Business Semantics Ltd. (Mr. Donald R. Chapin, Donald.Chapin(at)BusinessSemantics.com) Nature: Uncategorized Issue Severity: Summary: In support of the addition of a very generic concept for all kinds of occurrences to SBVR at the DTV RTF’s request, so that all specifications that define a particular kind of occurrence based on this generic SBVR concept, the Date-Time Vocabulary needs entries to do this. Resolution: 1. Adopt ‘occurrence‘ from SBVR as specialize it as ‘temporal occurrence’. 2. Adopt ‘what-happens state of affairs has occurrence’ from SBVR as specialize it as ‘what-happens state of affairs has temporal occurrence’. Revised Text: In clause 16 immediately before the entry for ‘situation model', INSERT two new entries: temporal occurrence Definition: occurrence that occurs for a given time interval … add whatever contraints are required by DTV on ‘temporal occurrence’, which is adopted from SBVR … Necessity: A state of affairs will have occurred for a time interval if and only if the state of affairs has an occurrence and the occurrence interval of the occurrence is the time interval. Necessity: A state of affairs has been actual if and only if an occurrence of the state of affairs is in the past. Necessity: A state of affairs is actual if and only if an occurrence of the state of affairs is current. Necessity: A state of affairs will be actual if and only if an occurrence of the state of affairs is in the future. Necessity: An occurrence has been actual if and only if the occurrence is in the past. Necessity: An occurrence is actual if and only if the occurrence is current. Necessity: An occurrence will be actual if and only if the occurrence is in the future. what-happens state of affairs … add whatever contraints are required by DTV on ‘what-happens state of affairs’, which is adopted from SBVR … what-happens state of affairs has temporal occurrence Definition: ’ what-happens state of affairs has occurrence’ that includes only temporal occurrences … add whatever contraints are required by DTV between ‘temporal occurrence’ and ‘what-happens state of affairs’, which are adopted from SBVR … In clause 16.7, in the entry for ' situation model occurs now', ADD a Nole: Note: The statement “the state of affairs has an occurrence that is current” is semantically equivalent to the SBVR characterisitc “state of affairs is actual”. Resolution: Revised Text: Actions taken: October 15, 2012: received issue Discussion: End of Annotations:===== sposition: Resolved OMG Issue No: 18173 Title: Adopt .occurrence. and .what-happens state of affairs. from SBVR Source: Business Semantics Ltd, Donald Chapin, (Donald.Chapin@BusinessSemantics.com) Summary: In support of the addition of a very generic concept for all kinds of occurrences to SBVR at the DTV RTF.s request, so that all specifications that define a particular kind of occurrence based on this generic SBVR concept, the Date-Time Vocabulary needs entries to do this. Resolution: 1. Adopt .occurrence. from SBVR as specialize it as .temporal occurrence.. 2. Adopt .what-happens state of affairs has occurrence. from SBVR as specialize it as .what-happens state of affairs has temporal occurrence.. Revised Text: In clause 16 immediately before the entry for .situation model', INSERT two new entries: temporal occurrence Definition: occurrence that occurs for a given time interval . add whatever contraints are required by DTV on .temporal occurrence., which is adopted from SBVR . Necessity: A state of affairs will have occurred for a time interval if and only if the state of affairs has an occurrence and the occurrence interval of the occurrence is the time interval. Necessity: A state of affairs has been actual if and only if an occurrence of the state of affairs is in the past. Necessity: A state of affairs is actual if and only if an occurrence of the state of affairs is current. Necessity: A state of affairs will be actual if and only if an occurrence of the state of affairs is in the future. Necessity: An occurrence has been actual if and only if the occurrence is in the past. Necessity: An occurrence is actual if and only if the occurrence is current. Necessity: An occurrence will be actual if and only if the occurrence is in the future. what-happens state of affairs . add whatever contraints are required by DTV on .what-happens state of affairs., which is adopted from SBVR . what-happens state of affairs has temporal occurrence Definition: . what-happens state of affairs has occurrence. that includes only temporal occurrences . add whatever contraints are required by DTV between .temporal occurrence. and .what-happens state of affairs., which are adopted from SBVR . In clause 16.7, in the entry for ' situation model occurs now', ADD a Nole: Note: The statement .the state of affairs has an occurrence that is current. is semantically equivalent to the SBVR characterisitc .state of affairs is actual.. Disposition: Resolved From: "Donald Chapin" To: "'Mark H Linehan'" , Cc: Subject: RE: New SBVR Issue + New DTV Issue Enabling All Kinds of 'Occurrence' SBVR Vocabularies to be Standardized Consistently Date: Wed, 17 Oct 2012 12:56:44 +0100 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG5xgS7BK9QIGHoDeIvGcLChDly5AFKW253l9rdpYA= X-Mirapoint-IP-Reputation: reputation=Fail, source=NONE, refid=n/a, actions=MAILHURDLE TAG X-Junkmail-Premium-Raw: score=11/50, refid=2.7.2:2012.10.17.113406:17:11.920, ip=81.149.51.65, rules=__HAS_FROM, __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, __C230066_P5, __HTML_MSWORD, __HTML_FONT_BLUE, __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=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.507E9CFF.0087,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Mark, On 16 October 2012 18:29 Mark Linehan wrote: 've discussed this with other members of the Date-Time FTF, and we feel this is a start in the right direction. We do have a number of comments: 1. Making 'occurrence' a kind of 'state of affairs' is problematic because it implies the following: a) An occurrence can have other occurrences, which doesn't make sense. Then add this Necessity to DTV Necessity: No temporal occurrence is a what-happens state of affairs of another temporal occurrence b) An occurrence can be not actual. This seems contradictory since it implies a "state of affairs that is the happening ..." is not happening. In SBVR, propositions posit states of affairs (events, activities, situations & circumstances) in the universe of discourse which may be actual or no actual. Of course there can be states of affairs in the universe of discourse that no one has said or written a sentence about. In SBVR false propositions correspond to states of affairs that are posited but not actual or no state of affairs. c) A proposition can correspond to an occurrence. I think we previously agreed that what a proposition corresponds to is a 'what-happens SOA' which may have an occurrence. We never agreed that propositions do not correspond to occurrences. Here.s one that does: John threw his football to Bill at 5:55:30 PM on Saturday, October 13, 2012. 2. It does not make sense to subtype 'occurrence' as 'temporal occurrence', 'location occurrence', etc. Every happening has a time and a place, even if they are not stated in the proposition that corresponds to the 'what-happens SOA' that has the happening. It.s useful to have the distinction between .temporal occurrence. and .location occurrence. in SBVR. But, since DTV is concerned only with the time dimension, .occurrence. in DTV means the same thing as .temporal occurrence. means in SBVR. So no change to the signifier for .occurrence. in DTV is needed. For example, the proposition "Mark sits in chair 123" does not mention a time. It corresponds to a 'what-happens SOA' that has zero or more occurrences, each of which definitely has a time. If the present tense sits is interpreted to mean .now., then it does include time. If the present tense sits is interpreted to mean .sometimes., then the proposition does not include time and its truth value is determined independent of the time of any actual occurrences(s). 3. Following up on point 1(c), a proposition should only correspond to a 'what-happens SOA'. 4. 'What-happens SOA' should have 'Concept Type: role'. But if you agree with us that 'occurrence' should be a separate kind of res, then there's no reason to distinguish 'state of affairs' from 'what-happens SOA'. No, it is defined as .can happen.. Role would limit it to only those that are already playing the role in .what-happens state of affairs occurs for time interval.. 5. Making 'occurrence' and 'state of affairs' abstract in the MOF model has the consequence that users can't draw UML instance diagrams of them. This seems an undesirable restriction. Res is not a meaning. They never go in any model or even any database. Only concepts and propositions go in SBVR Business Vocabulary and Rules Content Models. Only propositions taken to be true (facts) go in databases and other kinds of factbases. Never a res. When you transform .what happens state of affairs. and .occurrence. to the DTV UML model, the definition changes .by definition.. The instances of UML Data Model constructs are facts not res. The definition of .state of affairs would be .fact about an event, activity, situation or circumstance.. The definition of occurrence would follow the same pattern. 6. I would like to discuss what you intend to accomplish by changing the definition of 'actuality' from 'happens' to 'is happening'. Ed requested it and he is right. .Happens. can be interpreted to mean .happens sometimes. and that is not correct. .Is happening. cannot be so interpreted. 7.The definition of 'what-happens SOA has occurrence' should be "the occurrence is A realization of the SOA", not "the occurrence is THE realization of the SOA". "the occurrence is THE realization of the SOA" is the way Ed wrote it and he was correct. One instance of that verb concept is for just one occurrence. 8. It would be useful to have the concept of 'individual what-happens SOA'. Reason: many SOAs only have one occurrence. When referring to such SOAs in English, we often mean the occurrence. All you have to do is add that concept to DTV. 9. We propose either of these two names for 'what-happens SOA' (which seems a very clumsy signifier): 'situation kind' or 'situation model'. All you have to do is to add those synonyms to DTV. 10. We request a synonymous form for 'what-happens SOA has occurrence': either 'occurrence exemplifies what-happens SOA' or 'occurrence realizes what-happens SOA'. The former is already used by DTV. All you have to do is add whatever synonymous forms you need to DTV. 11. It is not clear what the first Necessity proposed in 18173 means for those 'what-happens SOAs' that have multiple occurrences. DTV distinguishes between the time intervals of the occurrences of a 'what-happens SOA' and the time span that covers all the occurrences of the 'what-happens SOA'. It says that a what-happens state of affairs has to have an occurrence to have occurred, and that the occurrence is occurring during the occurrence interval in the possible world being referenced. 12. The second and fourth Necessities don't make sense because SOAs are actual only with respect to the current time of the possible world. An SOA about a past occurrence is actual if the possible world currently has a record of the past occurrence. The actuality of an SOA that mentions the future cannot be known until the current time is that future. SBVR is not about .records.. That the domain of factbases. Necessities 2-4 are about what can make the what-happens state of affairs actual. 13. The third Necessity should go with 'state of affairs is current'. OK, all you have to do is put it there. 14. The fifth through seventh Necessities (the ones about occurrences) do not make sense -- presuming you agree that every occurrence is actual. If every occurrence is actual, then you can.t talk about occurrences that are not actual, which of course you can do in natural language. SBVR is a natural language standard. Donald ----------------------------- Mark H. Linehan STSM, IBM Research From: "Donald Chapin" To: , "Juergen Boldt" , Cc: "sbvr-rtf " , Date: 10/15/2012 08:51 AM Subject: New SBVR Issue + New DTV Issue Enabling All Kinds of 'Occurrence' SBVR Vocabularies to be Standardized Consistently -------------------------------------------------------------------------------- Juergen, SBVR RTF & DTV RTF -- Attached are two small new Issues with their proposed resolutions, one for the SBVR RTF and the other for the DTV RTF, that provide the means for the DTV specification to define temporal occurrence in a way that will integrate with other standards that define any kind of occurrence based on SBVR -- including those that define occurrence in space, and possibly occurrence in other dimensions. Donald [attachment "SBVR Issue nnnnn - Add Generic Occurrence to SBVR.doc" deleted by Mark H Linehan/Watson/IBM] [attachment "DTV Issue nnnnn - Adopt Generic Occurrence from SBVR.docx" deleted by Mark H Linehan/Watson/IBM] To: sbvr-rtf@omg.org Subject: RE: New SBVR Issue + New DTV Issue Enabling All Kinds of 'Occurrence' SBVR Vocabularies to be Standardized Consistently X-KeepSent: 868D58EF:4437B0DB-85257A9A:005A6FC8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Mark H Linehan Date: Wed, 17 Oct 2012 14:03:49 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.3FP2IF1|July 25, 2012) at 10/17/2012 14:03:55, Serialize complete at 10/17/2012 14:03:55 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12101718-9360-0000-0000-00000BC91499 I did not have an opportunity to review this before our call. So I am responding like this. ----------------------------- Mark H. Linehan STSM, IBM Research From: "Donald Chapin" To: Mark H Linehan/Watson/IBM@IBMUS, , Cc: Date: 10/17/2012 07:57 AM Subject: RE: New SBVR Issue + New DTV Issue Enabling All Kinds of 'Occurrence' SBVR Vocabularies to be Standardized Consistently -------------------------------------------------------------------------------- Mark, On 16 October 2012 18:29 Mark Linehan wrote: . I've discussed this with other members of the Date-Time FTF, and we feel this is a start in the right direction. We do have a number of comments: 1. Making 'occurrence' a kind of 'state of affairs' is problematic because it implies the following: a) An occurrence can have other occurrences, which doesn't make sense. Then add this Necessity to DTV Necessity: No temporal occurrence is a what-happens state of affairs of another temporal occurrence The Necessity should be: No occurrence has an occurrence. b) An occurrence can be not actual. This seems contradictory since it implies a "state of affairs that is the happening ..." is not happening. In SBVR, propositions posit states of affairs (events, activities, situations & circumstances) in the universe of discourse which may be actual or no actual. Of course there can be states of affairs in the universe of discourse that no one has said or written a sentence about. A agree with what Donald says, but I don't understand how this responds to the point I made. My point is that if I consider the phrase "occurrence is not actual" and I substitute the definitions of 'occurrence' and 'soa is actual', I get "state of affairs that is the happening of another state of affairs for a given time interval and/or at a given location and/or in some other dimension that is not happening (i.e., takes place, obtains)". This is a contradiction. The fix for this is a Necessity that says "Each occurrence is actual". In SBVR false propositions correspond to states of affairs that are posited but not actual or no state of affairs. Yes, we agree. c) A proposition can correspond to an occurrence. I think we previously agreed that what a proposition corresponds to is a 'what-happens SOA' which may have an occurrence. We never agreed that propositions do not correspond to occurrences. Here.s one that does: John threw his football to Bill at 5:55:30 PM on Saturday, October 13, 2012. I believe this example corresponds to a 'what-happens SOA' that has an occurrence. The correspondance is always between a proposition and a what-happens SOA, and then it indirectly relates to the occurrence. The fix for this is a Necessity: Each proposition corresponds to exactly one what-happens SOA. 2. It does not make sense to subtype 'occurrence' as 'temporal occurrence', 'location occurrence', etc. Every happening has a time and a place, even if they are not stated in the proposition that corresponds to the 'what-happens SOA' that has the happening. It.s useful to have the distinction between .temporal occurrence. and .location occurrence. in SBVR. But, since DTV is concerned only with the time dimension, .occurrence. in DTV means the same thing as .temporal occurrence. means in SBVR. So no change to the signifier for .occurrence. in DTV is needed. It seems to me that every occurrence has both a time and a place, so I don't see the reason for the distinction. Please note that an occurrence is a real thing. A proposition that refers to an occurrence may not mention the time or the place, but the occurrence still has both. For example, the proposition "Mark sits in chair 123" does not mention a time. It corresponds to a 'what-happens SOA' that has zero or more occurrences, each of which definitely has a time. If the present tense sits is interpreted to mean .now., then it does include time. If the present tense sits is interpreted to mean .sometimes., then the proposition does not include time and its truth value is determined independent of the time of any actual occurrences(s). Donald's response does not address my point, which is about the relationship among propositions, what-if SOAs, and occurrences. I would say that if 'sits' is interpreted as 'now' then the proposition corresponds to a what-if SOA that has an occurrence that occurs for now (and maybe other occurrences). If 'sits' is interpreted as 'sometimes' then the proposition corresponds to a what-if SOA that has zero or more occurrences. My interpretation supports most of what Donald says. I do not agree that "its truth value is determined independent of the time of any actual occurrences(s)." According to SBVR and 18172, the truth value of a proposition depends upon whether it corresponds to an actuality. And 'SOA is actual' depends upon whether the SOA "is happening" - present tense. So the truth value of a proposition does depend upon time. 3. Following up on point 1(c), a proposition should only correspond to a 'what-happens SOA'. 4. 'What-happens SOA' should have 'Concept Type: role'. But if you agree with us that 'occurrence' should be a separate kind of res, then there's no reason to distinguish 'state of affairs' from 'what-happens SOA'. No, it is defined as .can happen.. Role would limit it to only those that are already playing the role in .what-happens state of affairs occurs for time interval.. In that case, the diagram in 18172 is inconsistent with the text. I made this comment because the diagram shows it as a role, but DTV would be MUCH happier if 'what-happens SOA' is truly a specialization of 'SOA'. 5. Making 'occurrence' and 'state of affairs' abstract in the MOF model has the consequence that users can't draw UML instance diagrams of them. This seems an undesirable restriction. Res is not a meaning. They never go in any model or even any database. Only concepts and propositions go in SBVR Business Vocabulary and Rules Content Models. Only propositions taken to be true (facts) go in databases and other kinds of factbases. Never a res. I do not propose to put res in models. I do want to be able to show EXAMPLES on UML diagrams. If you make 'occurrence' abstract then you can't draw UML diagrams that contain instances of 'occurrence'. When you transform .what happens state of affairs. and .occurrence. to the DTV UML model, the definition changes .by definition.. The instances of UML Data Model constructs are facts not res. The definition of .state of affairs would be .fact about an event, activity, situation or circumstance.. The definition of occurrence would follow the same pattern. UML can be used to model the real world. We are using it that way, so we do not change the definitions when we model DTV in UML. For example, when we draw a class called 'time interval' in UML, we do not mean that the class is of machine artifacts that somehow represent time intervals. We mean a class whose instances are real time intervals. When we draw a class labelled 'occurrence', we mean that the instances of that class are real occurrences in the real world. We also like to draw UML instance diagrams that illustrate uses of the class diagrams. If you make 'occurrence' abstract then we can't do that for examples that involve occurrences. 6. I would like to discuss what you intend to accomplish by changing the definition of 'actuality' from 'happens' to 'is happening'. Ed requested it and he is right. .Happens. can be interpreted to mean .happens sometimes. and that is not correct. .Is happening. cannot be so interpreted. OK. 7.The definition of 'what-happens SOA has occurrence' should be "the occurrence is A realization of the SOA", not "the occurrence is THE realization of the SOA". "the occurrence is THE realization of the SOA" is the way Ed wrote it and he was correct. One instance of that verb concept is for just one occurrence. I see no Necessity that "each what-happens SOA has exactly one occurrence". And if you mean to have that Necessity, then it is fundamentally broken. I don't believe Ed was intending his words to be used as a definition. 8. It would be useful to have the concept of 'individual what-happens SOA'. Reason: many SOAs only have one occurrence. When referring to such SOAs in English, we often mean the occurrence. All you have to do is add that concept to DTV. OK. 9. We propose either of these two names for 'what-happens SOA' (which seems a very clumsy signifier): 'situation kind' or 'situation model'. All you have to do is to add those synonyms to DTV. OK. 10. We request a synonymous form for 'what-happens SOA has occurrence': either 'occurrence exemplifies what-happens SOA' or 'occurrence realizes what-happens SOA'. The former is already used by DTV. All you have to do is add whatever synonymous forms you need to DTV. OK. 11. It is not clear what the first Necessity proposed in 18173 means for those 'what-happens SOAs' that have multiple occurrences. DTV distinguishes between the time intervals of the occurrences of a 'what-happens SOA' and the time span that covers all the occurrences of the 'what-happens SOA'. It says that a what-happens state of affairs has to have an occurrence to have occurred, and that the occurrence is occurring during the occurrence interval in the possible world being referenced. I don't disagree with your intention, but the way it is stated is at least confusing. 12. The second and fourth Necessities don't make sense because SOAs are actual only with respect to the current time of the possible world. An SOA about a past occurrence is actual if the possible world currently has a record of the past occurrence. The actuality of an SOA that mentions the future cannot be known until the current time is that future. SBVR is not about .records.. That the domain of factbases. Necessities 2-4 are about what can make the what-happens state of affairs actual. These Necessities are about what is and what is not actual which necessarily involves fact bases. You can't evaluation whether an SOA is actual without looking at the facts in a possible world. If you allergic to "records", then please substitute "facts" for "records". 13. The third Necessity should go with 'state of affairs is current'. OK, all you have to do is put it there. Good, we agree. 14. The fifth through seventh Necessities (the ones about occurrences) do not make sense -- presuming you agree that every occurrence is actual. If every occurrence is actual, then you can.t talk about occurrences that are not actual, which of course you can do in natural language. SBVR is a natural language standard. My position is that we only talk about the actuality (or not) of what-happens SOAs. Occurrences are always actual. Donald ----------------------------- Mark H. Linehan STSM, IBM Research From: "Donald Chapin" To: , "Juergen Boldt" , Cc: "sbvr-rtf " , Date: 10/15/2012 08:51 AM Subject: New SBVR Issue + New DTV Issue Enabling All Kinds of 'Occurrence' SBVR Vocabularies to be Standardized Consistently -------------------------------------------------------------------------------- Juergen, SBVR RTF & DTV RTF -- Attached are two small new Issues with their proposed resolutions, one for the SBVR RTF and the other for the DTV RTF, that provide the means for the DTV specification to define temporal occurrence in a way that will integrate with other standards that define any kind of occurrence based on SBVR -- including those that define occurrence in space, and possibly occurrence in other dimensions. Donald [attachment "SBVR Issue nnnnn - Add Generic Occurrence to SBVR.doc" deleted by Mark H Linehan/Watson/IBM] [attachment "DTV Issue nnnnn - Adopt Generic Occurrence from SBVR.docx" deleted by Mark H Linehan/Watson/IBM]